[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: v6-v4 transition scenarios, take 1

On 28 jul 2008, at 14:51, Pekka Savola wrote:
As an observation after writing this, I'm focusing pretty much only on client-server type applications because I've yet to see p2p or other _inter-domain_ applications that are business critical. Another reason may be that I don't know them in detail, and that will likely require application-specific transition scenarios, not just ALG extensions. But I'm willing to be convinced otherwise...
VoIP in general and Skype in particular are rapidly becoming business critical for many people. Peer to peer downloading isn't "business" critical but you're sure going to hear from users if you break this. (Don't forget that web and mail doesn't sell 20 Mbps ADSL2 connections, that stuff works fine on 1 Mbps, many users buy faster links because of the peer to peer stuff, it's bad business for ISPs to break this.) 


1. ISP offers IPv6-only provisioning as a new service offering using
  translation or tunneling
Due to IPv4 exhaustion (public or private space), due to alleged O&M simplicity, an ISP prefers to provision a futuristic green field deployment or residential or small enterprises only with global v6 addresses. This requires customers to move voluntarily from old service
First rule of ISP operations: never, EVER make your users migrate to something new, this costs a fortune in support calls.
I would assume all of this only applies to new customers, addresses for existing customers won't disappear.
Because the vast majority of content is still available only with IPv4, the service provider must provide a translator service at least for IPv6-initiated short local handle -type applications. In this scenario, IPv4->IPv6 initiated communication is not required. Because the change in service offering is voluntary, some reconfiguration in customer's equipment is acceptable; host upgrades should be avoided if possible. 

Ok...
An alternative to translation strategy is akin to simplified DSTM (ie. Alain Durand's tunneling approach). The tunneling approach is easier to deploy but it does not take IPv6 deployment much further as the edges still keep using IPv4.
Right, the advantage of NAT64 is that it breaks the no eyeballs on v6 - > no content on v6 -> no eyeballs on v6 cycle. The advantage of dual stack light is that you can continue to run IPv4 stuff. 


2. ISP provides IPv6 as an additional option to v4 private addressing
  + NAT but does not offer translation
Due to IPv4 exhaustion, an ISP stops providing public IPv4 addresses through DHCP to its residential, SOHO and small enterprise customers. Instead, it provides only private IPv4 addresses and NATs these.
In addition, the ISP starts providing IPv6 service to the customers as a way to show the users this is actually "the good thing for the continued health of Internet".
Or they don't, because they are too busy keeping all the different instances of the same RFC 1918 addresses straight... That would be bad. 


3. A greenfield IPv6 deployment needs to provide services to the rest
  of Internet
Due to IPv4 exhaustion or due to alleged O&M simplicity, a futuristic enterprise, ISP, content provider or similar deploys its internal infrastructure using only IPv6. However, it still seeks to provide the services to IPv4 users in Internet; those users which have IPv6 connectivity are able to use them over IPv6. IPv4 users must either be translated near the user or the service provider. As such, v4-initiated local handle -type applications must be supported.
The big question here is on whom the burden of the translation falls. If it's the job of the greenfield people, then it's easy because they can just get an IPv4 address (perhaps even just a port for each service on a shared address), publish the IPv4 address and set up a static mapping.
If on the other hand the IPv4 clients must arrange for their own translation, this means a generic IPv4-to-IPv6 NAT (NAT46), which is much tougher than the other way around. 


4. Nearing 2015, ISP wants to ensure its users can reach all the
  services in Internet, and deploys a v4-to-v6 NAT


Is it a given that NAT is the appropriate option in this case?
Many protocols support proxies, where the name-to-address translation happens at the proxy so if the proxy supports IPv6, the client doesn't have to.
(I don't think it's a good idea to mention dates, though. It's only recently that people have stopped whining "you IETF guys said we'd be out of IPv6 addresses by 2005 and it didn't happen".)
Sometime in 2015-2020 range it may be that the pain of providing IPv4 services becomes so big that some significant content providers want to stick to just IPv6 (and don't even want to pay for someone else to deal with this problem for them as in scenario 3) above).
Right. I've found myself say to customers "this would be easy with IPv6" regularly in recent years.
I expect once the IPv6 ball gets rolling people will start turning off IPv4 surprisingly fast.
b) Such complex services (e.g. SIP, possibly p2p apps) which are not easily translateable or proxyable that if users exist in both IP versions, communication between these is a major challenge and requires application-specific proxying mechanisms or an accelerated IPv6 deployment.
Note that ICE can apply to IPv6 as well as IPv4, and even though we don't plan on having NAT in IPv6 itself, we probably still need ICE for firewall traversal so I expect to see ICE in more and more peer to peer applications. BitTorrent-like applications that don't require each peer to be reachable for every other peer have a very easy transition path: as long as you have at least 10% or so dual stack peers it works without trouble.
IPv4 exhaustion is not causing major problems for these applications as these already have a pretty good NAT traversal mechanisms and those mechanisms are likely to get better over time.
Many of the currently used NAT traversal techniques don't work well with multiple layers of NAT, and with more users behind an IP address it will be harder for users to open up ports to host incoming sessions. So I don't think this is necessarily true.