>> > With the current draft, that is correct. With Paul's proposed changes >> of >> > 27 Jun, they definitely aggregate at the LIR and RIR levels, making it >> > much harder to defend the position that they won't end up in the DFZ. > > the aggregation present in that version was unintentional. if you look at > the actual <http://sa.vix.com/~vixie/ula-global.txt> you'll see that it > recommends that allocations be deliberately nonaggregatable. > >> I'm not quite following your logic here. If ARIN allocates ULA-G space >> from a distinct netblock, how does that make it any harder for transit >> providers to filter routes from fc00::/7, reduce their incentive to do >> so, >> or create an incentive not to? > > my concern about aggregation is that if someone receives 8 /48's that are > aligned as a /45 then they could conceivably advertise it as a /45. i > hope > that IANA will allocate nonaligned blocks, or perhaps give even numbers to > one RIR and odd numbers to the next, and that the RIRs and LIRs will do > likewise.
Aggregation - bane or boon? Depends on whether it's in the DFZ or not. However, here are some observations, which might at some point be paraphrased by someone, along with elements of other postings by me and lots of other smart folks, into a document to serve as an IPv6 "primer" for both new participants in the v6 world, and old-timers... The notion of "default" is a bit of a problem, when you have both the DFZ "universe" and the ULA-* multiverse (which is what ULA's are). Each group of connected ULA "sites", is its own little internet. Or intranet, or extranet, depending on what floats your boat. There can, and will, be zillions of these, including overlapping domains which individual ULA sites are members of. Fundamentally, the DFZ doesn't care what happens outside of the DFZ. And as long as the tech works everywhere, to achieve the desired goals, that should be enough. The thing we need to be concerned about is not only route leakage, but packet leakage, especially if it has the ability to affect the core infrastructure, e.g. DNS. Here's what is interesting about both the ULA space(s) as proposed, and the DFZ space. Each is allocated out of a block which is easily identifiable, and not only that, but which can serve as a covering aggregate (or a few covering aggregates, if need be). And in each routing domain (DFZ or ULA multiverse), the concept of default is generally restricted to members of that domain. So, Best Common Practice should be to never install a true default route, except when also installing covering aggregates for both spaces, the other of which points to the bit bucket. E.g. in the DFZ, have ULA covering aggregate pointing to null0. E.g. in any ULA site or collection of sites, have DFZ covering aggregate pointing to null0. E.g. in both spaces, only install ::/0 if the corresponding example above is also installed. Also interesting is the fact that in ULA routing domains (of which there can be zillions), scalability can be achieved on the routing side, when the topology happens to lend itself accordingly, by having any "core" site carry lots of ULA routes, and "edge" sites carry a ULA aggregate pseudo-default which points towards the core site. All of this, again, points towards my earlier observation. ULA-* should be recommended only for use when there is no desire or need to directly participate in the DFZ. Brian Dickson -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
