Re: Follow-up work on NAT-PT

[briand@ca.afilias.info]

> On 2007-10-30 11:54, Brian Dickson wrote:
>> 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.
>
> I'm not sure how this is different from Bump in the Stack (RFC 2767)
> or Bump in the API (RFC 3338), as you describe it above.
> Or are you closer to DSTM?
> http://tools.ietf.org/id/draft-ietf-ngtrans-dstm-overview-00.txt

It *does* bear some superficial resemblence to elements of all 3, but
is very different from any of them.

Both BIS and BIA, presume native IPv4 on the dual-stack host.
What they both offer, is the ability to offer a fake IPv4 path between
*two* IPv6 hosts. What I'm talking about is a means for an IPv6-only
host to access an IPv4 only host via one or more ALGs/NATs, by
presenting an IPv4 interface to the IPv6-only host.

This concept, 4-6-4, is a mechanism to provide what appears to the host
itself, as if it has native IPv4 connectivity (i.e. dual stack), and doing
something different from straight IPv4-in-IPv6 tunneling.

Instead of tunneling, or vanilla SIIT, it adds the twist which allows
identification of the specific ALG via IPv6 routing.

By directing traffic to the ALG on the native IPv6 network, the scaling
of both the individual ALGs, and the management of and placement of the
ALGs, scales much better. ALGs can be added on a per-port basis, can
be multiplex by IPv6-only load-balancers, or supported by any number of
networking tricks, devices, or topological niceties, all of which can
be IPv6-only, and (aside from the specific IPv6 prefixes used), ignorant
of the fact that any of this traffic is 4-6-4 traffic.

The one other significant difference is the concept of maintaining any
NAT state in the mapped V6 addresses, meaning v4 addresses can be used
simultaneously by multiple 4-6-4 client hosts, thus allowing much more
scalable deployment on the 1918 side of the NAT.

In fact, for maximum scalability, hosts in the 4-6-4 universe could all be
given identical IPv4 1918 addresses, and this would still work. Imagine
the ease of managing clients when they could all be configured with
192.168.1.2 as their IPv4 address. :-)

Brian D

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