Subject: Re: Follow-up work on NAT-PT

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Oct 2007 12:48:10 +1300

On 2007-10-14 06:28, Jari Arkko wrote:
> Thanks for this, Olaf. Indeed, we are considering follow-up work,
> and understanding the scenarios & possible need for producing
> a revised version of NAT-PT is on the Vancouver agenda (currently
> planned to be a discussion in V6OPS, with protocol work to fall
> out to an INT area WG).

I realise this may be jumping the gun a bit, but since I won't be
in Vancouver, here is a sketch of one possible direction.

     Brian

-------- Original Message --------
Subject: I-D Action:draft-carpenter-shanti-00.txt
Date: Sun, 28 Oct 2007 18:20:01 -0400
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Shimmed IPv4/IPv6 Address Network Translation Interface (SHANTI)
	Author(s)       : B. Carpenter
	Filename        : draft-carpenter-shanti-00.txt
	Pages           : 12
	Date            : 2007-10-28

There is a pragmatic need for a packet-level translation mechanism
between IPv4 and IPv6, for scenarios where no other mode of IPv4 to
IPv6 interworking is possible.  The mechanism defined here uses a
shim in both the translator and the IPv6 host to mitigate the
problems introduced by stateless translation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-shanti-00.txt

---

From: David Miles <[email-masked]>
Date: Tue, 30 Oct 2007 00:47:16 +1100

Brian,

In the introduction I'd suggest we add some words to clarify that the  
scope of v4-to-v6 translation is not broadly "IPv4 to IPv6", but a  
specific case where a IPv6-only host is modified (with the inclusion  
of a shim and possibly DNS resolver changes) to allow it to leverage a  
separate device (the translator) to access the IPv4 Internet. Also  
consider the readability of the draft (your intro is very detailed)  
and adding a section about the placement of the translator?

I'm afraid that we need to push the IPv6 component of your proposal  
much closer to the IPv4 host appreciating the dire situation with  
globally routable IPv4 addresses. As it stands SHANTI would most  
likely be deployed with both v6-host and translator in a closed  
administrative environment, but I'd like to consider the bigger  
challenge of these v6-only hosts communicating with v4-only hosts over  
a IPv6 Internet (rather than an IPv4 one). I'm not sure you were  
trying to take on something that big, but I thought I'd shoot the  
question through.

I'm interested to hear your thoughts on IPv6-only hosts (as opposed to  
dual-stack hosts) during the IPv4-to-IPv6 transition period. The work  
I've been doing up till now has made a fundamental assumption that we  
would see only v4-only and dual-stack hosts, assuming that only post  
IPv4 shutdown would we see an emergence of IPv6-only devices.

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

Best Regards,

-David Miles

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Oct 2007 09:40:26 +1300

On 2007-10-30 02:47, David Miles wrote:
> specific case where a IPv6-only host is modified (with the inclusion of 
> a shim and possibly DNS resolver changes) to allow it to leverage a 
> separate device (the translator) to access the IPv4 Internet. 

Sure, that's the scenario (or possibly "to access a residual fragment
of the IPv4 Internet" at some much later stage).

> Also 
> consider the readability of the draft (your intro is very detailed) and 
> adding a section about the placement of the translator?

Agreed; this is a first cut rapidly transcribed from the whiteboard.

> 
> I'm afraid that we need to push the IPv6 component of your proposal much 
> closer to the IPv4 host appreciating the dire situation with globally 
> routable IPv4 addresses. As it stands SHANTI would most likely be 
> deployed with both v6-host and translator in a closed administrative 
> environment, 

I don't think that is required, but it seems likely that a network
wishing to support IPv6-only hosts would choose to deploy SHANTI
translators at its edge. However, the reason that only standard
IPv6 addresses are used is so that there are no topological
restrictions on where the translators are placed.

> but I'd like to consider the bigger challenge of these 
> v6-only hosts communicating with v4-only hosts over a IPv6 Internet 
> (rather than an IPv4 one). I'm not sure you were trying to take on 
> something that big, but I thought I'd shoot the question through.

Well, in that case your translator, however it works, has to be
close to the fragment of IPv4 that the v4-only host is attached
to. That will apply even if the fragment is a single PPP link.
I wouldn't recommend SHANTI for that, probably.

> IPv4 shutdown would we see an emergence of IPv6-only devices.

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.

> 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

---

From: Brian Dickson <[email-masked]>
Date: Mon, 29 Oct 2007 18:54:55 -0400

Brian E Carpenter wrote:
>> (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"?
>
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