[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Follow-up work on NAT-PT

Brian E Carpenter wrote:

The IAB request specifically asks for a solution for IPv6-only
hosts. It's long been my view that the primary coexistence strategy
must be dual-stack, but I'm trying to answer the IAB's question.
Finally, from my reading the usefulness of SHANTI is only where the IPv6-only host has an application that appreciates IPv4 parameters (port and address) or the translation itself. Do we expect application developers to widely cater for this scenario, or to make the assumption that "if IPv4 matters we should use the IPv4 stack"? 

No, SHANTI will work out of the box for any application that runs
through a traditional NAT or NAPT without problems *and* has been
upgraded to AF_INET6 sockets. However, applications that require
an ALG with traditional NA(P)T will need to be tweaked, I think.
The question is whether that overhead is justified to get rid of
the problems of NAT-PT?

    Brian

I've been giving thoughts to some of the issues along similar lines.

Here's what I've been thinking of, in terms of a solution space:
Protocol translation that uses IPv6 as a transport, but doesn't do anything other than present IPv4 on an IPv6-only host. 

The way to describe it in shorthand would be:
PT-4-6-4

On the IPv6-only host, add an IPv4 "thing". (interface/driver/whatever).
There's some bootstrap issues regarding bringing up the IPv4 interface - let's defer those for now...
When this IPv4 "thing" talks to another IPv4 host, it will be using IPv4 source/dest and src/dest ports.
Do IPv4-to-IPv6 protocol translation - but now, the extra "twist" - embed the *port* in the IPv6 destination, *above* the IPv4 address. This lets us set up "generic" ALGs, based on covering aggregates for the "special" address space we use for the place where 6-back-to-4 happens. And, we can then set up ALGs on a per-port basis, which are more-specific addresses. And even more fine-grained port+IPv4 ALGs can be set up, e.g. when there is a need to do 4-6-4 for RFC 1918 space. 

Since the host sees IPv4 "natively", no DNS tricks are needed.
There are even a few advanced tricks that can be accomplished, like reverse-port-mapping to request inbound port(s) and possibly inbound port+IPv4 address "reservation". Combined with dynamic DNS, it may be possible to extend the usefulness of a very small number of IPv4 addresses, to support a much larger of "servers" who need reserved ports, although possibly only intermittently. (Think SMTP for hosting, inbound with MX and relay.)
The implementation of things like DHCP (for IPv4) use well-know IPv4 "broadcast" address destination 255.255.255.255. But, having an IPv6 host listen on that address, transmogrified by the mapping including port, means a specific IPv6 address can act as a DHCP server (or relay).
NAT stuff built to handle this has an added advantage - the IPv4 client-side addresses can overlap, since the presumption is that all the hosts already have IPv6 - and can communicate via IPv6. So there would not be any need for support for "tromboned" traffic between pairs of hosts behind this 4-6-4-plus-NAT. The colliding addresses are disambituated in IPv4 by port (assigned by the NAT), and in the NAT back-end by IPv6 address.
There are details to work out, of course. But I think it could be an interesting starting point, which by virtue of presenting an IPv4 interface to the client, avoids most of the NAT-PT issues.
Oh, yeah, one other good thing - there is no requirement that the ALGs or NAT-PT exist on the same network, just that they be reachable via IPv6 natively. So, a small network could point their "ALG default" at an upstream, who then would handle all the NAT-PT stuff (presumably as either a value-add, paid, or bundled service) for access to the V4 Internet. 

Brian D