Subject: [v4v6interim] The NAT64 prefix

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 1 Oct 2008 17:24:00 +0100

There are several advantages of having a well known prefix for NAT-PT/ 
NAT64 or even DS-lite. For the former, synthetic AAAA records are no  
longer necessary and can be ignored by updated hosts, for the latter  
there is no longer any need have a configuration mechanism. Upgraded  
IPv6 hosts can simply start sending packets to IPv4 destinations to  
the translator when they detect that they don't have actual IPv4  
connectivity, rather than depend on external entities to provide  
configuration information, in AAAA records or explicitly. An  
additional benefit would be that NAT64 could even support IPv4  
applications this way.

On the other hand, there are operational benefits to having a  
configurable prefix: this makes it possible to direct traffic that is  
to be translated to a specific translator without routing contortions.

What I suggest is that we do both. We present a well known prefix of a  
combined NAT-PT/NAT64/DS-lite translator to transport protocols and  
applications, but we allow packets destined for that prefix to have  
their destination address rewritten into a specific prefix. Because  
the packets are translated later anyway, this causes no problems.  
Also, if we allow longest match first rules for the well known to  
specific prefix translation table, this makes it very easy to support  
private translators for RFC 1918 destinations along with global  
translators for global IPv4 destinations.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Hiroshi MIYATA <[email-masked]>
Date: Thu, 2 Oct 2008 03:47:44 +0900

Good point!

I also stated similar same in my latest version of snatpt.

http://www.ietf.org/internet-drafts/draft-miyata-v6ops-snatpt-02.txt

...miyata

On 2008/10/02, at 1:24, Iljitsch van Beijnum wrote:

> There are several advantages of having a well known prefix for NAT- 
> PT/NAT64 or even DS-lite. For the former, synthetic AAAA records are  
> no longer necessary and can be ignored by updated hosts, for the  
> latter there is no longer any need have a configuration mechanism.  
> Upgraded IPv6 hosts can simply start sending packets to IPv4  
> destinations to the translator when they detect that they don't have  
> actual IPv4 connectivity, rather than depend on external entities to  
> provide configuration information, in AAAA records or explicitly. An  
> configurable prefix: this makes it possible to direct traffic that  
> is to be translated to a specific translator without routing  
> contortions.
>
> What I suggest is that we do both. We present a well known prefix of  
> a combined NAT-PT/NAT64/DS-lite translator to transport protocols  
> and applications, but we allow packets destined for that prefix to  
> have their destination address rewritten into a specific prefix.  
> Because the packets are translated later anyway, this causes no  
> problems. Also, if we allow longest match first rules for the well  
> known to specific prefix translation table, this makes it very easy  
> to support private translators for RFC 1918 destinations along with  
> global translators for global IPv4 destinations.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 2 Oct 2008 04:22:37 +0900

Another point.

If we have a well-known prefix for translation, we can implement  
address selection policy simply. If the to-be-translated prefix is  
defined to be 3000::/16, we can configure client host's policy table  
so that to-be-translated prefix have less priority than IPv6 and  
possibly IPv4.

Moreover, if we put this rule in the *default* policy table, we can  
control a client host's address selection behavior in the following way.

If a server administrator put a 6->4 translater in front of his  
server, and he uses 3000::/16 prefix for the DNS AAAA record as well  
as a normal A record, IPv4 traffic won't decrease so much. This is  
because those client hosts with IPv6 address only connect to the  
server through the IPv6 network and the translator.
If he uses non-3000::/16 prefix for the DNS AAAA record and uses a  
normal A record, the server will have much traffic through IPv6, as  
far as most of the client hosts don't loose IPv4 address.

Even if we put a translator on client-side, we can make use of this  
address selection policy by deciding which prefix to use for the dummy  
prefix.

Kindest Regards.

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Oct 2008 16:07:55 -0400

On Oct 1, 2008, at 12:24 PM, Iljitsch van Beijnum wrote:

> PT/NAT64 or even DS-lite.

Maybe I'm missing something.

If there exists a AAAA record for a name, there is no reason to  
translate an A record to create one. Regardless of the host type, if a  
native AAAA record exists, a translated record will never be presented.

What's the issue?

---

From: Hiroshi MIYATA <[email-masked]>
Date: Thu, 2 Oct 2008 05:43:22 +0900

Fred,

You are right when we use currently proposed DNS rewriting.
But, we may have some exception.

e.g., When the administrator place Translator box in front of
Dual stack server, the administrator may register both
native IPv6 address and synthesized address as AAAA RR.

Thanks,

....miyata

On 2008/10/02, at 5:07, Fred Baker wrote:

> translate an A record to create one. Regardless of the host type, if  
> a native AAAA record exists, a translated record will never be  
> presented.
>
> What's the issue?

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Oct 2008 16:45:29 -0400

On Oct 1, 2008, at 4:43 PM, Hiroshi MIYATA wrote:

> the administrator may register both

that's his choice. we can recommend he choose differently :-)
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 2 Oct 2008 05:48:55 +0900

> a native AAAA record exists, a translated record will never be  

I believe this is about well-known prefix to make a synthetic IPv6  
address from IPv4 address. On client-side translation, you can use  
this prefix to send a packet which is translated into an IPv4 packet  
somewhere in the network.

I mentioned in my previous e-mail server-side translation case. In  
that case, IPv4 only server can serve to IPv6 clients through the  
translator. Here, a server administrator can use the well-known prefix  
to make AAAA record.

---

From: Hiroshi MIYATA <[email-masked]>
Date: Thu, 2 Oct 2008 05:52:11 +0900

> that's his choice. we can recommend he choose differently :-)

If he can know the client address, it is possible.
But if he choose one from his assigned prefix, both are very close.
So, longest match/shortest match depends on the client side.
Thus, very different prefix is preferable. ;-)

...miyata

---

From: Hiroshi MIYATA <[email-masked]>
Date: Thu, 2 Oct 2008 05:57:46 +0900

Mind you, it does not mean I recommend to use well-known address in  
public. ;-)

....miyata

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Oct 2008 10:08:32 +1300

Iljitsch,

On 2008-10-02 05:24, Iljitsch van Beijnum wrote:
> There are several advantages of having a well known prefix for
> NAT-PT/NAT64 or even DS-lite. For the former, synthetic AAAA records are
> no longer necessary and can be ignored by updated hosts, for the latter
> IPv6 hosts can simply start sending packets to IPv4 destinations to the
> translator when they detect that they don't have actual IPv4
> configuration information, in AAAA records or explicitly. An additional
> benefit would be that NAT64 could even support IPv4 applications this way.
> 
> configurable prefix: this makes it possible to direct traffic that is to
> be translated to a specific translator without routing contortions.
> 
> their destination address rewritten into a specific prefix. Because the
> packets are translated later anyway, this causes no problems. Also, if
> we allow longest match first rules for the well known to specific prefix
> translation table, this makes it very easy to support private
> translators for RFC 1918 destinations along with global translators for
> global IPv4 destinations.

I agree with all that, but it's important to add a very strong set of
operational recommendations on how the two prefixes are advertised in
both internal and external routing. Exactly as with 6to4 and Teredo relays,
if the prefixes are announced outside the appropriate scope, all sorts
of undesirable traffic patterns (and black holes) will result.

   Brian

---

From: Hiroshi MIYATA <[email-masked]>
Date: Thu, 2 Oct 2008 06:23:21 +0900

Indeed!

...miyata

On 2008/10/02, at 6:08, Brian E Carpenter wrote:

> it's important to add a very strong set of
> both internal and external routing.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 2 Oct 2008 10:39:30 +0100

> What's the issue?

I don't see how you get from what I said to what you said...

But now that you bring it up: the reason to make sure fake AAAA  
records aren't generated when real AAAA records exist is that we don't  
want to have the situation where a host uses translated connectivity  
if there's also native connectivity.

However, if the address selection rules work well enough it MAY be  
useful to present both a native address and an address that will go  
through a translator to the application so that if the native address  
doesn't work the app can try the translated address. However, we know  
there are hosts out there today that don't implement RFC 3484 fully  
(at all?) (i.e., Macs) so generating fake AAAA records where real ones  
exist in a DNS64 (-like) box is a very bad idea.

To get back to a less academic issue: what we need is for the  
addresses that are translated to be less preferred than real IPv4  
addresses. Currently, the default RFC 3484 policy table puts IPv4  
below ANY type of IPv6, so we don't have this property today.  
Obviously this is a trivial change to make to the default policy table  
if the prefix is well known, but again, external boxes that generate  
fake AAAA records can't know whether the host in question has been  
upgraded.

So let me present a path from where we are today to where we want to  
be in the future.

Today, we have NAT-PT implementations, deprecated as they may be.

The next step would be to implement some of the stuff in the NAT64  
draft, such as not using a DNS ALG but an explicit DNS64 and the EDNS0  
SAS option to indicate that synthetic AAAA records were created. Note  
that this mostly works with existing NAT-PT translators, although  
those should be upgraded to work according to the latest BEHAVE  
insights as referenced in the NAT64 draft.

At the same time, we can ask IANA to allocate a well known prefix for  
NAT64/DS-lite use. The specifications for the NAT64 translator and DS- 
lite CGN should be merged at this point, so a single translator can  
address both use cases, making deployment for either easier and  
reducing risk on the part of vendors. Because (old) hosts using DS- 
lite may need ALG support to work but ALGs get in the way of modern  
hosts/applications, IPv4 ALGs are deployed when using DS-lite, but no  
ALGs are used when the host uses NAT64.

New NAT64/DS-lite implementations should use the well known prefix and  
existing implementations should migrate to the well known prefix.

Host OSes are upgraded to prefer native IPv4 over the well known  
translated prefix, and, if desired, they are upgraded to create  
synthetic AAAA responses locally whenever there is no IPv4  
connectivity in the system.

(Alternatively, hosts implement a mechanism such that A lookups are  
also done in the absense of IPv4 connectivity and the ::ffff:0:0/96  
prefix that is used in the API is rewritten into the well known  
translator prefix as (IPv6) packets are generated so that applications  
using IPv4 through the IPv6 socket API or even the IPv4 socket API can  
send packets to IPv4 destinations even though there is no IPv4  
connectivity.)

Middlebox / DSLAM / CPE / home gateway etc vendors implement a DHCPv6  
option to obtain rewrite rules for the well known prefix, so that  
packets addressed to the well known prefix can have their destination  
address rewritten so that the packets flow towards a specific  
translator (and the return packets are translated back).

When we reach this point we should be in very good shape and be ready  
to use IPv6-to-IPv4 translation for a good number of years without  
major problems.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 2 Oct 2008 21:13:35 +0900

> records aren't generated when real AAAA records exist is that we  
> don't want to have the situation where a host uses translated  
> connectivity if there's also native connectivity.
>
> through a translator to the application so that if the native  
> address doesn't work the app can try the translated address.  
> However, we know there are hosts out there today that don't  
> implement RFC 3484 fully (at all?) (i.e., Macs) so generating fake  
> AAAA records where real ones exist in a DNS64 (-like) box is a very  
> bad idea.

I agree with you most of the parts, but let me comment on this point.

Regardless of the existence of RFC 3484 non-compatible hosts, replying  
a synthesis AAAA with a genuine AAAA should be an operator's choice ?  
As far as there is some benefit, such as fault-tolerance, to have  
these two AAAA records, and we don't have strong motivation to  
prohibit it universally, it's better to leave this decision up to an  
operator of the site or the translator box.

Kindest regards.

---

From: Fred Baker <[email-masked]>
Date: Thu, 2 Oct 2008 09:03:35 -0400

On Oct 2, 2008, at 5:39 AM, Iljitsch van Beijnum wrote:

> addresses.

picking one comment out of your longer note (which I might have more  
of a response to later), I'm not sure I agree, at least in the IVI case.

The big issue is what happens when a system with a general IPv6  
address sends a datagram to a system that has a translated address. If  
the result is that the message goes through the translator, we have a  
problem.

In the IVI case and I believe in the NAT64 case, they don't go through  
the translator. What happens is that the translator announces a  
default route (whatever prefix the LIR assigned, at that length) into  
the IPv6 domain, and either the servers or the routers in front of  
them announce more specific routes appropriate to the locations of  
those servers in the network. This is necessary for datagrams from the  
translator to get to their target servers. By the same logic that  
datagrams get from the translator to the servers, traffic from other  
IPv6 devices will go directly to the same servers - traffic will  
follow longest-match-first standard routing and go nowhere near the  
translator.

I will agree philosophically that it would be preferable that clients  
and peers in the IPv6 domain used the more general IPv6 address, but I  
honestly don't see anything that breaks, or even a change of route, if  
they happen to use the translated address.
_______________________________________________
v4v6interim mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v4v6interim

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Oct 2008 14:14:46 +1300

On 2008-10-03 01:13, Arifumi Matsumoto wrote:
> Regardless of the existence of RFC 3484 non-compatible hosts, replying a
> synthesis AAAA with a genuine AAAA should be an operator's choice ? As
> far as there is some benefit, such as fault-tolerance, to have these two
> AAAA records, and we don't have strong motivation to prohibit it
> universally, it's better to leave this decision up to an operator of the
> site or the translator box.

There's also the rather strange case where the genuine AAAA record leads
to a routing black hole, and the synthetic AAAA leads to a working
translator. Although that should not happen, it *will* happen during
the early years of IPv6 deployment.

    Brian