Subject: Re: [BEHAVE] ULA as PREF64

From: Nathan Lutchansky <[email-masked]>
Date: Sat, 1 Jan 2011 11:29:50 -0500

[resent with the correct from-address]

On Sat, Dec 18, 2010 at 01:53:17PM -0800, Cameron Byrne wrote:
> Are there any known limitations or problems with using ULA addresses
> as the PREF64?
> 
> I do not want people from outside of my administrative domain to use
> my DNS64 and NAT64.  Other mechanisms such as access lists will be
> used, but in an attempt to have a layered approach to this particular
> security issue, it seems to make sense that ULA be used as both the
> queried address of the DNS64 as well as the NSP PREF64 that will be
> used.
> 
> Any concerns that i am overlooking?

There might be some considerations concerning address selection.  RFC
3484 and the update draft-ietf-6man-rfc3484-revise-01 both consider ULA
addresses to be of global scope, but some implementations (e.g. glibc)
deviate from this and consider it to be of site-local scope.  This means
that the hosts on your network with both native IPv4 and NAT64
connectivity would prioritize one protocol over the other in an
implementation-dependent way.

>From a more practical viewpoint, you may run into trouble with customer
equipment firewalling ULAs by default on the WAN interface.

Is there a reason you can't use the non-routable well-known prefix
64:ff9b::/96?  Traffic engineering?  -Nathan

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 1 Jan 2011 09:06:01 -0800

> implementation-dependent way.

That's an interesting point, but it works in any case still, right?
Regarding what is in place today in the address selection space across
implementations, the only think that is consistent is the expectation
that it will be inconsistent.  That said, i prefer single stack
implementation that make all these "unhappy eyeball" issues moot.

> equipment firewalling ULAs by default on the WAN interface.

Agreed, more complicated environments have a more dependencies, but in
the mobile wireless space, this should not be an issue since i have a
good idea on how the CPE / Handset should behave when i sell it to the
customer every 18 to 24 months.

> 64:ff9b::/96?  Traffic engineering?  -Nathan

I don't think WKP has much use in a large wireless network due to the
need to scale and traffic engineering requirements.  My expectation is
that there will be anycast DNS servers that have a feedback mechanism
with the NAT64, and thus the DNS64 rotates PREF64 to different users
based on load and availability of a NAT64 kit. The PREF64 should
always be the same for a given user for a given time period of
stickiness. When you think of how to implement 10s to 100s of millions
of sessions across multiple geographies, this type of feedback and
high availability mechanisms are required, and WKP is not possible for
N by NAT64 scaling.

Cameron

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Nathan Lutchansky <[email-masked]>
Date: Mon, 3 Jan 2011 11:25:20 -0500

On Sat, Jan 01, 2011 at 09:06:01AM -0800, Cameron Byrne wrote:
> On Sat, Jan 1, 2011 at 8:29 AM, Nathan Lutchansky <[email-masked]> wrote:
> > There might be some considerations concerning address selection. ?RFC
> > deviate from this and consider it to be of site-local scope. ?This means

Well, the traffic should still go *somewhere*, but possibly not to where
the owner/manufacturer of the device intended.

I can imagine that handset manufacturers may set up their address
selection rules to always prefer site-scoped addresses.  The reason
being that carriers might run split-DNS for their internal services, so
that devices on their own network could be directed to a customers-only
version of the service running on site-local addresses.  (I think the
T-Mobile "My Account" app for Android works something like this.)

Now imagine a handset with both a GPRS data link to your IPv6-only APN
and an active WiFi connection to an IPv4-only network.  If DNS queries
go to the GPRS link, and all queries for IPv4-only hosts are answered
with a site-scoped address, no IPv4 traffic will ever go out the WiFi
link.

> customer every 18 to 24 months.

Handsets, sure, but for CPE that the customer doesn't buy from you like
laptops or pocket routers, it's harder to predict behavior.  -Nathan

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 3 Jan 2011 09:16:27 -0800

> the owner/manufacturer of the device intended.

Like always, there is a scope to the technology and testing is
required, that's business as usual for anything the service providers
sells.  It has to work out the door.

> with a site-scoped address, no IPv4 traffic will ever go out the WiFi

All the handsets i know of don't run multiple interfaces.  For
example, when Android attaches to WiFi it detaches from GPRS internet
access, or at least that has been my experience.  I believe the issue
you discuss is a more broad one for DNS64 clients having access to
NAT64 resources.  Part of the motivation for using ULA for DNS64 is to
ensure only folks within my domain can access the DNS64 and the paired
NAT64 resources.

> laptops or pocket routers, it's harder to predict behavior.  -Nathan

Indeed.  That is always the case.  That said, NAT64/DNS64 will not fit
all users in the early stages.  As stated many times, there is no
silver bullet.

Cameron

---

From: Nathan Lutchansky <[email-masked]>
Date: Mon, 3 Jan 2011 13:56:23 -0500

On Mon, Jan 03, 2011 at 09:16:27AM -0800, Cameron Byrne wrote:
> On Mon, Jan 3, 2011 at 8:25 AM, Nathan Lutchansky <[email-masked]> wrote:
> > and an active WiFi connection to an IPv4-only network. ?If DNS queries
> access, or at least that has been my experience.

The network monitor API in Android allows applications to request that
their traffic leave over a specific outbound link, which means that both
GPRS and WiFi can be active simultaneously under some circumstances.  I
believe Symbian has the same capability.

Android Market insists on having GPRS up for some operations (probably
to get access to carrier-specific sections of the Market) which means
that it breaks horribly when I try to use it on my home WiFi network
with NAT64/DNS64.  I haven't looked into the problem in any detail,
though.

> I believe the issue you discuss is a more broad one for DNS64 clients
> having access to NAT64 resources.

Or, more generally, it's an issue with split DNS of any sort.  -Nathan