Thus wrote Yannis Nikolopoulos (dez@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@serpens.de (S.P.Zeidler)