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.