[ipv6-wg] 96 more bits... time for some magic after all?

Thus wrote Yannis Nikolopoulos (dez at otenet.gr):

> >>For example, declaring a specific bit in the address to be 1 for voice
> >>traffic or 0 otherwise.
> >[...]
> >
> >>What should we do about it?
> >As a RIR, nothing.
> 
> what about as one of RIPE's WGs?

The addressing plan within an allocation is the LIRs responsibility, and
if they want to shoot themselves in the foot they may do so. Maybe their
network designer is a genius or they have a special environment, and the
complicated plan they come up with turns out to be gold.

In general, "as simple as you can get away with" is a good aim, though.
It won't only need to look good on paper, it'll need to be useable and
maintainable, too.

> Should we go on and produce a BCP
> document of some kind? As the author of this addressing plan
> 
> (https://ripe67.ripe.net/presentations/222-ripe67-yanodd-ipv6-addressing.pdf) , my main motivation for presenting it was to show that it is possible to encode basic information in an addressing plan (without wasting too much space) and still keep it simple . For example, even IPv4 addressing plans were location-aware, that's nothing new. Well, its even easier and more effective in IPv6 addressing, because of the number of bits available. As far as encoding service type, no space is wasted because it is encoded after the /56 boundary ;) , even making it possible for QOS.

Ok, let me be less terse. I'm not speaking from a scientific research
position but from a gut reaction which is based on some practical
experience.

I think if you want to encode something in the netmask area, you want
to define ranges, not bits, you want to prioritize routing (i.e.,
obviously "location") and keep "magic info" to the really really
basic, like "the '0' subnet is the PoP LAN'", because if the people in
the NOC need to do a drawing of the bits or use a calculator before
they can assign the proper address to a router that'll not be
a happy network (use of tools alleviates that, but the more complicated
your rules the more prone to bugs they will be).

Humans can learn the most amazing feats of pattern matching, given enough
time, but you want to give the new hire who has only been around for 6
months a chance to also immediately *see* that the address given is wrong
in that use context if your routers discriminate on them.

If your network equipment does not use the encoded information,
thus making errors obvious by causing failures, you can expect that
the information encoded is a cute note but not a reliable one.
There's nothing wrong with conventions, especially if they are
entertaining, as long as you remember that that's all they are, and that
they can be put out with the garbage if there is a good reason.

For a network plan I have been involved in, for an ISP with many
locations and expecting growth, we basically said:

We have small, medium, large and huge locations.
We will section up the entire available space in equal chunks.
(this gives a minimum standard network size in the routing table;
customers will cause this to be messed up :)
Each location will get a chunk and when they use it up, another one.
We will try to keep the chunks going to a location contiguous, but no
guarantees. To be able to add contiguous chunks, we will leave gaps
between initial assignments, and the size of the location determines
the size of its gap; initially, group net-near locations next to
each other but also make no promises.
Lowest /64 of the initial assignment is location core LAN, rest of the
lowest /48 are further LANs or transfer addresses: convention, no
guarantees. Should the /48 run out, just take the next free one.

This is fairly simple and hopefully also maintainable.

Additional knowledge about a network may lead to different results;
but it's easy to underestimate growth, or to misjudge where growth
will happen, and when that happens it shouldn't cause too much pain -
especially not sustained pain.

Regarding the addressing plan you made: I don't know your network, you do.
My comments may thus simply not apply because of local conditions.
So, adding this packet of salt:

Not to be snide, but "trusted" is a bad designation :) You know all the
jokes about the evil bit? Being able to immediately see that a fault
is probably your issue is good, trusting large ranges of address space
less so.

Traffic types in front of location prevents aggregation, which is not a
huge issue these days, but still unnessecarily inefficient.
That's also what I don't like about your loopback choice and transfer
addresses choice; your routing table will contain quite a bunch of /128.

Also, having both traffic type and service seems redundant (is there an
issue for network ops to get prefixes configured in a local firewall?
Otherwise I'd expect infrastructure to just be treated as another
service), and lower than /56 you normally leave to your customers
(a case of "local specialties not mentioned" that make you contol
those bits as well?)

No quarrel with encoding the vlan id in the local infrastructure subnet
as long as you agree beforehand to write numbers (hex) or strings;
that's an example of convention. If you write string, the presence
of a letter can mean it's not a vlan.

Your plan of numbering residential customers up and business customers
down will not survive contact with the enemy^Wcustomer unscathed; also
its information content is limited as long as you don't know where the
border is (and that will be different in every location, unless you are
willing to accept large gaps that may not fill), but as a convention, why
not.

I'm missing an explicit plan on how locations get grown. You assume you'll
never run out with a /40?

regards,
	spz
-- 
spz at serpens.de (S.P.Zeidler)