v6-v4 transition scenarios, take 1

[Pekka Savola <[e-mail]>]

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.