Subject: v6-v4 transition scenarios, take 1

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Jul 2008 16:51:31 +0300 (EEST)

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.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 28 Jul 2008 15:42:32 +0100

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:
> 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.
>

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Jul 2008 20:29:27 +0300 (EEST)

Jari spotted a confusion and suggested another scenario (new item 3); 
here's take 2.

==========

1. ISP offers IPv6-only provisioning as a new service w/ translation

2. ISP moves customers from v4 public to rfc1918, may provide v6

In addition, the ISP may start providing IPv6 service to the customers as 

3. ISP aims at an IPv6-dominant network but customers keep on using v4

Due to alleged O&M simplicity, political/publicity incentives, or 
minimizing the number of public IPv4 addresses, etc., an ISP wants to 
move to an IPv6-dominant infrastructure, eliminating IPv4 where using 
it can be avoided.  Customers may or may not be provided with IPv6 
addresses and connectivity.

Given that customers and local hosts will continue to use IPv4, IPv4 
must be tunneled or translated either at PE routers, CPE routers 
and/or end hosts. Tunneling at PE routers gives significant benefit 
mainly only if tunneling is done at layer 2 (and as a result PE 
routers can be IPv6-only). Tunneling from CPE devices and/or end hosts 
requires that this is offered to customers voluntarily as a new 
service offering.  At the same time, some customers' IPv4 addresses 
may be changed to use private rather than public addresses, further 
reducing the IPv4 address usage.

Customers' IPv4 connecitivity is provided by tunneling IPv4 over IPv6 
to either an aggregating router (when the customer uses public v4 
addresses) or to a NAT device (customer is using private v4 addresses; 
NAT implementation may require minor modifications), from where it is 
further encapsulated or forwarded to other, e.g., border routers. 
Practically it's simplest to leave the ISP's backbone network 
dual-stack at least initially, though.

Most ISP's own systems will likely require some v4 connectivity 
(tunneled or translated) for external connectivity (e.g. software 
patches) for some time.  Likewise, some systems will provide IPv4 
services to the rest of the Internet and/or the customers and will 
require untranslated v4 connectivity. Final stage of ISP's 
infrastructure evolution is described in the next scenario.

4. A greenfield IPv6 deployment needs to provide services to the rest
      of Internet

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

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 4) above).

6. Explicitly not considered scenarios

--
$Id: scenarios.txt,v 1.2 2008/07/28 17:26:41 pekkas Exp $

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Jul 2008 18:42:39 +0100

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.)

> 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.

> 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.  

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.

> 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.

> 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.

>   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.

> requires application-specific proxying mechanisms or an accelerated  

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.

> 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.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Jul 2008 06:19:18 +1200

On 2008-07-29 05:42, Iljitsch van Beijnum wrote:
> (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.)

FYI, there's at least one proposal in the oh-so-serious ITU discussion
of IPTV for a P2P based IPTV delivery mechanism. There are already
P2P based video on demand solutions in the wild. I don't think
you can assume that P2P is not of business interest.

My guess is that dual stack nodes in a mixed v4/v6 P2P network would
become hot spots, with the v4-only and v6-only nodes using them
as convertors. I'd expect P2P networks to be rather successful in
routing around connectivity gaps due to v4/v6.

    Brian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 28 Jul 2008 21:19:51 +0300 (EEST)

On Mon, 28 Jul 2008, Iljitsch van Beijnum wrote:
>> _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...
>
> 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.)

AFAIK, p2p protocols, at least downloading, are smart enough to work 
through a NAT box that doesn't support any ALG, UPNP, port 
redirection, etc.  I have personal experience with this :-). So, does 
this require special casing in NAT64 techniques or are such 
approaches enough client-server -like?
>> 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
>
> I would assume all of this only applies to new customers, addresses for 
> existing customers won't disappear.

So, the ISP may do as they do in Finland: only provide support in a 
0.39 EUR/min phone number. As a result, they're able to downsize their 
support departments.  Think about the revenue opportunities! :-)

The text talks about both new customers, or old ones migrating to a 
new type of service voluntarily.

>> 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.

Sure.  Actually I added conditionals that take care of this in take 2.

> 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.

Agree that this is an issue, but not probably in practise.  Let me try 
to phrase it differently.. "I strongly encourage all my competitors to 
start providing their services as v6-only".

So I don't think there should be a big question about which approach 
is viable and which isn't.

> 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".)

Maybe I should have used s/NAT/translator/, that was certainly the 
intent.  However, in practise given that the intent is to support 
weird v4 hosts and apps in "end-game" situation, it seems improbable 
that an app-specific proxying would be enough.

Wrt dates, I wanted to emphasize that this won't be happening any time 
soon.

> I expect once the IPv6 ball gets rolling people will start turning off IPv4 
> surprisingly fast.

Personally I doubt it -- a lot.  Or we have a different things in mind 
when we talk about "IPv6 ball gets rolling".

I wouldn't turn off v4 on any service I have association with until at 
least 90% and hopefully more than 99% of the user base (or potential 
user base) could reach it.

>> 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.

I guess you're referring to NAT traversal mechanisms such as uPNP, 
NAT-PMP etc.  -- I don't count those as NAT traversal because they 
require modifications in NATs.  Teredo and similar tunneling 
mechanisms which require no NAT modifications are the true traversal 
mechanisms.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: [email-masked]
Date: Mon, 28 Jul 2008 13:34:22 -0600

Pekka Savola writes: 

>> recently that people have stopped whining "you IETF guys said we'd be out 
>> of IPv6 addresses by 2005 and it didn't happen".)
> 
> Maybe I should have used s/NAT/translator/, that was certainly the intent. 
>  However, in practise given that the intent is to support weird v4 hosts 
> and apps in "end-game" situation, it seems improbable that an app-specific 
> proxying would be enough. 
> 

Given the rate that Operating systems are being forced on end users, what is 
the likelihood that non-dual stack systems will be very common by that 
point? I can see a need to take v6 customers to v4 servers, but I do not 
expect that you will have a large percent of users on v4 only hardware or 
operating systems 7 years from now. Now you may have v4 only ISPs or other 
businesses providing services but that is a different issue. 

> least 90% and hopefully more than 99% of the user base (or potential user 
> base) could reach it.

This makes senses 

Eric

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 30 Jul 2008 13:17:53 +0100

On 28 jul 2008, at 19:19, Pekka Savola wrote:

> redirection, etc.  I have personal experience with this :-)

The ones that I've used depend heavily on UPnP (or NAT-PMP) or manual  
port mappings. If you can't receive incoming sessions, it still works  
because most other peers can. But you'll see a marked increase in  
download speeds when you enable incoming sessions because you can now  
connect to a larger set of peers.

> So, does this require special casing in NAT64 techniques or are such  

For the BitTorrent-like stuff you probably don't really have to do  
anything: peers behind NAT64 wouldn't be able to receive incoming  
sessions from IPv4 peers, but they can still have outgoing sessions to  
many IPv4 peers and they should also be able to talk to IPv6 peers in  
both directions. (Although IPv6 firewalls get in the way, but you can  
disable those.)

For SIP ICE should work, especially with endpoint independent mapping  
in the NAT64 box. Other protocols could be upgraded to use ICE as  
well, but for things like BitTorrent this would require significant  
changes to the signaling protocol.

>> I expect once the IPv6 ball gets rolling people will start turning  
>> off IPv4 surprisingly fast.

> Personally I doubt it -- a lot.  Or we have a different things in  
> mind when we talk about "IPv6 ball gets rolling".

> I wouldn't turn off v4 on any service I have association with until  
> at least 90% and hopefully more than 99% of the user base (or  
> potential user base) could reach it.

Right, I was thinking of the client side. There are basically two  
things that I regularly do that I can't do when I run IPv6-only now:  
printing and VoIP. This will only get better over time. (Or I use a  
much smaller set of apps than most people.)

>> 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.

> NAT-PMP etc.

Yes.