Subject: Re: Fwd: I-D Action:draft-van-beijnum-modified-nat-pt-02.txt

From: Brian Dickson <[email-masked]>
Date: Mon, 03 Dec 2007 14:39:25 -0800

Iljitsch van Beijnum wrote:
> Hi,
>
> I've updated my modified NAT-PT draft (again). It now includes:
>
> - changes to NAT-PT in the form of using A records directly rather 
> than syntetic AAAA records so no DNS issues
> - synthetic RFC 1918 source address coupled with the above allows for 
> applications to see that they're doing IPv4 rather than IPv6 and that 
> there is NAT involved
> - the above allows for non-IPv6 applications to work
> - IPv4-to-IPv6-to-IPv4 translation without double NAT
> - a mechanism for IPv6-only hosts to receive incoming sessions from 
> the IPv4-only world
>
> Please note that this is a discussion document, I'm not suggesting 
> that everything in it is adopted as-is.
There were some ideas I floated in reply to Brian Carpenter's SHANTI 
proposal, which look like they may better fit in with your work - 
indeed, they look very similar, with one extra feature that allows for 
additional scaling of any ALGs if they are needed, on a per-port basis.

Here's the highlights, followed by the rest of my ideas...

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.

(rest of quoted stuff details stuff that may or may not be of interest 
or in-scope for your document)

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.
>
> Begin forwarded message:
>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>
>>     Title           : Modified Network Address Translation - Protocol 
>> Translation
>>     Author(s)       : I. van Beijnum
>>     Filename        : draft-van-beijnum-modified-nat-pt-02.txt
>>     Pages           : 16
>>     Date            : 2007-11-19
>
>> A smooth transition from IPv4 to IPv6 requires that either all hosts
>> are upgraded to dual stack before the first hosts can become IPv6-
>> only, or that there be some mechanism for IPv6-only hosts to talk to
>> IPv4-only hosts.  Expecting the former within a reasonable timeframe
>> isn't realistic, based on current adoption of dual stack combined
>> with the latest projections for the IPv4 depletion that point to a
>> date early in the next decade.  And the IETF has recently deprecated
>> the main mechanism that allows the latter: NAT-PT.
>> This document proposes modifications to NAT-PT that address the
>> reasons why the mechanism was deprecated.  This should allow future
>> deployment of the modified NAT-PT as an IPv4-to-IPv6 transition
>> mechanism, giving operators the option of running their networks
>> largely IPv6-only.
>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-van-beijnum-modified-nat-pt-02.txt 
>>
>
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Dec 2007 12:19:37 -0800

On 3 dec 2007, at 14:39, Brian Dickson wrote:

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

When I read this it wasn't obvious to me what you meant, but being  
able to talk in person can sometimes be helpful.  :-)

The idea is to have a format like ::port:v4:addr which makes it  
possible to route all traffic for a given destination port to a  
separate translator that is better prepared to translate the protocol  
in question. This is a good trick!

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

Right, there are services that need a more or less permanent inbound  
capability and others that only need this at certain times. I'd say  
that SMTP is an example of the former, though. The latter would be  
things like peer-to-peer applications that only run once in a while,  
such as videoconferencing.

> port, means a specific IPv6 address can act as a DHCP server (or  

Is this useful?

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

Indeed.

---

From: "Erik Kline" <[email-masked]>
Date: Tue, 4 Dec 2007 22:16:27 -0800

> in question. This is a good trick!

Do you want to include the protocol number in there as well? that way
you could route SCTP separately.  Not a really good argument, but I
thought I'd toss the idea out there.