Subject: [v6ops] combination of NAT64/DNS64 and NAT44

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 17 Apr 2013 12:23:21 +0200 (CEST)

Hello.

I would like to solicit some feedback on a deployment scenario.

A device has dual stack access on its WAN access, with IPv4 RFC1918 
addresses or 100.64.0.0/10 address space on WAN side, and a CGN NAT44 
gateway for sharing these addresses towards the Internet, and GUA IPv6 
addresses. There is also a NAT64 gateway in the network, and a DNS64 
resolver reachable over IPv6. There is a regular resolver reachable over 
IPv4. A dual stack client will get both types of resolvers.

Now, aim is to support all kinds of devices, IPv4 only, IPv6 only, and 
dual stack. The single stack cases are pretty obvious (IPv4 single stack 
will use NAT44, IPv6 single stack will use NAT64/DNS64 and require 464XLAT 
for "proper" function), but my question relates to the dual stack case. 
With a DNS64 based resolver, only IPv4 literals will go over the NAT44, if 
the device uses the IPv6 based resolver. If it uses the IPv4 based 
resolver, it will use the NAT44 device for IPv4 only sites.

So my questions are:

1. Is there a case where the above setup will cause problems?

2. Does it make sense to turn on DNS64 even on the IPv4 based resolver? 
This would cause AAAA lookups over IPv4 to steer traffic towards the NAT64 
gateway, in case a client chooses to use the IPv4 based resolver for 
lookups even if it's dual stacked. As far as I understand, a DNS64 based 
resolver will forward A quaries unmodified so this shouldn't cause any 
problems for single stacked IPv4 clients?

3. Did I miss anything?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: <[email-masked]>
Date: Wed, 17 Apr 2013 13:20:41 +0200

Hi Mikael,

Isn't your problem similar to what is discussed here: http://tools.ietf.org/html/draft-kaliwoda-sunset4-dual-ipv6-coexist-01?

This problem is also discussed at: http://tools.ietf.org/html/draft-wing-dhc-dns-reconfigure-00

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>Mikael Abrahamsson
>Envoyé : mercredi 17 avril 2013 12:23
>À : [email-masked]
>Objet : [v6ops] combination of NAT64/DNS64 and NAT44
>
>
>Hello.
>
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 17 Apr 2013 16:31:52 +0200 (CEST)

On Wed, 17 Apr 2013, [email-masked] wrote:

> Isn't your problem similar to what is discussed here: 
> http://tools.ietf.org/html/draft-kaliwoda-sunset4-dual-ipv6-coexist-01?

Well, partly.

> This problem is also discussed at: http://tools.ietf.org/html/draft-wing-dhc-dns-reconfigure-00

Yes, but my network (3GPP based) doesn't use DHCPv6 to hand out IPv6 DNS 
resolvers, so unfortunately this doesn't help me.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 17 Apr 2013 16:42:52 +0200

Le 2013-04-17 12:23, Mikael Abrahamsson a écrit :
> will use NAT44, IPv6 single stack will use NAT64/DNS64 and require
> 464XLAT for "proper" function), but my question relates to the dual
> stack case. With a DNS64 based resolver, only IPv4 literals will go over
> the NAT44, if the device uses the IPv6 based resolver.

This is not quite true. Happy-eyeballs algorithms will direct some 
traffic over IPv4 even if IPv6 is available. It could even be a lot of 
traffic, or even most traffic, depending on traffic patterns.

> If it uses the
> IPv4 based resolver, it will use the NAT44 device for IPv4 only sites.
>
> So my questions are:
>

It should work, but it will not be fun to operate.

> This would cause AAAA lookups over IPv4 to steer traffic towards the
> NAT64 gateway, in case a client chooses to use the IPv4 based resolver
> for lookups even if it's dual stacked. As far as I understand, a DNS64
> based resolver will forward A quaries unmodified so this shouldn't cause
> any problems for single stacked IPv4 clients?

It makes a lot of sense, especially since some implementations do happy 
eyeballs at the DNS level and cache the first result received. So an 
otherwise perfectly dual stack node might end up not using the NAT64 if 
it happens to obtain results from the IPv4 resolver first and that 
resolver doesn't do DNS64.

> 3. Did I miss anything?

It might not be immediately useful to you, but you should know about 
this draft:
https://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic

Other than that, my main feedback would be: you want to provide NATed 
IPv4 alongside NAT64, doesn't that defeat the purpose of NAT64, i.e. 
operating an IPv6-only network?

Simon

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 17 Apr 2013 16:48:42 +0200 (CEST)

On Wed, 17 Apr 2013, Simon Perreault wrote:

> It might not be immediately useful to you, but you should know about this 
> draft:

Yep. Also RFC6877, but my guess would be that the 464XLAT would be 
disabled when WAN port is dual stack?

> operating an IPv6-only network?

I want all kinds of terminals to be supported using single APN. I don't 
want to care if the device connects using DS or single stack IPv4 or IPv6.

I don't control the end devices.

---

From: "cb.list6" <[email-masked]>
Date: Wed, 17 Apr 2013 07:54:20 -0700

On Wed, Apr 17, 2013 at 3:23 AM, Mikael Abrahamsson <[email-masked]> wrote:
> Now, aim is to support all kinds of devices, IPv4 only, IPv6 only, and dual
> stack. The single stack cases are pretty obvious (IPv4 single stack will use
> NAT44, IPv6 single stack will use NAT64/DNS64 and require 464XLAT for
> "proper" function), but my question relates to the dual stack case. With a
> DNS64 based resolver, only IPv4 literals will go over the NAT44, if the
> device uses the IPv6 based resolver. If it uses the IPv4 based resolver, it
> will use the NAT44 device for IPv4 only sites.
>
> So my questions are:
>
> 2. Does it make sense to turn on DNS64 even on the IPv4 based resolver? This
> would cause AAAA lookups over IPv4 to steer traffic towards the NAT64
> gateway, in case a client chooses to use the IPv4 based resolver for lookups
> even if it's dual stacked. As far as I understand, a DNS64 based resolver
> will forward A quaries unmodified so this shouldn't cause any problems for
> single stacked IPv4 clients?
>
> 3. Did I miss anything?
>

i already operate this way.  I don't really see a major downsides.

Depending on how you want to deploy, you can leverage RFC 6724 in
different ways with either a GUA or ULA pref64.  Meaning, RFC6724
prefers any IPv4 over ULA.  And, if your pref64 is ULA, the dual-stack
devices in your network will always use NAT44 if they have IPv4, since
ULA is a lower pref.

But, ULA Pref64 has some impacts on 464XLAT / RFC 6877.  If you are
trying to optimize for single translation since anything that is not
native IPv6 will have translation at the CLAT and PLAT, but that is
acceptable in many scenarios.

CB

---

From: Simon Perreault <[email-masked]>
Date: Wed, 17 Apr 2013 16:55:37 +0200

> want to care if the device connects using DS or single stack IPv4 or IPv6.

IMHO, it would be better engineering-wise to provision different sets of 
parameters for DS, SSv4, and SSv6.

DS: IPv6 + NAT44
SSv4: NAT44
SSv6: IPv6 + NAT64

And you're lucky, you can even determine the kind of client based on the 
PDP type. Others aren't so lucky... ;)

Can you do that using a single APN?

Simon

---

From: Czerwonka Michał - Hurt TP <[email-masked]>
Date: Wed, 17 Apr 2013 15:14:44 +0000

Or 

SSv4: NAT44 + DNS_DS (old UE or new)
SSv6: IPv6 + NAT64 + DNS64_DS ( new samrtphones/routers/tablets with CLAT feature)

DS will be if enduser establish two PDP at the same time (dongles) (of cource if network allowed this)

DNS_DS != DNS64_DS

BR,
Mcz

-----Wiadomość oryginalna-----
Od: [email-masked] [mailto:[email-masked]] W imieniu Simon Perreault
Wysłano: 17 kwietnia 2013 16:56
Do: Mikael Abrahamsson
DW: [email-masked]
Temat: Re: [v6ops] combination of NAT64/DNS64 and NAT44

DS: IPv6 + NAT44
SSv4: NAT44
SSv6: IPv6 + NAT64

Simon

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 17 Apr 2013 10:43:22 -0500

Does it make sense to complicate the network with all these things if you
have a dual stack network?

Is it to discourage people from using IPv4? Or be ready for IPv6 only
network?

I don't understand.

Regards,

Behcet

On Wed, Apr 17, 2013 at 9:54 AM, cb.list6 <[email-masked]> wrote:

> dual
> This
> lookups

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 17 Apr 2013 17:46:21 +0200 (CEST)

> Is it to discourage people from using IPv4? Or be ready for IPv6 only

Some devices are not capable of dual stack, they are either single stack 
IPv4 or single stack IPv6.

This is mobile. It's understandable that you feel things seem weird, 
because a lot of things in 3GPP land do not make sense unless you've 
worked with it a while and accept the quirks.

---

From: Sander Steffann <[email-masked]>
Date: Wed, 17 Apr 2013 18:43:03 +0200

> This is mobile. It's understandable that you feel things seem weird, because a lot of things in 3GPP land do not make sense unless you've worked with it a while and accept the quirks.

There is a big difference between accepting the quirks and them making sense ;-)
Sander

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 17 Apr 2013 23:41:39 +0000

Hi Mikael,

1. Nothing major, however, minor side-effect is that the UE traffic could
go over IPv4 when it should be going over IPv6 or vice versa, depending on
which DNS response gets received sooner in the context of dual-stack
devices (ignoring happy eyeball).

2. Your proposal has a nice property of seeing more IPv6 traffic inside
the network (barring #1, or put it other way, if AAAA are always sent
before A), and seeing IPv4 traffic for IPv4-only UEs (e.g. Motorola 3G
smartphones) or IPv4-only apps (e.g. Skype

3. An automated way of figuring out which APN (for v4 only, v6 only, and
DS!) to be used by which UE??

Cheers,
Rajiv

-----Original Message-----
From: Mikael Abrahamsson <[email-masked]>
Organization: People's Front Against WWW
Date: Wednesday, April 17, 2013 6:23 AM
To: "[email-masked]" <[email-masked]>
Subject: [v6ops] combination of NAT64/DNS64 and NAT44

>464XLAT 
>NAT64

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Apr 2013 11:08:51 +0300

On Apr 17, 2013, at 5:55 PM, Simon Perreault <[email-masked]> wrote:

> IMHO, it would be better engineering-wise to provision different sets of parameters for DS, SSv4, and SSv6.
> 
> DS: IPv6 + NAT44
> SSv4: NAT44
> SSv6: IPv6 + NAT64
> 
> And you're lucky, you can even determine the kind of client based on the PDP type. Others aren't so lucky... ;)
> 

In theory yes if AAA backend is used to provide per subscriber
configuration to the GGSN/PGW.. However, the reality in actual
products can be on a different orbit than specifications. Also
it depends on the GGSN/PGW implementation how it handles the
session profile for APNs and such..

- JOuni

---

From: GangChen <[email-masked]>
Date: Thu, 18 Apr 2013 16:12:14 +0800

> want to care if the device connects using DS or single stack IPv4 or IPv6.

Are you seeing IPv6-only PDN context?  It's rather interested to hear
more about it.

BRs

Gang

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 18 Apr 2013 10:13:14 +0200 (CEST)

> parameters for DS, SSv4, and SSv6.

Yes, but this is hard to do in real life.

> Can you do that using a single APN?

It might be possible, but I don't think it's feasable. I'd probably go for 
multiple APNs then, and provision different APNs depending on equipment 
type.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 18 Apr 2013 10:17:05 +0200 (CEST)

> Are you seeing IPv6-only PDN context?  It's rather interested to hear 

Well, my Samsung Galaxy Nexus supports IPv4 or IPv6 PDP context, not 
IPv4v6 or IPv4+IPv6. My hope to make this phone work is that Android 4.3 
will include CLAT functionality in it, then IPv6 only PDP context + 
DNS64/NAT64 will hopefully work well enough.

I have done testing with IPv6 only for several years and rejected it due 
to NAT64+DNS64 not working well enough without 464XLAT. Two PDP contexts 
(IPv4+IPv6) works well, but I don't want to deploy in volume it due to 
increased signalling load.

So what are your interest in IPv6 only PDN context?

---

From: Simon Perreault <[email-masked]>
Date: Thu, 18 Apr 2013 10:20:46 +0200

> session profile for APNs and such..

Understood. That's what I expected too.

*sigh* That's why we can't have nice things.

Simon

---

From: GangChen <[email-masked]>
Date: Thu, 18 Apr 2013 16:37:25 +0800

2013/4/18, Mikael Abrahamsson <[email-masked]>:
> IPv4v6 or IPv4+IPv6.

Is this a situation for 3G mode. I heard most HSDPA terminals are R6
and HSUPA are R7
Those terminals can not support IPv4v6 PDP context.

> My hope to make this phone work is that Android 4.3

Good. I guess that is a right way to go.

> So what are your interest in IPv6 only PDN context?

My thought was about terminals which are post-R8, especially LTE
modes. Basically it supports dual-stack PDN activation. IPv6-only PDN
context is desirable, but it seems vulnerable when the terminals are
roaming to a IPv6-disable network. Dual-stack PDN could fall back to
IPv4 in that case. I'm not sure what is the behavior for IPv6-only PDN
context. Fallback to IPv4 seems straightforward. However, 3GPP doesn't
give the words to describe.

BRs

Gang

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 18 Apr 2013 10:50:49 +0200 (CEST)

On Thu, 18 Apr 2013, GangChen wrote:

> Is this a situation for 3G mode. I heard most HSDPA terminals are R6 and 
> HSUPA are R7 Those terminals can not support IPv4v6 PDP context.

Might be so. But they can support IPv4+IPv6, but the Galaxy Nexus doesn't. 
Even my old Nokia N900 could do IPv4+IPv6 by editing the startup scripts.

> My thought was about terminals which are post-R8, especially LTE modes. 
> Basically it supports dual-stack PDN activation. IPv6-only PDN context 
> is desirable, but it seems vulnerable when the terminals are roaming to 
> a IPv6-disable network. Dual-stack PDN could fall back to IPv4 in that 
> case. I'm not sure what is the behavior for IPv6-only PDN context. 
> Fallback to IPv4 seems straightforward. However, 3GPP doesn't give the 
> words to describe.

IPv4v6 is fairly new, so a lot of network components don't support it, or 
it's not well tested. For LTE it generally works out of the box if it's 
enabled in config everywhere. Most newer LTE terminals support it as well, 
if the vendor hasn't disabled it in the GUI.

I think Android GUI option to have a separate "roaming APN protocol" 
option and "APN protocol" option, so that it can be IPv4 when roaming, and 
whatever (IPv4v6 or IPv6) when in the home network, is sensible.

Generally the 3GPP standard makes a lot of sense, unfortunately there are 
network components that go BOOM when they see IPv6 or IPv4v6 requests, as 
some of us have noticed. This is especially a roaming problem, since it's 
doable to qualify ones own network, but qualifying everybody elses is 
another matter.