Hi Alain, On Fri, 28 Sep 2007 08:45:58 -0400 "Durand, Alain" <Alain_Durand@cable.comcast.com> wrote:
The IETF thinking for the last 10+ years (and I include myself in this) had been that dual stack was the answer and most things would be converted to dual stack before we ran out of v4.
Well, it has not happen.
There is still very little v6 deployment and we will be running out of v4 space soon (instantiate soon by your particular prediction of the day you won't be able to get space from your RIR, either because there is no more or because you do not qualify any longer).
I don't think it has happened because in the past there hasn't been a compelling reason to. End-users haven't seen any benefit, so they haven't asked for it, and service providers (who of course provide services to those end-users) haven't been able to justify the investment, because their end-users/customers haven't been asking for it. If IPv4 addressing runs out, and the only way to grow the Internet is to implement IPv6, then the service providers who've made the IPv6 investment provide access to more services i.e. both IPv4 + IPv6 based, will win customers from their competing service providers. I think the loss of customers to competitors would create a compelling reason for service providers to introduce and migrate to IPv6, and I think a "better Internet experience" (I've been around Internet marketing people too long) i.e IPv4+IPv6 visible content would be the compelling reason for customers to move to service providers who're providing access to both protocols.
Given the above, it is clear that we are gong to see devices (which might be dual stack *capable*) that will be deployed and provisionned with *v6-only*...
At the edge of the network, where we have devices by the millions and where address space is a critical issue and dual-stack is a non starter, this is already under way...
It is also becoming apparent that:
- the "core internet" (ie the web and any infrastructure server) will take a long time to move to v6 and/or dual stack.
- new v6-only edges will have to communicate with it. So we need v6->v4 translation in the core
MPLS as well as the IETF softwires techniques (the MPLS model without using MPLS i.e. tunnel from ingress to egress via automated setup tunnels - gre, l2tp, or native IPv4 or IPv6) can or will shortly be able to be used to tunnel IPv6 over IPv4 or vice versa. softwires in effect treats the non-native core infrastructure as an NBMA layer 2. The advantage of these techniques verses dual stack is that they push the complexity of dual stack to the network ingress and egress devices. Dual stack isn't all that complicated, however when you think about running two forwarded protocols, two routing protocols or an integrated one supporting two forwarded protocols, having two forwarding topologies that may not match in the case of dual routing protocols, and having two sets of troubleshooing methods and tools, I think the simplicity of having a single core network forwarding protocol and tunnelling everyting else over it becomes really attractive. The price is the tunnel overhead of course, however, processing wise that price is only paid at the edges, making it scalable, and in the core, the bandwidth cost of the tunnel overhead is minimal, because the network core typically has all the high bandwidth links.
- legacy v4 PCs (think win95 up to win XP) using RFC1918 addresses behind a home gateway will never be able to upgrade to an IPv6-only environment. So if we provision the home gateway with v6-only (because there will be a point where we do not have any global v4 addresses left for it) those legacy PCs are going to need a double translation, v4->v6 in the home gateway and then v6 back to v4 in the core. Note: a double private v4->private v4->global v4 translation would work too, but if you are running out of private space as well, this is also a non-starter...
While it probably won't be a huge amount, getting rid of forwarding based on end-node IPv4 destination address out of the core will help with this a bit. I wonder if anybody has done a study as to how much public IPv4 address space is consumed by infrastructure addressing.
- there are a number of internal deployment cases where net 10 is just not big enough, thus the idea to use v6 to glue several instances of private space together as a 'super net 10'. For this to work, legacy devices that cannot upgrade to v6 need to go through a translation v4->v6.
I'm guessing you might be in part talking about your cable modem management problem that I've seen an IPv6 presentation of yours about. Is it really necessary to have global reachability to all your customer's CPE for management purposes across the whole of your network? Would it be possible to have e.g. 3 large management regions, each with their own instance of network 10, and then make the infrastructure robust enough that there'd be much bigger problems with your network if the need to remotely manage one group of CPE from another management region became necessary?
So, no, NAT v4->v6 or v6-v4 does not solve world hunger but solve very real operational problems.
I suppose we have to weigh up whether the NAT can of worms is worth openning again with IPv6 to solve operational problems, and losing the chance to have the benefits of end-to-end principle back again for all the end-users of the Internet. I've experienced and seen too many cases where the hidden costs of NAT became unhidden. In those instances, "throwing" public address space at the problem would have instantly destoyed the problem NAT was causing. In IPv4 we have to be a bit careful doing that these days, in the future, with IPv6, we don't. Regards, Mark.
- Alain.
----- Original Message ----- From: Jari Arkko <jari.arkko@piuha.net> To: Durand, Alain Cc: Randy Bush <randy@psg.com>; nanog@nanog.org <nanog@nanog.org> Sent: Fri Sep 28 00:25:11 2007 Subject: Re: WG Action: Conclusion of IP Version 6 (ipv6)
Randy, Alain,
o nat-pt with standardized algs for at least dns, smtp, http, sip, and rtp
-->> This is on my top 3 hot topics. And make it works both way, v4 to v6 and v6 to v4. And also don’t call it NAT-PT. That name is dead.
For what it is worth, this is one of the things that I want to do. I don't want to give you an impression that NAT-PT++ will solve all the IPv6 transition issues; I suspect dual stack is a better answer. But nevertheless, the IETF needs to produce a revised spec for the translation case. Fred and I are organizing an effort to do this.
Jari
-- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"