Subject: Re: [v6ops] Different DNS servers depending on dual stack or single stack usage

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 1 Aug 2012 12:08:45 +0200 (CEST)

On Mon, 30 Jul 2012, Daniel Roesen wrote:

> I was considering using an EDNS0 option to request DNS64 service, kinda 
> "DNS64 desired" similar to "recursion desired". Single-stack IPv6 
> clients would set this flag.

I think this sounds like a good idea, then our regular resolvers would 
only give DNS64 responses to clients who ask for it, and if we know some 
devices need only DNS64 responses (older clients without this 
functionality and ones we know will be behind NAT44 anyway), then we give 
them special DNS64-only resolvers.

Would such an option be something only newer implementations used, so it's 
not "always before set to 0" (older clients without this implemented), 
because then modern clients (with this option implemented) could indicate 
to the DNS64 resolvers that they did *not* want DNS64 responses as well.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Daniel Roesen <[email-masked]>
Date: Wed, 1 Aug 2012 12:26:54 +0200

On Wed, Aug 01, 2012 at 12:08:45PM +0200, Mikael Abrahamsson wrote:
>> "DNS64 desired" similar to "recursion desired". Single-stack IPv6 clients 
>> would set this flag.
>
> I think this sounds like a good idea, then our regular resolvers would only 
> give DNS64 responses to clients who ask for it, and if we know some devices 
> need only DNS64 responses (older clients without this functionality and 
> ones we know will be behind NAT44 anyway), then we give them special 
> DNS64-only resolvers.

Personally, I wouldn't complicate it that much but just provide a single
set of resolvers which are capable of DNS64 if requested by the
endpoint. But that depends on some considerations specific to the
outfit's user base and access technology.

> to the DNS64 resolvers that they did *not* want DNS64 responses as well.

EDNS0 is defined in RFC2671. EDNS0 sports querying for a pseudo RR "OPT"
which contains a 16-bit flag field. Currently, there is only one of
those defined (http://www.iana.org/assignments/dns-parameters/):

==============================================================
Registry Name: EDNS Header Flags (16 bits) 
Reference: [RFC2671]
Registration Procedures: RFC Required 

Registry:
Bit        Flag  Description            Reference
---------  ----  ---------------------  ------------------
Bit 0      DO    DNSSEC answer OK       [RFC4035][RFC3225]
Bit 1-15         Reserved
==============================================================

The EDNS0 spec calls for the 16-bit field to be set to zero unless
usage is defined, so one can expect the undefined bits to be zero.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 1 Aug 2012 12:57:44 +0200 (CEST)

On Wed, 1 Aug 2012, Daniel Roesen wrote:

> The EDNS0 spec calls for the 16-bit field to be set to zero unless usage 
> is defined, so one can expect the undefined bits to be zero.

Oki, well, then either we need two bits (one for DNS64 desired and one for 
DNS64 not desired) or just ignore one of the use-cases I described and go 
with a single bit (DNS64 desired).

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 1 Aug 2012 06:47:31 -0700

On Jul 31, 2012 10:30 PM, "Mikael Abrahamsson" <[email-masked]> wrote:
>
> On Wed, 1 Aug 2012, jouni korhonen wrote:
>
>>> Let's say we have a network where clients can connect, some will be
dual stack, some will be IPv6 only (3GPP for instance, also wifi). In case
the client is IPv6 only (single stack), I would like them to have access to
DNS64/NAT64 infrastructure.
>>
>>
>> For 3GPP networks this can be achieved using AAA to provision DNS servers
>> for your APN.. obviously you need some additional logic then in your AAA
>> server to hand out different DNS servers depending on the PDP-Type that
got
>> established.
>
>
> I don't believe this solves my problem. If I hand out DNS64 for everybody
who connects using IPv6, I might cause problems to clients who establish a
second PDP context, this time IPv4 only (dual bearer).
>
> I read the 464xlat discussion from february, and I can only chime in with
Cameron that getting v4v6 dual stack PDP context actually working in a
2G/3G/4G environement, is non-trivial. There are a lot of components that
need to support it and it seems whenever I get one of them fixed, there is
something else we didn't think of.
>
> Also handsets seem to be very slow to adopt this (the only time I've been
able to successfully able to enable a dual stack single bearer is on LTE,
which then fails miserably when handing over to (or trying to establish in)
2G/3G), but handsets also do not seem to go the way of supporting 2 single
stack bearers either (at least not Android). My Galaxy Nexus with 4.1.1 at
least has the v4v6 PDP type I can choose, but it doesn't work (and I don't
really know if it's the phone or the network (or both) that fails).
>
> I would at least like to thank Google for IPv6-enabling their phones so
we have something to test with (we have USB dongles for computer
connectivity as well, but that doesn't test the App ecosystem). I have been
trying to reach someone at Apple to try to understand where they're headed,
but so far no luck on that (which doesn't greatly surprise me considering
their usual secrecy), but if someone from Apple reads this, it would
greatly help if you would at least say for instance "it looks like we're
going to support single v4v6 PDP context, single v4, or single v6 in the
not too distant future", so we have something to plan for.
>
> Right now I have a really hard time internally trying to get something
done because I can't say what we should be headed for, what will the
handsets support in 1-2 years time. Installed base is also of great
importance, if tens of percent doesn't support something (or will support
it in the not too distant future) it's really hard to get anyone to spend
time on implementing anything network side.
>
> So the only thing I can say for sure right now is that v6 only seems to
work on a few android phones, and getting networking code into android
would be easier (at least I imagine so) than to get baseband changes done
to support new PDP context types. But this is just speculation on my part...

A bit off topic from the subject line, but i 100% agree with your rant
about mobile challenges with dual stack.

< plug>

And, that is why 464XLAT is appealing. We took the matter into our own
hands by leveraging the ability to contribute code into the android base
(still in code review at Android, but builds for nexus s and galaxy nexus
freely available as well as source code) so that the feature is avalable
down stream to all Android OEMs and builds on the what we know commonly
works (ipv6-only + nat64/dns64).

This has the advantage of that it works today using existing generally
available components and it does not carry the dual stack bagage (no ipv4
left for DS, happy eyeballs issues, ....)

FYI. The T-Mobile USA Samsung SG2, SG3, Note, Nesus S and GNex all support
ipv6-only with nat64/dns64. So, there is progress to build on.

</plug>

CB

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 1 Aug 2012 18:16:15 +0200 (CEST)

> ipv6-only with nat64/dns64. So, there is progress to build on.

I wholeheartedly applaud your initiative here, and I think for instance 
464XLAT to enable NAT64 to work for apps that have not been designed for 
IPv6 only use, is a key feature that is going to be needed in the next few 
years in order to get v6 only access off the ground.

Developers of apps and PC programs generally do not test their software in 
an v6 environment (not even dual stack), and users want to use this 
software on their devices, so before there is a working solution we cannot 
deploy as that would cause customer outrage (my own very limited tests 
show for instance that Waze, Spotify and Skype doesn't work). Your list of 
apps on android that needs 464XLAT to work is excellent, please keep up 
the good work. Does 464XLAT make "portable hotspot" work as well? 
Currently with v6 only access it seems at least a Galaxy Nexus with 4.1.1 
does "nothing".

I would be very interested in testing 464XLAT on Windows 7 as well if it 
was available.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 1 Aug 2012 12:05:05 -0700

> years in order to get v6 only access off the ground.

Thank you, i deflect all credit to the folks that coded the solution
(Dan Drown for Android and the folks at NEC) and the folks the
specified the comment parts in RFC 6145 and RFC 6146

> an v6 environment (not even dual stack), and users want to use this software
> on their devices, so before there is a working solution we cannot deploy as
> that would cause customer outrage (my own very limited tests show for
> instance that Waze, Spotify and Skype doesn't work). Your list of apps on
> android that needs 464XLAT to work is excellent, please keep up the good
> work. Does 464XLAT make "portable hotspot" work as well? Currently with v6
> only access it seems at least a Galaxy Nexus with 4.1.1 does "nothing".
>

Yes, 464XLAT I-D as well as open source Android code supports the
dual-stack WLAN extended from an IPv6-only GSM/UMTS/LTE UE and
network.  Meaning, you can present a DS WLAN to a PC  via an IPv6-only
network (3GPP for Android , FTTH for NEC ...)

Running code matters.  To that end, here is a reminder set of links on
where this can be found

http://dan.drown.org/android/clat/ (source and Nexus S image)

http://dl.dropbox.com/u/6628080/update-cm-9-20120514-SNAPSHOT-maguro-signed.zip
 (Galaxy Nexus image)

> I would be very interested in testing 464XLAT on Windows 7 as well if it was
> available.
>
>

Like most things, 464XLAT evolves in Open Source and I-D documents.

Once there is a viable market for the solution and the solution is
proven at scale, others (Microsoft, Apple, ...)  may pick it up too.

CB

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 1 Aug 2012 20:02:00 +0000

Hi Mikael,

> second PDP context, this time IPv4 only (dual bearer).

Hmmm....not sure if I follow. Assuming we meant to say 2nd primary PDP context (and not secondary PDP contexts, since  secondary PDP contexts must use the same IP address as that of the associated primary PDP context),  couldn't HSS force SGSN/MME to override the requested PDN type (=IPv4, say) with PDN type=IPv6 at the time of PDP creation, or simply reject it?

In other words, Jouni's suggestion of using AAA to assign different DNS server addresses to different PDN-types should solve your problem.

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mikael Abrahamsson
> Sent: Wednesday, August 01, 2012 1:30 AM
> To: [email-masked]
> Subject: Re: [v6ops] Different DNS servers depending on dual stack or single
> stack usage
> 
> >> dual stack, some will be IPv6 only (3GPP for instance, also wifi). In
> >> case the client is IPv6 only (single stack), I would like them to
> >> have access to DNS64/NAT64 infrastructure.
> >
> > For 3GPP networks this can be achieved using AAA to provision DNS
> > servers for your APN.. obviously you need some additional logic then
> > in your AAA server to hand out different DNS servers depending on the
> > PDP-Type that got established.
> 
> able to successfully able to enable a dual stack single bearer is on LTE, which
> then fails miserably when handing over to (or trying to establish
> in) 2G/3G), but handsets also do not seem to go the way of supporting 2
> single stack bearers either (at least not Android). My Galaxy Nexus with
> 4.1.1 at least has the v4v6 PDP type I can choose, but it doesn't work (and I
> don't really know if it's the phone or the network (or both) that fails).
> 
> I would at least like to thank Google for IPv6-enabling their phones so we
> have something to test with (we have USB dongles for computer
> trying to reach someone at Apple to try to understand where they're
> headed, but so far no luck on that (which doesn't greatly surprise me
> considering their usual secrecy), but if someone from Apple reads this, it
> would greatly help if you would at least say for instance "it looks like we're
> going to support single v4v6 PDP context, single v4, or single v6 in the not
> too distant future", so we have something to plan for.
> 
> Right now I have a really hard time internally trying to get something done
> because I can't say what we should be headed for, what will the handsets
> support in 1-2 years time. Installed base is also of great importance, if tens
> of percent doesn't support something (or will support it in the not too
> distant future) it's really hard to get anyone to spend time on implementing
> anything network side.
> 
> So the only thing I can say for sure right now is that v6 only seems to work
> on a few android phones, and getting networking code into android would
> be easier (at least I imagine so) than to get baseband changes done to
> support new PDP context types. But this is just speculation on my part...
> 
> --

---

From: jouni korhonen <[email-masked]>
Date: Wed, 1 Aug 2012 23:05:15 +0300

Mikael,

On Aug 1, 2012, at 8:30 AM, Mikael Abrahamsson wrote:

>>> Let's say we have a network where clients can connect, some will be dual stack, some will be IPv6 only (3GPP for instance, also wifi). In case the client is IPv6 only (single stack), I would like them to have access to DNS64/NAT64 infrastructure.
>> 
>> server to hand out different DNS servers depending on the PDP-Type that got
>> established.
> 
> I don't believe this solves my problem. If I hand out DNS64 for everybody who connects using IPv6, I might cause problems to clients who establish a second PDP context, this time IPv4 only (dual bearer).

So then don't let your subscribers establish a "dualstack" with two contexts for
those APNs you care about this.. with a limitation then that IPv4 would only be 
possible with real dualstack context. Without modifying the end host and the
current tools in 3GPP specs there is a limited amount things you can do.

For the rest below, yes, painful points many of us is very aware of :(

- Jouni

> I read the 464xlat discussion from february, and I can only chime in with Cameron that getting v4v6 dual stack PDP context actually working in a 2G/3G/4G environement, is non-trivial. There are a lot of components that need to support it and it seems whenever I get one of them fixed, there is something else we didn't think of.
> 
> Also handsets seem to be very slow to adopt this (the only time I've been able to successfully able to enable a dual stack single bearer is on LTE, which then fails miserably when handing over to (or trying to establish in) 2G/3G), but handsets also do not seem to go the way of supporting 2 single stack bearers either (at least not Android). My Galaxy Nexus with 4.1.1 at least has the v4v6 PDP type I can choose, but it doesn't work (and I don't really know if it's the phone or the network (or both) that fails).
> 
> I would at least like to thank Google for IPv6-enabling their phones so we have something to test with (we have USB dongles for computer connectivity as well, but that doesn't test the App ecosystem). I have been trying to reach someone at Apple to try to understand where they're headed, but so far no luck on that (which doesn't greatly surprise me considering their usual secrecy), but if someone from Apple reads this, it would greatly help if you would at least say for instance "it looks like we're going to support single v4v6 PDP context, single v4, or single v6 in the not too distant future", so we have something to plan for.
> 
> Right now I have a really hard time internally trying to get something done because I can't say what we should be headed for, what will the handsets support in 1-2 years time. Installed base is also of great importance, if tens of percent doesn't support something (or will support it in the not too distant future) it's really hard to get anyone to spend time on implementing anything network side.
> 
> So the only thing I can say for sure right now is that v6 only seems to work on a few android phones, and getting networking code into android would be easier (at least I imagine so) than to get baseband changes done to support new PDP context types. But this is just speculation on my part...
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 2 Aug 2012 06:01:17 +0200 (CEST)

On Wed, 1 Aug 2012, Rajiv Asati (rajiva) wrote:

> Hmmm....not sure if I follow. Assuming we meant to say 2nd primary PDP 
> context (and not secondary PDP contexts, since secondary PDP contexts 
> must use the same IP address as that of the associated primary PDP 
> context), couldn't HSS force SGSN/MME to override the requested PDN type 
> (=IPv4, say) with PDN type=IPv6 at the time of PDP creation, or simply 
> reject it?

Yes, but if the goal for the client is to end up being dual stacked, then 
your suggestion doesn't help anything. And yes, I am talking about 2nd 
primary PDP context, as in "client will have two primary PDP contexts, one 
v4 and one v6". The problem this solves is that the network is not ready 
for v4v6 dual stack PDP context and neither is the UE. Otoh I have not 
heard from mobile phone vendors that they're interested in supporting two 
simultaneous PDP contexts, but we have this working with test firmware in 
LTE USB dongles.

> In other words, Jouni's suggestion of using AAA to assign different DNS 
> server addresses to different PDN-types should solve your problem.

I don't see how it does.

---

From: jouni korhonen <[email-masked]>
Date: Thu, 2 Aug 2012 21:03:46 +0300

On Aug 2, 2012, at 7:01 AM, Mikael Abrahamsson wrote:

> Yes, but if the goal for the client is to end up being dual stacked, then your suggestion doesn't help anything. And yes, I am talking about 2nd primary PDP context, as in "client will have two primary PDP contexts, one v4 and one v6". The problem this solves is that the network is not ready for v4v6 dual stack PDP context and neither is the UE. Otoh I have not heard from mobile phone vendors that they're interested in supporting two simultaneous PDP contexts, but we have this working with test firmware in LTE USB dongles.

Afair some (Android based) tablets to do that. Also some 3G USB dongles did two PDPs.

>> In other words, Jouni's suggestion of using AAA to assign different DNS server addresses to different PDN-types should solve your problem.

Mikael is right regarding the case where two PDP context would be used (or allowed) for the "dualstack". There we have no means to figure out in advance whether we need to assign a DNS64 to the IPv6 PDP Context or not, since we do not know whether IPv4 PDP gets ever established.

- Jouni

---

From: Daniel Roesen <[email-masked]>
Date: Fri, 3 Aug 2012 02:37:40 +0200

On Thu, Aug 02, 2012 at 09:03:46PM +0300, jouni korhonen wrote:
> Mikael is right regarding the case where two PDP context would be used
> (or allowed) for the "dualstack". There we have no means to figure out
> in advance whether we need to assign a DNS64 to the IPv6 PDP Context
> or not, since we do not know whether IPv4 PDP gets ever established.

The same issue is present with any host in a dualstacked LAN as well.
You'll never know wether that device is IPv6-only or dualstack capable.

We need something "inband" in DNS to signal wether DNS64 is required
(alias "IPv6 only") or not. Because only the endpoint knows.

Best regards,
Daniel

---

From: Mark Andrews <[email-masked]>
Date: Sat, 04 Aug 2012 02:40:58 +1000

> (alias "IPv6 only") or not. Because only the endpoint knows.

And recursive servers need to get *both* styles of answers at once.
EDNS provides a way for a client to signal that it is DNS64 aware
and if it is DNS64 aware the server can return *both* the regular
answer and the addresses it would have sent if it was synthesised.

EDNS could also be used by the client to lookup the mapping of IPv4
literal over DNS with QCOUNT=0.

Request:
	<code><length>[<ipv4address>]*
Response:
	<code><length><ttl>[<synthesised-address>]+

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Philipp Kern <[email-masked]>
Date: Sat, 4 Aug 2012 19:57:19 +0200

> (alias "IPv6 only") or not. Because only the endpoint knows.

Or we need something that signals a NAT64 range through e.g. DHCPv6 and
enables the client to map IPv4 transparently into it if Dual Stack is not
available.

Kind regards
Philipp Kern

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 4 Aug 2012 11:29:09 -0700

> enables the client to map IPv4 transparently into it if Dual Stack is not

You may find this interesting for a host to discover that a DNS64 is
available  http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-11

---

From: Mark Andrews <[email-masked]>
Date: Mon, 06 Aug 2012 03:56:56 +1000

In message <[email-masked]>
> available  http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuri

Which doesn't handle all the nuances of DNS64.  Requires every app
that handles IPv4 literals (i.e. just about all network apps) to
be updated.