Subject: Re: [Int-area] IPv4 and IPv6 Co-existence discussions in Dublin

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 6 Aug 2008 12:00:11 +0200

On 18 jul 2008, at 18:22, Mark Townsley wrote:

> If the subscribers are in turn given private IPv4 address space, the  
> tunnels would be connected to an IPv4 NAT device that serves  
> multiple subscribers, potentially
> requiring a device that serves a very large number of translations  
> as well as tunnels.

> It is suggested that this is a work item that fits the SOFTWIRE WG,  
> and the INT ADs will be sending off a recharter proposal for this WG  
> to examine this particular problem space and develop a solution  
> accordingly.

[...]

> We believe that, on balance, the benefits outweigh the costs on  
> developing a standard method for translation of IPv4 and IPv6. This  
> will likely have a smaller scope, at least in the short term, than  
> the original NAT-PT though it will inevitably share some of the same  
> limitations.

Let me once again emphasize that the two approaches are very similar  
when it comes to the translation part.

The scenario where a regular tunnel is terminated and IPv4 packets  
with RFC 1918 source addresses are then translated by a NAT44 is  
rather suboptimal because it requires configuration/provisioning of an  
address to the source host that is unique within the scope of the  
NAT44. Dual stack lite avoids this issue by demultiplexing tunneled  
packets based on the IPv6 source address in the outer header rather  
than the IPv4 source address in the inner header. This way, the IPv4  
source address is of no consequence to any processing steps so it  
doesn't have to be unique and no configuration/provisioning is  
necessary.

The interesting thing here is that this makes dual stack lite  
processing extremely similar to NAT64 processing. The only difference  
is the presence of an additional IPv4 header in the packets. However,  
if we copy the inner IPv4 source address to the lower bits of the  
outer IPv6 source address and the inner IPv4 destination address to  
the lower bits of the outer IPv6 destination address (as well as other  
relevant fields), the inner IPv4 header can be completely ignored for  
outgoing packets and be generated from the IPv6 header for incoming  
packets so there is no practical difference between the two solutions  
as far as the translator is concerned.

As such, it's very important that we create only a single  
specification for a translator that can accommodate both NAT64 and  
dual stack lite to minimize work on the part of vendors and maximize  
deployability.

In addition, having these two slightly different approaches at our  
disposal side by side allows us to do another thing: we can optimize  
dual stack lite for optimum backward compatibility and NAT64 for  
optimum transparency. I.e., for dual stack lite, vendors can apply  
their existing ALGs, because all the address fields in protocols  
carried in dual stack lite will be IPv4 address fields, so existing  
NAT44 ALGs can be applied without change.

Because systems requiring extensive backward compatibility with IPv4  
can use dual stack lite, this removes the burden of having to provide  
backward compatibility hacks from NAT64, which can thus be kept  
completely ALG-free. This is architecturally desirable, but also  
practical, because IPv6 hosts using NAT64 would use IPv6 addresses for  
referrals, requiring additional work to modify ALGs.

As a result, we end up in a situation where we can both have good  
backward compatibility and maintain a good level of architectural  
cleanliness in IPv6, all of this without undue duplication of effort  
because we only need to specify a single set of translation behaviors.
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 6 Aug 2008 13:26:51 +0300

On Wednesday 06 August 2008 13:00:11 ext Iljitsch van Beijnum, you wrote:
> NAT44.

I consider that uniqueness is a feature... it allows seamless connectivity 
within the realm in question.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 7 Aug 2008 09:46:34 +0200

> within the realm in question.

RFC 1918 is non-unique by nature. You can of course strive for  
uniqueness within a limited context, but in the case of NAT by a  
service provider this is going to be really, really hard because the  
service provider then has to impose an RFC 1918 numbering scheme on  
its customers.

With dual stack light none of this is necessary because the IPv6  
source addresses are unique, even if there is a non-unique RFC 1918  
address in the source address field of the inner IPv4 header.
_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area