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

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 30 Jul 2012 12:20:28 +0200 (CEST)

Hello.

I would like to describe a problem that I do not have a solution to, thus 
trying to solicit possible remedies to it so please fire if you have any 
thoughts.

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. At the same time, I would like to avoid 
handing out the DNS64 resolver address if the client is dual stacked (I 
believe that is considered harmful?).

How could this be achieved? One way would be to extend the DHCP standard 
to hand out multiple DNS servers and have them tagged for different use, 
so the client would need to decide if it's single or dual stack, and 
choose DNS resolver accordingly.

Thoughts?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 30 Jul 2012 06:50:15 -0700

On Mon, Jul 30, 2012 at 3:20 AM, Mikael Abrahamsson <[email-masked]> wrote:
> DNS64/NAT64 infrastructure. At the same time, I would like to avoid handing
> out the DNS64 resolver address if the client is dual stacked (I believe that
> is considered harmful?).
>

Why is DNS64 to DS NAT44 hosts harmful? IMHO, NAT44 and NAT64
equivalent levels of service  (NOTE:  In my experience, NAT44 ALGs are
more complete than NAT64 ALGs .... that is implementation level
issues).

> How could this be achieved? One way would be to extend the DHCP standard to
> hand out multiple DNS servers and have them tagged for different use, so the
> client would need to decide if it's single or dual stack, and choose DNS
> resolver accordingly.
>

You want one DHCP solution for multiple access types?

Seems like the solutions should be address assignments for the
specific access types, but i am likely missing something.

CB

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

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 30 Jul 2012 23:18:19 +0200

Hi,

On Mon, Jul 30, 2012 at 12:20:28PM +0200, Mikael Abrahamsson wrote:
> out the DNS64 resolver address if the client is dual stacked (I believe 
> that is considered harmful?).

Yep, that's a problem I was thinking about multiple times, too.

> hand out multiple DNS servers and have them tagged for different use, so 
> the client would need to decide if it's single or dual stack, and choose 
> DNS resolver accordingly.

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.

See #networker logs from 2012-01-17 for some discussion. :)

Best regards,
Daniel

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

---

From: Daniel Roesen <[email-masked]>
Date: Mon, 30 Jul 2012 23:26:59 +0200

> more complete than NAT64 ALGs .... that is implementation level

When providing centralized NAT64 service, I really don't want to see
traffic from dualstacked services to go through NAT64 towards
dualstacked endpoints which happen to support DNS resolving via IPv6
transport, really. It should use its very own IPv4 connectivity to reach
such a service, no matter wether it gets implemented via CPE-based
NAT44, NAT444 or DS-Lite. Don't inject more AFI trickery than absolutely
required as long as IPv4 is still delivered to the endpoint.

IMHO, YMMV. :)

> specific access types, but i am likely missing something.

How do you detect an IPv6-only endpoint from the DHCP server
and/or DNS recursor perspective?

Best regards,
Daniel

---

From: Jared Mauch <[email-masked]>
Date: Mon, 30 Jul 2012 17:39:21 -0400

> specific access types, but i am likely missing something.

Sounds like you want to modify the host stack (or application layer) to have per-af resolvers and capabilities.  since you are stuck with gethostbyname2() and similar, you need to push this elsewhere.  I'm not sure the best way to address this as it requires a more comprehensive rewrite of so many parts of the system.

What is the overall ROI you see for this work?  Is this just a system to provide polarization for or against v4("Classic IP")?

- Jared

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 31 Jul 2012 06:05:31 +0200 (CEST)

On Mon, 30 Jul 2012, Cameron Byrne wrote:

> Why is DNS64 to DS NAT44 hosts harmful? IMHO, NAT44 and NAT64 equivalent 
> levels of service (NOTE:  In my experience, NAT44 ALGs are more complete 
> than NAT64 ALGs .... that is implementation level issues).

I seem to remember seeing text that this was harmful, but I might be 
mistaken.

> You want one DHCP solution for multiple access types?

Well, that is not my primary goal.

> specific access types, but i am likely missing something.

Well, for instance for the 3GPP scenario I have no idea if the client is 
going to request a v6 only PDP context, a v4v6 PDP context, or two 
different (v4/v6) PDP contexts, at the time I need to hand out DNS 
servers. I also do not know if the client is going v6 only by means of 
taking down it's v4 PDP context along the way.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 31 Jul 2012 06:09:05 +0200 (CEST)

On Mon, 30 Jul 2012, Jared Mauch wrote:

> Sounds like you want to modify the host stack (or application layer) to 
> have per-af resolvers and capabilities.  since you are stuck with 
> gethostbyname2() and similar, you need to push this elsewhere.  I'm not 
> sure the best way to address this as it requires a more comprehensive 
> rewrite of so many parts of the system.

Nope, I do not think that is what is being proposed.

> What is the overall ROI you see for this work?  Is this just a system to 
> provide polarization for or against v4("Classic IP")?

For me it would mean I could provide v6 only clients with NAT64 
connectivity on all access technologies for the forseeable future.

Another way might be that v6 only clients who desire NAT64 connectivity 
actually asked different questions than a dual stack client so that the 
resolver knew if it should give DNS64 answers or not. Perhaps that is a 
saner way to go?

I also do not understand your last sentence, could you please 
rephrase/elaborate?

---

From: Jared Mauch <[email-masked]>
Date: Tue, 31 Jul 2012 05:25:01 -0400

On Jul 31, 2012, at 12:09 AM, Mikael Abrahamsson <[email-masked]> wrote:

> 
> I also do not understand your last sentence, could you please rephrase/elaborate?

I think I am concerned about feature creep with the idea of providing a preference. I do think this will be challenging without significant changes in the host applications or stack. 

Jared

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 31 Jul 2012 12:35:32 +0200 (CEST)

On Tue, 31 Jul 2012, Jared Mauch wrote:

> I think I am concerned about feature creep with the idea of providing a 
> preference. I do think this will be challenging without significant 
> changes in the host applications or stack.

Ok.

So how do we adress the problem? Going a completely different route and go 
for the "discover NAT64 prefix"-heuritics and ask clients to implement 
that instead, if they're single stacked on v6?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 31 Jul 2012 12:36:47 +0200 (CEST)

> than NAT64 ALGs .... that is implementation level issues).

Well, in my example the client has un-NATed v4 and v6 service, but might 
sometimes not have v4 connectivity at all. So this is not a DNS64 vs DS 
NAT44 problem, it's a DNS64 vs DS non-NAT44 problem. I agree that if the 
client is behind NAT44, then this is less an issue.

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 31 Jul 2012 07:18:28 -0700

To clarify scope, there is a workable solution: seperate dhcp servers /
config / VMs  per access type.

The open question is for having one monolithic dhcp config for multiple
access types with different host configuration requirements.

So the ons monolithic server must make an intelligent decision ( select dns
server) bases on access type / relay agent (if from this relay access
network do x, else do y)

CB

---

From: jouni korhonen <[email-masked]>
Date: Wed, 1 Aug 2012 02:45:55 +0300

Hi,

On Jul 30, 2012, at 1:20 PM, Mikael Abrahamsson wrote:

> 
> Hello.
> 
> I would like to describe a problem that I do not have a solution to, thus trying to solicit possible remedies to it so please fire if you have any thoughts.
> 
> 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.

- Jouni

>  At the same time, I would like to avoid handing out the DNS64 resolver address if the client is dual stacked (I believe that is considered harmful?).
> 
> How could this be achieved? One way would be to extend the DHCP standard to hand out multiple DNS servers and have them tagged for different use, so the client would need to decide if it's single or dual stack, and choose DNS resolver accordingly.
> 
> Thoughts?
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 1 Aug 2012 07:30:06 +0200 (CEST)

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.
>

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...