From: Vince Fuller (no email)
Date: Fri Jun 01 2007 - 20:20:14 EDT
> At 5:08 AM -1000 5/29/07, Randy Bush wrote:
> > > (*) Anyone advocating staying with IPv4 and relying
> >> on NAT and market demand as an alternative
> >> needs to consider the completely deaggregated
> >> address usage pattern (and routing table explosion)
> >> that results.
> >
> >not that i think this a nice approach or anything, but ...
> >
> >it would seem that the size of the routing table in this case, as in
> >others, is proportional to the number of end sites, pi multi-homed if
> >that is the dominant policy, or pa aggregated if that is the dominant
> >policy.
>
> I respectfully disagree... you'll see addresses being moved out of
> both PA and PI space (particularly PI & legacy) to directly end-sites
> and create enormous pressure on the ISPs to allow end-sites with
> "self-obtained" /32's to have them injected into the DFZ... (This is
> effectively when the utility value of unique IPv4 addresses reaches
> all time high)
>
> Our present routing table issues are nominal compared to the full
> brunt of end site non-hierarchical address usage that results.
Yes, as NAT becomes ubiquitous, a larger number of private networks will
be behind ever smaller prefixes that are assigned to sites so the per-site
prefix length will decrease. The logical end state for this would be /32s.
In some cases, multi-homed end-sites may wish to have those /32s advertised
into the global routing system. If, on the other hand, those end sites were
to transition to ipv6, they would instead obtain "PI" /48s and advertise
those into the global routing system. How is the former any worse than the
latter?
If you think about it, the NAT approach actually offers the possibility of
improved routing scalability: site multihomed with NATs connected to each
of its providers could use topologically-significant (read "PA") global
addresses on the NATs while using the same private address space on their
network. This reduces any renumbering problem to just that for a NAT that
moves (or is replaced) during a provider change. Yes, this sort of poor man's
identifier/locator separation has all sorts of ugliness but it can probably
be made to work. It may even be the path of least resistance versus fixing
ipv6's routing scalability and deploying ipv6.
It will certainly be interesting to see how this all plays out over the next
few years.
--Vince
|
|
|