[EMAIL PROTECTED] wrote:
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.
Apparently I'm not using the same set of assumptions as most of the
other folks here. We all seem to agree that ULA prefixes should stay
out of the DFZ, but I'm not quite sure why aggregatability of ULA space
is a bad thing. At least in my decision process, it doesn't much matter
if the ULA routes I'm receiving are /48's or /45's: my decision to
filter (if I'm doing Internet transit) or accept them (if I'm operating
a metro network) will be the same.
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.
Agreed.
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.
Or, if a site is a member both of a ULA multiverse than the DFZ
universe, it could contain both a 2000::/3 Internet default pointing to
a transit provider, and a fc00::/7 ULA default pointing to your ULA
"core", as you described below.
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.
Agreed.
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.
I would say it a little differently, that ULA addresses should be
recommended for use only for connections to other ULA-addressed networks
outside the DFZ. A site using ULA addresses in this way could also use
Internet addresses (PA or PI) in parallel, allowing hosts to select
2000::/3 addresses when communicating across the DFZ, and fc00::/7
addresses when communicating with other ULA networks.
-Scott
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
