phil@charon.milepost.com (Phil Howard) writes:
The transition to IPv6 is clearly going to have some difficulties. We are waiting on:
1. Network equipment, with translation
2. End user software
3. Address space assignment
nice list.
IPv6-only space is of less value than IPv4-private space until IPv6 becomes at least fully routeable over the Internet. So the backbone networks are going to have to take the lead to make it happen. Even when it is routeable, it has to work on all the ends, which will thus have to have translations to make their IPv4 space appear as IPv6sub4 space.
The best workable scenario I can see so far is one where IOS and other routing software includes translation between IPv4 and IPv6
IOS IPv6 prototype does include that facility. It translates to and from an arbitrary v4 network and an arbitrary v6 network.
Something is thus needed to encourage customers to move into IPv6 even when it is fully routeable.
That is really the key issue... because even with IPv6 NAT (protocol translation) working, IPv6 is as actractive as using IPv4 NAT, unless it brings some value added to the end customers... The potential advantage i see is autoconfiguration support. But DHCP can actually do the same job reasonably well.
But just having IOS translating IPv4 <-> IPv6s4 is not enough.
Agreed.
We will need to manage the new IPv6 network. All the various tools we use will need to understanding IPv6 and how it it configured on the network. Routing will have to work right even during the transition to this, which means BGP4v6 has to be there capable of understanding IPv6 space at some point in time.
BGP4 + Multiprotocol Extensions is able to do the job. And it is working resonably well...
Routing issues will become different in IPv6.
How ?
If IPv6 allocations will have varying sizes like CIDR, then we might continue to have issues of size based route filtering. OTOH, with the right methods of allocating IPv6 space, no one should ever have to come back to get more space. Eventually that should mean fewer routes as IPv4/IPv6s4 closes down. Route filtering should be encouraged on IPv4 space and prohibited on IPv6 space, at that point, IMHO.
I don't think i really understand your point here.... The only "difference" when it comes to routing information i can think off is that in IPv6 there isn't suppose to be address ownership (which creates holes into CIDR blocks)... but it seems to me that the same policy is being adopted for IPv4. Pedro.
On Mon, Nov 03, 1997 at 08:53:11PM -0800, Pedro Marques wrote:
If IPv6 allocations will have varying sizes like CIDR, then we might continue to have issues of size based route filtering. OTOH, with the right methods of allocating IPv6 space, no one should ever have to come back to get more space. Eventually that should mean fewer routes as IPv4/IPv6s4 closes down. Route filtering should be encouraged on IPv4 space and prohibited on IPv6 space, at that point, IMHO.
I don't think i really understand your point here....
The only "difference" when it comes to routing information i can think off is that in IPv6 there isn't suppose to be address ownership (which creates holes into CIDR blocks)... but it seems to me that the same policy is being adopted for IPv4.
Pedro.
Bad model. I said this years ago. 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. 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!) and the remaining space (define it as 32 bits for backward compatibility reasons with IPv4) is private to the ASN. If you change ASNs as a customer, it is between you and the new provider whether you need to renumber - the rest of the world *DOES NOT CARE*. What this leads to is a registry system (one or more) for the 32-bit suffixes in which you form "colloquial" memberships, ensuring uniqueness among competing ASNs *as long as both ASNs subscribe to the same registry*. But membership is VOLUNTARY; you give up nothing except possibly the ability to allow people to join your ASN without renumbering if you don't belong. Right now membership in these registries is MANDATORY; the network breaks if you choose random 32-bit integers and masks and announce them. We can fix this if we think for more than 2 nanoseconds before doing something stupid (again). If you want to connect to an ASN which is *NOT* part of your colloquial group, that's fine too -- but you might need to renumber in that case (or perhaps not - 32 bits is still quite large). With each ASN having 32 bits of *private* address space, the IP space becomes effectively infinite, and the route table size is fixed at one entry per ASN. The best of both worlds. This is also, by the way, trivially backward compatible (heh, what a concept); bitwise masking provides all you need to translate between local and global address formats (these operations are extremely fast, and typically single-instruction-cycle in duration on modern processors). Hardware bit-slice assist on interface boards make it cheap and feasible even at wire rates to translate at the boundaries of an ASN both inbound and outbound. 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. It never ceases to amaze me how people will ignore the obvious solutions to problems like this. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal
What this leads to is a registry system (one or more) for the 32-bit suffixes in which you form "colloquial" memberships, ensuring uniqueness among competing ASNs *as long as both ASNs subscribe to the same registry*.
But membership is VOLUNTARY; you give up nothing except possibly the ability to allow people to join your ASN without renumbering if you don't belong.
Right now membership in these registries is MANDATORY; the network breaks if you choose random 32-bit integers and masks and announce them. We can fix this if we think for more than 2 nanoseconds before doing something stupid (again).
If you want to connect to an ASN which is *NOT* part of your colloquial group, that's fine too -- but you might need to renumber in that case (or perhaps not - 32 bits is still quite large).
draft-odell-8+8-00.txt (expired) suggests something not so different from this. -Phil
participants (3)
-
Karl Denninger -
Pedro Marques -
Phillip Vandry