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