Subject: Modified IPv6 to unmodified IPv4

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 19 Oct 2007 10:05:11 +0200

Several people have said they prefer the modifications that make it  
possible for IPv6 hosts to talk to IPv4 hosts to be on the IPv6 side.  
How about this:

Obviously, we're trying to address the situation where the IPv6 host  
doesn't have a real IPv4 address all to itself. Dual stack or  
softwires will address the situation where that is the case.

So that means NAT. What if we can keep the NAT in IPv4 rather than  
IPv6? So instead of applications talking IPv6 and then having a  
gateway translate and NAT, we have the applications talk IPv4, carry  
the IPv4 over IPv6 and then NAT. The interesting part here is that if  
we integrate the NAT and the translation, we can skip the whole IPv4  
provisioning, because the NATed IPv4 address is of no importance to  
anyone except the application behind the NAT. So we simply use a well- 
known private address here. We also skip the DNS ALG and deal with A  
records directly.

In other words:

A is an IPv6 host
B is an IPv4 server
T is a translator
X is a client app on A
Y is a server app on B

So X thinks it is running on an IPv4 host which has address 10.6.6.6  
(or whatever well-known RFC 1918 address we want to use). In reality,  
A is an IPv6 host with address 2001:db8:31::1. When X wants to talk  
to Y, it looks up the relevant domain name and sees address  
64.0.0.64. So it opens a TCP connection to 64.0.0.64. A then  
generates and IPv6 packet with source 2001:db8:31::1 and destination  
<96 fixed bits>:64.0.0.64. T translates the IPv6 packet into an IPv4  
packet with source 10.6.6.6 and destination 64.0.0.64 and then  
proceeds to NAT, using 2001:db8:31::1 under the hood to demultiplex  
rather than 10.6.6.6 because 10.6.6.6 is implicitly used by ALL  
clients of T. X sees the <address of T>/64.0.0.64 packets and Y may  
or may not notice and subsequently may or may not work around the  
"IPv4 NAT" in the path.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 19 Oct 2007 10:26:00 +0200

On 19-okt-2007, at 10:05, Iljitsch van Beijnum wrote:

[...]

And now let's see if we can make this stateless.

The reason NATs require state is because clients can choose random  
source port numbers which may clash. So we give each client a small  
identifier that determines the range of source port numbers they may  
use. I.e., ID = 1 - 127, source port is 1 + ID bits + 8 bits chosen  
by the client. This limits the number of clients per translator to  
127. Solution: give the translator more IPv4 addresses and encode  
them like this: 0:0:0:0:<translator IPv4 address>:<destination IPv4  
address>. We then use a range of 65536 fake IPv4 private addresses,  
where the IPv6 host selects one based on its IPv6 address such that  
the TCP and UDP checksums are the same for the original IPv6 address  
and the translated and NATed IPv4 address. Only problem is telling  
both sides about the combination of translator IPv4 address, port ID  
bits and client IPv6 address. This could be done with DHCP for the  
client side. So there is SOME state involved for the translator, but  
this is long-term per-client state rather than ephemeral per-session  
state so it may be worth the effort.

---

From: Nathan Ward <[email-masked]>
Date: Sat, 20 Oct 2007 00:32:52 +1300

On 19/10/2007, at 9:05 PM, Iljitsch van Beijnum wrote:

> [...]
> A is an IPv6 host
> B is an IPv4 server
> T is a translator
> X is a client app on A
> Y is a server app on B
>
> So X thinks it is running on an IPv4 host which has address  
> 10.6.6.6 (or whatever well-known RFC 1918 address we want to use).  
> In reality, A is an IPv6 host with address 2001:db8:31::1. When X  
> wants to talk to Y, it looks up the relevant domain name and sees  
> address 64.0.0.64. So it opens a TCP connection to 64.0.0.64. A  
> then generates and IPv6 packet with source 2001:db8:31::1 and  
> destination <96 fixed bits>:64.0.0.64. T translates the IPv6 packet  
> into an IPv4 packet with source 10.6.6.6 and destination 64.0.0.64  
> and then proceeds to NAT, using 2001:db8:31::1 under the hood to  
> demultiplex rather than 10.6.6.6 because 10.6.6.6 is implicitly  
> used by ALL clients of T. X sees the <address of T>/64.0.0.64  
> packets and Y may or may not notice and subsequently may or may not  
> work around the "IPv4 NAT" in the path.

It is unclear to me why one would not just deploy traditional IPv4  
NAPT and regular IPv6 - it works with existing protocols, is  
significantly more simple, and end user hardware is (we are told)  
being worked on.

--
Nathan Ward

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 20 Oct 2007 14:03:00 +0200

> significantly more simple, and end user hardware is (we are told)  

The crucial difference is that in that case, the host must have IPv4  
connectivity. Although building a NATed IPv4 network would at first  
seem easier or not much more difficult than building an IPv6 network  
with some gateways, I think the latter is a better way forward,  
especially as we're getting closer to running out of IPv4 addresses.  
As soon as ISPs start NATing their customers, many people will be  
behind double NAT, which makes it impossible to open up ports to make  
peer-to-peer protocols work through a single layer of NAT.

If the ISP hosts the IPv6-IPv4 gateways, then it's possible to have a  
clean, routed path between the gateway and the end-user, even if a  
site has multiple hosts, which pretty much requires NAT for SOHO  
sites for IPv4 today.

Another advantage is that the gatewayed IPv4 connectivity and real  
IPv6 connectivity go hand-in-hand so users always get both access to  
the legacy IPv4 infrastructure and the new IPv6 infrastructure that  
(hopefully) allows peer-to-peer applications and new protocols that  
would require an ALG with NAT. With regular IPv4 NAT it's still an  
extra hurdle to get IPv6 in there so large numbers of users will have  
to live with reduced transparency for some time.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 Oct 2007 08:11:22 +1300

On 2007-10-19 21:05, Iljitsch van Beijnum wrote:
> doesn't have a real IPv4 address all to itself. Dual stack or softwires 
> will address the situation where that is the case.
> 
> So that means NAT. What if we can keep the NAT in IPv4 rather than IPv6? 
> So instead of applications talking IPv6 and then having a gateway 
> translate and NAT, we have the applications talk IPv4, carry the IPv4 
> over IPv6 and then NAT. The interesting part here is that if we 
> integrate the NAT and the translation, we can skip the whole IPv4 
> anyone except the application behind the NAT. So we simply use a 
> well-known private address here. We also skip the DNS ALG and deal with 
> A records directly.
> 
> In other words:
> 
> A is an IPv6 host
> B is an IPv4 server
> T is a translator
> X is a client app on A
> Y is a server app on B
> 
> So X thinks it is running on an IPv4 host which has address 10.6.6.6 (or 
> whatever well-known RFC 1918 address we want to use). 

That doesn't cover us for the day when we have true IPv6-only apps
with no reptilian memory of IPv4. I think I'd rather avoid the
application having any knowledge of IPv4 at all. If we're going to
do this horrible thing, let's do it 100%. (As Iljitsch knows, I'm
playing with some thoughts on this, but they aren't quite ready for
public ridicule yet.)

     Brian

> In reality, A is 
> an IPv6 host with address 2001:db8:31::1. When X wants to talk to Y, it 
> looks up the relevant domain name and sees address 64.0.0.64. So it 
> opens a TCP connection to 64.0.0.64. A then generates and IPv6 packet 
> with source 2001:db8:31::1 and destination <96 fixed bits>:64.0.0.64. T 
> translates the IPv6 packet into an IPv4 packet with source 10.6.6.6 and 
> destination 64.0.0.64 and then proceeds to NAT, using 2001:db8:31::1 
> under the hood to demultiplex rather than 10.6.6.6 because 10.6.6.6 is 
> implicitly used by ALL clients of T. X sees the <address of T>/64.0.0.64 
> packets and Y may or may not notice and subsequently may or may not work 
> around the "IPv4 NAT" in the path.
> 
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 22 Oct 2007 10:53:38 +0200

On 20-okt-2007, at 21:11, Brian E Carpenter wrote:

>> gateway translate and NAT, we have the applications talk IPv4,  
>> carry the IPv4 over IPv6 and then NAT. The interesting part here  
>> is that if we integrate the NAT and the translation, we can skip  
>> the whole IPv4 provisioning, because the NATed IPv4 address is of  
>> no importance to anyone except the application behind the NAT.

> do this horrible thing, let's do it 100%.

Well, the way I see it there are four permutations:

1. both the IPv4 and IPv6 ends are unaware of the translation
2. the IPv4 end is aware of the translation, the IPv6 end isn't
3. the IPv4 end isn't aware of the translation, the IPv6 end is
4. both ends are aware of the translation

The first case, in the form of NAT-PT has fallen into disfavor within  
the IETF for a variety of reasons, my favorite being that it imports  
NAT issues into IPv6. Personally, I believe that there is no way to  
resurrect a type 1. approach that doesn't have much the same issues,  
but I'd be happy to be proven wrong.

If 1. is out this basically leaves either modifying IPv4 hosts so  
they can talk to unmodified IPv6 hosts, or modifying IPv6 hosts so  
they can talk to unmodified IPv4 hosts. The former has the advantage  
that it keeps IPv6 clean, the latter is more pragmatic because a good  
part of the IPv4 installed base is presumably unupgradable.

Alternatively, we could go for 4. (or rather, 2. + 3.) and come up  
with something where one end is modified and the other isn't, and let  
the operators figure out if and where they want to place the burden  
of extra protocol layers to talk to the other protocol.

It would be good if the wg could decide on which direction is best,  
so that we can start work in that direction.

---

From: james woodyatt <[email-masked]>
Date: Mon, 22 Oct 2007 10:38:31 -0700

On Oct 22, 2007, at 01:53, Iljitsch van Beijnum wrote:
> they can talk to unmodified IPv4 hosts. The former has the  
> advantage that it keeps IPv6 clean, the latter is more pragmatic  
> because a good part of the IPv4 installed base is presumably  
> unupgradable.

There is one significant way that unmodified IPv4 applications will  
never be able to manage communicating with IPv6-only peers, i.e. when  
their peers store their translated IPv6 addresses in some persistent  
storage, like a logfile or a web page or a report or anything  
generally intended for offline automated analysis, and the IPv4-only  
application needs to do that and finds that it can't cope with its  
address being translated out of the IPv4 address family.

The reverse of this is not a problem.  IPv4-only applications need to  
be upgraded for IPv6 if they expect to communicate effectively with  
IPv6-only peers.  IPv6-only applications can get along just fine  
using IPv4-compatible IPv6 addresses (or some other address type  
representing the IPv4->IPv6 function) when keeping track of the  
translate IPv6 addresses of their IPv4-only peers.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Oct 2007 10:42:34 +1300

Iljitsch,

On 2007-10-22 21:53, Iljitsch van Beijnum wrote:
...
> 4. both ends are aware of the translation

...
> It would be good if the wg could decide on which direction is best, so 
> that we can start work in that direction.

I agree, and I'm in no doubt that 3 is best. 1 is already discredited,
and 2 and 4 don't help the true IPv4 legacy hosts.

     Brian

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 22 Oct 2007 16:42:09 -0500

Thus spake "Brian E Carpenter" <[email-masked]>
> playing with some thoughts on this, but they aren't quite ready for

Will code like that ever exist?  The changes to the sockets API (e.g. 
getnameinfo() and getaddrinfo()) has made it so that modern apps aren't any 
more v4-aware than they're v6-aware; they've become version-agnostic, not 
separately aware of v4 and v6, unless they have a specific reason to know.

The problem I think you're indirectly referring to is NAT awareness, and 
most of the problem there is going to exist in v6 with stateful firewalls 
even if we do manage to avoid creating a NATv6 world.  ALGs are simpler when 
you only have to inspect packets, not mangle them, but they're not going 
away, and end hosts/apps can't get away from coping with 
administratively-imposed reachability problems.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Oct 2007 11:16:14 +1300

On 2007-10-23 10:42, Stephen Sprunk wrote:
> getnameinfo() and getaddrinfo()) has made it so that modern apps aren't 
> any more v4-aware than they're v6-aware; they've become 
> version-agnostic, not separately aware of v4 and v6, unless they have a 
> specific reason to know.

Correct. I think the tricks that have to be played are below the
socket interface. (Although there is the residual problem of applications
that ignore RFC 1958, RFC 2101 and RFC 2775 by storing IP addresses for
future reference, but that is probably insoluble.)

> most of the problem there is going to exist in v6 with stateful 
> firewalls even if we do manage to avoid creating a NATv6 world.  ALGs 
> are simpler when you only have to inspect packets, not mangle them, but 
> they're not going away, and end hosts/apps can't get away from coping 
> with administratively-imposed reachability problems.

Unfortunately I believe you are correct; this has to be an exercise
in damage limitation.

    Brian

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 23 Oct 2007 07:33:29 +0900 (JST)

> future reference, but that is probably insoluble.)

	for the new deployment of applications, there are middleware (so to
	speak) from freebit corporation, which allows the following:
	- application be IPv6-only
	- middleware deals with all the troubles of IPv6-over-IPv4 and stuff
	- OS kernel can be IPv4-only, if OS kernel is IPv6-only then the
	  middleware will do nothing

	this may help us for the new applications.

	about NAT and stuff, I think NAT-PT is the necessary evil.  it was too
	early to deprecate NAT-PT.  my assumption was below:
	- IPv6 to IPv6 is without NAT
	- IPv6 to IPv4 is somehow connected, with NAT-PT
	- IPv4 to IPv6 is - well, it is a bit difficult but maybe NAT-PT
	  with wacky DNS mapping
	- IPv4 to IPv4 is with or without NAT (today's situation)
	the point is to keep IPv4 to IPv4 just like today, keep IPv6 to IPv6
	to follow end-to-end principle, and end nodes must not be modified.

	note that there are commercial products available for NAT-PT, so you
	can deploy it today.  if you talk about new technology development
	today, it won't hit the market before 2010.

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 23 Oct 2007 11:07:29 +0200

On 22-okt-2007, at 19:38, james woodyatt wrote:

> never be able to manage communicating with IPv6-only peers, i.e.  
> when their peers store their translated IPv6 addresses in some  
> persistent storage, like a logfile or a web page or a report or  
> anything generally intended for offline automated analysis, and the  
> IPv4-only application needs to do that and finds that it can't cope  
> with its address being translated out of the IPv4 address family.

True.

However, the case that I find more interesting is that of IPv6-aware  
applications running on hosts that only have IPv4 connectivity. In  
that case, it's possible to address this scenario. For instance, when  
the application wants to talk to an IPv6 address, it can set up a  
session through a dual stack proxy.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 23 Oct 2007 11:15:31 +0200

On 22-okt-2007, at 23:42, Stephen Sprunk wrote:

> The problem I think you're indirectly referring to is NAT  
> awareness, and most of the problem there is going to exist in v6  
> with stateful firewalls even if we do manage to avoid creating a  
> NATv6 world.  ALGs are simpler when you only have to inspect  
> packets, not mangle them, but they're not going away, and end hosts/ 
> apps can't get away from coping with administratively-imposed  
> reachability problems.

NAT and stateful firewalling don't have the same effect on applications.

In both cases, an ALG can make everything work for many applications  
if an ALG is available for the protocol in question and the control  
traffic isn't encrypted, and doesn't use options that the ALG doesn't  
understand. ALGs also require a control channel, so they don't  
address the situation where an application is simply listening for  
incoming sessions.

Alternatively, applications can reach out to the NAT or firewall and  
receive information about the public address from the NAT and open up  
incoming ports on the NAT or firewall. There are two non-IETF  
protocols to do that for NAT and a whole bunch of IETF protocols to  
do this for (IPv4?) firewalls. The difference between the NAT and the  
firewall case is that in the NAT case, the application must know  
about the public address, while in the firewall case it only has to  
open up the port. Conceivably, this could be done automatically by  
the OS when a listening socket is created. But such a simple solution  
doesn't address all NAT issues.

So the need to deal with firewalls doesn't mean it's a good idea to  
go ahead with NAT in IPv6, either explicitly or in the form of  
adopting an IPv6/IPv4 translation mechanism that exposes IPv6  
applications to NAT.

---

From: David Miles <[email-masked]>
Date: Thu, 25 Oct 2007 22:14:23 -0500 (CDT)

Iljitsch,

We have been taking a look at impacts of double NAPT and there is an
interesting paper on P2P friendly NAPT from Bryan Ford, Pyda Srisuresh
and Dan Kegal. Take a look at section 3.5
Peers Behind Multiple Levels of NAT.

http://www.brynosaurus.com/pub/net/p2pnat/

I don't think anyone is suggesting IPv4 with NAPT is a IPv6 alternative,
but more a complementary one that has become a necessity given how late we
have left things. During the transition period to IPv6 there will be a
mixture of IPv4-only, and IPv6-capable hosts - we are dealing with two
distinct issues: The exhaustion of IPv4; and, the transition to IPv6.
Implementing IPv6 in the provider network is comparitivly easy compared to
changing all the clients to support it.
Some fear that work to support continued IPv4 use will undermine the
transition to IPv6 - the industry as a whole must move forward with one
voice: IPv6 is the future, but we will not abandon IPv4 on D-day.

Addressing Peer-to-Peer, provider NAPT and NAT-PT/NAT46 should be items we
the industry take on. We can forsee these issues today, now we need to
agree whether we sholud do something about them within the IETF.

  Regards,

David Miles

On Sat, 20 Oct 2007, Iljitsch van Beijnum wrote:

>> It is unclear to me why one would not just deploy traditional IPv4 NAPT and 
>> regular IPv6 - it works with existing protocols, is significantly more 
>> simple, and end user hardware is (we are told) being worked on.
>
> connectivity. Although building a NATed IPv4 network would at first seem 
> easier or not much more difficult than building an IPv6 network with some 
> gateways, I think the latter is a better way forward, especially as we're 
> getting closer to running out of IPv4 addresses. As soon as ISPs start NATing 
> their customers, many people will be behind double NAT, which makes it 
> impossible to open up ports to make peer-to-peer protocols work through a 
> single layer of NAT.
>
> If the ISP hosts the IPv6-IPv4 gateways, then it's possible to have a clean, 
> routed path between the gateway and the end-user, even if a site has multiple 
> hosts, which pretty much requires NAT for SOHO sites for IPv4 today.
>
> Another advantage is that the gatewayed IPv4 connectivity and real IPv6 
> connectivity go hand-in-hand so users always get both access to the legacy 
> IPv4 infrastructure and the new IPv6 infrastructure that (hopefully) allows 
> peer-to-peer applications and new protocols that would require an ALG with 
> NAT. With regular IPv4 NAT it's still an extra hurdle to get IPv6 in there so 
> large numbers of users will have to live with reduced transparency for some 
> time.
>