|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
If we agree that dual-stack can be only needed in a small part of the network (and in my opinion in all the LANs, until all the applications are IPv6-enabled), then you could use private addresses and softwires (LT2P) for automatic tunneling of protocols that you can't proxy to avoid any new translation protocol, break less things and make it all much simple. I will just add proxies (v4<->v6) for protocols such as http, in order to avoid unnecessarily tunneling traffic that can just be proxied. We have this in real customers, so I know it works. Regards, Jordi > De: John Curran <[email protected]> > Responder a: <[email protected]> > Fecha: Sat, 29 Sep 2007 23:10:24 -0400 > Para: Iljitsch van Beijnum <[email protected]> > CC: <[email protected]> > Asunto: Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: > Conclusion of IP Version 6 (ipv6) > > > At 11:13 PM +0200 10/21/07, Iljitsch van Beijnum wrote: >> ... >> If an IPv6-only box is going to talk to the IPv4 world, at some point, the >> traffic needs to hit a dual stack system that can do the IPv6/IPv4 >> translation. >> >> I think an approach where you have a regular IPv4 NAT and then tunnel the RFC >> 1918 addresses over an IPv6-only network would work better than NAT-PT. > > There are companies which would like to be connecting new > customers with IPv6 as we approach IPv4 depletion and then > handle translation for IPv4 site connectivity in their network > i.e. customers connecting to "The Internet" via only IPv6 > with the expectation of reaching all Internet destinations > (IPv4 and IPv6) without any hassles. > > While making the backbone networks dual-stack is going to > be serious work, it's at least an understandable goal that > operators can makes plans to hit. That's not the case with > the requirement to provide transparent connectivity to IPv4 > destinations via IPv6 transport. NAT-PT wasn't exactly an > elegant solution, but it's now precisely what some providers > are looking for (so connecting customers via just IPv6 is at > least viable). Without it, every provider is going to come up > with ad-hoc customer connection models with various IPv4 > tunnelling and translation games once IPv4 address blocks > become generally unavailable. > > The irony is that the I* rationale for moving NAT-PT to historic > was "to restore the end-to-end transparency of the Internet" > and yet the only real chance we have to restore end-to-end > transparency is to first have a transition to the IPv6 (using > dual-stack, NAT-PT, and every other tool at our disposal) and > then over time let present IPv4 destination sites add IPv6 for > end-to-end transparency based on their actual need for it. > Instead, central planning may have effectively killed the very > tool that's needed to allow providers to provision new Internet > customers over a pure IPv6-only model, and create the right > motivation for existing Internet sites to go dual-stack and > actually gain "end to end transparency" via IPv6. > > /John > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
|