Subject: RFC6724/RFC3484bis: Destination selection not considering well-known NAT64 prefix

From: Philipp Kern <[email-masked]>
Date: Wed, 23 Jan 2013 22:05:57 +0100

Hi,

was it a deliberate ommission that RFC6724 does not mention a precedence value
for the well-known NAT64 prefix 64:ff9b::/96?

If a host has both IPv4 and IPv6 configured it should probably use the native
IPv4 connectivity to connect to the target instead of the translated
IPv6-to-IPv4 access. Especially if the DNS64 server is adding AAAA records
unconditionally because it cannot know if the client is actually dual stack.
Neither should the client be forced to resort to IPv4 for DNS resolution to
make this clear.

RFC6146 specifying both NAT64 and its well-known prefix is also on the
Standards Track, so it seems fair that it should be incorporated into a
RFC6724bis, I think.

Kind regards
Philipp Kern

---

From: Simon Perreault <[email-masked]>
Date: Thu, 24 Jan 2013 10:50:04 +0100

Le 2013-01-23 22:05, Philipp Kern a écrit :
> IPv6-to-IPv4 access.

This has been discussed in BEHAVE numerous times. The current consensus 
is: no, NAT64 is not "worse" than IPv4.

 From the host's point of view, you don't know that IPv4 is not NATed as 
well. You don't even know if it is "native": it could be provided by 
DS-Lite for all you know.

 From the operator's point of view, if you deploy a NAT64 in a 
dual-stack network, that probably means you *want* traffic to go over 
NAT64 rather than over IPv4. You probably want *less* native IPv4 
traffic in your network so that eventually you can make your network 
fully IPv6-only.

Simon

---

From: Philipp Kern <[email-masked]>
Date: Thu, 24 Jan 2013 11:42:11 +0100

Simon,

thanks for your reply and sorry to rehash an old topic. I appreciate any
pointers to mailing list discussions where this horse has already been
beaten to death. ;-)

am Thu, Jan 24, 2013 at 10:50:04AM +0100 hast du folgendes geschrieben:
> This has been discussed in BEHAVE numerous times. The current
> consensus is: no, NAT64 is not "worse" than IPv4.
> 
> From the host's point of view, you don't know that IPv4 is not NATed
> as well. You don't even know if it is "native": it could be provided
> by DS-Lite for all you know.

True, but I still find that rather unlikely in the case the host has a
globally unique IPv4 address configured. It might make sense to
preference NAT64 over NAT44, but then you are most likely double
translating, too, if you do not have enough public IPv4 addresses on the
outside interface of the NAT64 gateway.

> dual-stack network, that probably means you *want* traffic to go
> over NAT64 rather than over IPv4. You probably want *less* native
> IPv4 traffic in your network so that eventually you can make your
> network fully IPv6-only.

In that particular case the host has to have IPv4 connectivity to
provide NAT64 services and it does not make sense to have the traffic
round-trip through userspace and NAT64 translation. But nothing prevents
me from adjusting gai.conf for this special case anyway.

I guess the question is why native IPv4 is deployed to a host. If it's
done to avoid translation costs you really don't want to use the NAT64
gateway instead. If it's to just cope with IPv4 literals and IPv4-only
applications then I accept your argument that the operator would like
people to use the NAT64 gateway. But again this seems only likely if you
get a private IP assigned that's guaranteed to be NAT'ed. These seem to
be two entirely different categories with the first one being more
likely in a service provider / hosting scenario.

Kind regards
Philipp Kern

---

From: Simon Perreault <[email-masked]>
Date: Thu, 24 Jan 2013 11:47:37 +0100

> pointers to mailing list discussions where this horse has already been

No time to grep the archives, sorry. But as you can already see from 
these few emails, it's not black and white. As long as it stays mostly 
grey, it makes sense IMHO to stay with the status quo: prefer IPv6 by 
default.

Simon

---

From: Xuxiaohu <[email-masked]>
Date: Thu, 24 Jan 2013 10:12:55 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Simon
> Perreault
> 发送时间: 2013年1月24日 17:50
> 收件人: [email-masked]
> 主题: Re: RFC6724/RFC3484bis: Destination selection not considering
> well-known NAT64 prefix
> 

not worse when IPv4 is NATed, but worse when IPv4 is native.

> DS-Lite for all you know.

But there does exist a possibility for that IPv4 of being native.

> traffic in your network so that eventually you can make your network

This is just one possibility. Another possibility is just reverse.

Xiaohu

> Simon
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 25 Jan 2013 08:18:46 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Perreault
> Sent: Thursday, January 24, 2013 1:50 AM
> To: [email-masked]
> Subject: Re: RFC6724/RFC3484bis: Destination selection not considering
> well-known NAT64 prefix
> 
> > was it a deliberate ommission that RFC6724 does not mention a
> > precedence value for the well-known NAT64 prefix 64:ff9b::/96?
> >
> well. You don't even know if it is "native": it could be provided by DS-
> Lite for all you know.
> 
>  From the operator's point of view, if you deploy a NAT64 in a dual-
> stack network, that probably means you *want* traffic to go over

And also, if the host only has special handling for the well-known
NAT64 prefix (64:ff9b::/96), that means networks that need to or decide
to deploy their own, site-specific NAT64 prefix will not benefit from
that special handling.  BEHAVE didn't want the well-known prefix to work
differently than a site-specific NAT64 prefix.

-d

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 28 Jan 2013 16:13:26 +0900

Hi,

this issue was also discussed here in 6man.
Please refer to the following thread.
http://www.ietf.org/mail-archive/web/ipv6/current/msg13709.html

The result of the discussion was described in the past version of
the RFC 6724. But, it looks it was removed when it was re-structured.

Thanks.

2013/1/26 Dan Wing <[email-masked]>

---

From: "George, Wes" <[email-masked]>
Date: Mon, 28 Jan 2013 10:11:52 -0500

> Sent: Thursday, January 24, 2013 4:50 AM
> To: [email-masked]

[WEG] We've been discussing this on and off in sunset4 as well, and I have started to come to the conclusion that it's unlikely that there will be a single correct answer in all cases, and so the better thing is to work toward tools that allow the ISP to give the host some guidance about which address family to choose in different situations, or at least give the host some of the missing information about when something is being NATted or otherwise translated upstream so that it can make its own decision.
While any guidance of this nature should be focused on giving the end host the best possible service regardless of the intended destination or protocol, it could take into consideration the costs of different translation models (stateful vs stateless) the absence or presence of a set of ALGs for certain applications, etc. It's still useful to have default recommendations, these would likely be ways to optimize certain scenarios based on specific use cases where it's better to make a different choice than what is recommended in this document.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.