Re: v6-v4 transition scenarios, take 1

[Jari Arkko <[e-mail]>]

I think the practically relevant cases that we should worry about now 
are scenarios 1 and 2. Scenario 3 IMHO is not a problem until much 
later, and as you mention scenario 4 is also far in the future.

However, I think you are bundling in scenario multiple different 
situations. For instance, there is the original Alain Durand business 
case, where the operator network is made to be IPv6-only. This is very 
different from making the customers IPv6-only.

Jari

Pekka Savola wrote:
> In my comments and on the mike on 
> draft-ietf-v6ops-nat64-pb-statement-req,
> I've asked to describe the transition scenarios we're talking of in a bit
> more detail so we have better context on what we're actually considering.
>
> Below is my attempt to identify the high-level transition scenarios. 
> If you have a major case you're thinking of that's not listed here, 
> feel free to describe it on- or off-list and I'll consider adding it 
> or rephrasing.  Text suggestions are also welcome.
>
> 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...
>
> 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 offering to a new one because withdrawing IPv4 completely 
> would break customers' internal use badly enough to cause outrage. The 
> ISP may or may not be in control of the CPE device.  Almost all nodes 
> in the edge network are dual stack capable and may even use IPv4 
> private addresses in the internal network.
>
> 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.
>
> 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.
>
> 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.  The 
> change is involuntary, and the customer needs to pay a premium rate if 
> it wants to continue getting public v4 address space.  This causes 
> some problems with some customers' internal networks which use 
> overlapping private address space, but the ISP's troubleshooting 
> guides give instructions on renumbering the internal network to a 
> different private address space.
>
> 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".  IPv6->IPv4 NAT service is not 
> generally provided because IPv4 private addressing + NAT is still a 
> workable service. However, on the longer term, the ISP may be 
> interested in piloting a similar v6->v4 NAT solution as above.
>
> 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.  (Due 
> to need to apply software updates, etc. the hosts at the site may also 
> need to communicate with the v4 internet, but that is already covered 
> in previous cases.)
>
> It is unreasonable to expect that IPv4 sites would provide this 
> transition service, so the service provider (or a subcontractor, e.g. 
> its upstream ISP) to provide IPv4 version of these services.  This can 
> be done e.g. using TCP/UDP proxy (an inverse of RFC3142) or a more 
> advanced translator if ALGs or ICMP support is required.
>
> An alternative that does not require translation or proxying is to 
> build an IPv4-over-IPv6 tunnel from service-providing hosts (e.g. web 
> servers) to some point in the topology (e.g. the service provider or 
> its upstream) and assign addresses over that link either permantly or 
> temporarily (this is the original DSTM concept).  Addresses can be 
> assigned with IPv4 /32 netmask which ensures efficient address usage.
>
> Because deploying these services requires the same amount of public 
> IPv4 addresses no matter whether translation or tunneling is used, it 
> seems easier to employ tunneling or similar other deployment 
> strategies to avoid the problem in the first place.  It could also be 
> argued whether the IETF needs to support these kind of deployment 
> choices (at this point) because it's difficult to find a compelling 
> reason why this scenario needs to be created in the first place.
>
> 4. Nearing 2015, ISP wants to ensure its users can reach all the
>    services in Internet, and deploys a v4-to-v6 NAT
>
> Enterprises, content providers, etc. may have problems obtaining 
> enough IPv4 addresses to provide their services over IPv4 even if they 
> wanted to. During the next 5 years, this is not going to be a major 
> obstacle because existing IP address usage can be made more efficient 
> with some O&M expense (and more addresses freed e.g. by moving 
> client-only users behind NATs).
>
> However, some years after the IANA free pool has been exhausted this 
> may become a problem, depending on how much money the content provider 
> is willing to use to obtain public v4 addresses.
>
> 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).
>
> Around the time when this happens, even those ISPs which have wanted 
> to ignore IPv6 as long as they could, may decide that they will need 
> to do something.  (Or the case could be that the ISP still has 
> customers with only v4 capabilities.)  The possible fixes to this 
> problem are to a) deploy v6 to customers (if v4-only customers is rare 
> enough) or b) to provide a v4->v6 translation service for v4-initiated 
> short local handle -type applications.
>
> 5. Explicitly not considered scenarios
>
> a) Deployment being so far that a reasonable content provider might 
> decide to deploy the service using only IPv6 and require that non-IPv6 
> capable users either upgrade or have their connectivity translated for 
> them. (Somewhat similar to case 4) above).
>
> 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.
>
> 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.  App developers (esp. 
> p2p) also have an incentive to add IPv6 support to overcome the NAT 
> traversal problems if uPNP, NAT-PMP, and manual hole punching becomes 
> less and less practical due to NAT functionality moving into 
> ISP-controlled NAT.
>
>
>
>