North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: moving to IPv6
Karl Denninger <karl@Mcs.Net> writes: > IPng needs to have enough *prefix* length that every autonomous system > currently in existance or which will come into existance during its lifetime > can have a *unique*, *single* prefix. This has the advantage of maximizing site aggregation, however it has the disadvantage of scaling badly with respect to the number of sites. > Then the whole address ownership issue becomes moot - each ASN becomes a > prefix (heh, now that's novel - why not just use the ASN > - duh!) Sure, but the problem is not now who deserves a /19 but who deserves an ASN. Moreover, there is no plan in place for a hierarchical distribution of AS numbers, and ASes are not laid out very hierarchically (or in any kind of useful order) right now. If a very strict limit were placed on the number of ASes in this type of Internet, then distributing connectivity maps likely would be tractable; this leads into discussions about a global link-state routing protocol, some of which happen from time to time for other reasons. However, if you are not prepared to refuse to give out AS numbers to anyone who wants one, you will run into the same political problems as refusing to give out provider-independent addresses to anyone who wants some. Alternatively, if you provide a mechanism for aggregation of ASes (and don't go mad in the process), thus implying hierarchical routing, then your idea is workable, except that suddenly there is no difference between the semantics of your ASN+IPADDR and the IPv6 provider-based addressing scheme. The big difference would be in the requirement that only a fixed-size field be routed upon, which is very much like imposing prefix-length filtering on IPv6 addresses. The only known means for any IP-like protocol to scale to complex topologies is hierarchical routing. This imposes constraints on address assignment. There is no way around these constraints other than abandoning topological complexity or routing efficiency. I believe that the functionality you are trying to achieve is having a system in which renumbering is unnecessary when a change is made in the physical topology, or where address uniqueness is not guaranteed. NAT is currently the appropriate technology to be used in both cases, and has the advantage that no NAT-friendly deployed software needs to be changed to talk a new protocol. > This kind of logical design, of course, cannot be allowed to happen within > the realm of the Internet, which is why we'll never see it in our lifetime. Why not? NATs delineate two addressing scopes, and protocol translating NATs are an extension of this. Pablo Bevilacqua has already pointed out an existing implementation from OFRV. There is no reason why a series of NATs which each border on different IPv4 addressing scopes cannot share a common protocol and addressing region on the "outside" of each of these IPv4 addressing scopes. That is, among a group of NATs there is no strict need to run IPv4, so long as straightforward translations into and out of the local IPv4 addressing scopes are possible. Consequently, there is no reason why some part of the Internet cannot test or even deploy your hypothetical protocol. Personally I encourage you to go for it; there is alot we need to learn about what ought to be "in the middle" to keep the Internet permanently scalable, and the concept of protocol translating NATs needs some thorough deployment experience. Sean.