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 protected] https://www.ietf.org/mailman/listinfo/int-area
