Subject: [sunset4] An IPv4 sunset problem (?)

From: Simon Perreault <[email-masked]>
Date: Wed, 22 Aug 2012 11:53:32 -0400

Sunsetters,

Recently there has been discussion in v6ops about a problem that arises 
when a network infrastructure featuring NAT64+DNS64 is used by IPv6-only 
as well as dual-stack hosts. The problem is that you want the IPv6-only 
hosts to use the DNS64 but not the dual-stack hosts.

This is a well-known problem that has been discussed in behave and for 
which there is a solution that involves the hosts 
(draft-ietf-behave-nat64-discovery-heuristic), and another that involves 
only the network (provision different DNS resolver addresses to 
IPv6-only and dual-stack hosts). Those solutions may not apply in many 
cases: the first solution requires that all hosts be modified, while the 
second solution requires that one be able to differentiate IPv6-only 
from dual-stack hosts.

Question for the WG: should this be discussed in 
draft-ietf-sunset4-gapanalysis? If so, we would appreciate additional 
input. Additional solution ideas would also be appreciated...

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 22 Aug 2012 09:19:56 -0700

On Wed, Aug 22, 2012 at 8:53 AM, Simon Perreault
<[email-masked]> wrote:
> Sunsetters,
>
> Recently there has been discussion in v6ops about a problem that arises when
> a network infrastructure featuring NAT64+DNS64 is used by IPv6-only as well
> as dual-stack hosts. The problem is that you want the IPv6-only hosts to use
> the DNS64 but not the dual-stack hosts.
>

Is it enough to say "don't do that"?

I don't believe the IETF should take on this problem

CB

> This is a well-known problem that has been discussed in behave and for which
> there is a solution that involves the hosts
> only the network (provision different DNS resolver addresses to IPv6-only
> and dual-stack hosts). Those solutions may not apply in many cases: the
> first solution requires that all hosts be modified, while the second
> solution requires that one be able to differentiate IPv6-only from
> dual-stack hosts.
>
> draft-ietf-sunset4-gapanalysis? If so, we would appreciate additional input.
> Additional solution ideas would also be appreciated...
>
> Thanks,
> Simon
> --
> _______________________________________________
> sunset4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sunset4

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 22 Aug 2012 12:24:06 -0400

> Is it enough to say "don't do that"?

looks to me as too simplistic.  The scenario described is in fact very likely to happen.

> I don't believe the IETF should take on this problem

the gap analysis may state the problem (and reference the proposed solutions). 
But the IETF may decide to take or not take on the problem.  

Marc.

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 22 Aug 2012 18:37:44 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc
> Blanchet
> Sent: Wednesday, August 22, 2012 6:24 PM
> To: Cameron Byrne
> Cc: Simon Perreault; [email-masked]
> Subject: Re: [sunset4] An IPv4 sunset problem (?)
> 
> 

Given that the SP has a control over the DNS information (resolvers) provided to its 
customers I believe it could happen as an error case, but not as the intention. I am 
assuming that there are separate DNS servers running to serve dual-stack customers 
and NAT64 enabled ones.

> > CB

Cheers,
Ales

---

From: Simon Perreault <[email-masked]>
Date: Wed, 22 Aug 2012 12:40:55 -0400

> assuming that there are separate DNS servers running to serve dual-stack customers

Right. This corresponds to the second solution I described, which 
depends on the ISP's ability to differentiate IPv6-only from dual-stack 
hosts. In many cases it is impractical.

Simon

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 22 Aug 2012 12:45:51 -0400

Le 2012-08-22 à 12:40, Simon Perreault a écrit :

> Right. This corresponds to the second solution I described, which depends on the ISP's ability to differentiate IPv6-only from dual-stack hosts. In many cases it is impractical.

- there are many other places where the provisioning is not that controlled: think about an Internet café. 

Marc.

---

From: <[email-masked]>
Date: Wed, 22 Aug 2012 18:54:09 +0200

Hi Simon,

This issue has been already documented in depth in http://tools.ietf.org/html/draft-ietf-behave-nat64-learn-analysis-03.

I'm not sure if there is a value to re-discuss this point in the gap analysis document.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] 
>[mailto:[email-masked]] De la part de Simon Perreault
>Envoyé : mercredi 22 août 2012 17:54
>À : [email-masked]
>Objet : [sunset4] An IPv4 sunset problem (?)
>
>Sunsetters,
>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 22 Aug 2012 12:56:10 -0400

> This issue has been already documented in depth in http://tools.ietf.org/html/draft-ietf-behave-nat64-learn-analysis-03.

This corresponds to the first solution I described. It requires that all 
hosts be modified to be able to discover the NAT64 prefix. This is often 
impractical.

Thanks,
Simon

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 22 Aug 2012 12:58:56 -0400

> This issue has been already documented in depth in http://tools.ietf.org/html/draft-ietf-behave-nat64-learn-analysis-03.

maybe, but for a document (gap analysis) that should state potential issues when turning IPv4 off in a network, I think that issue (two sets of stacks in an IPv6-only network with NAT64)  is relevant to be listed.  

Maybe it is a short paragraph that points to the others (such as the one you are referencing to), so we avoid multiple discussions. I leave it to the editors to review the referenced texts and write whatever is appropriate.

Marc.

---

From: <[email-masked]>
Date: Thu, 23 Aug 2012 07:42:38 +0200

Hi Marc,

Please see inline.

Cheers,
Med 

>De : Marc Blanchet [mailto:[email-masked]] 
>Envoyé : mercredi 22 août 2012 18:59
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : Simon Perreault; [email-masked]
>Objet : Re: [sunset4] An IPv4 sunset problem (?)
>
>
>> This issue has been already documented in depth in 
>http://tools.ietf.org/html/draft-ietf-behave-nat64-learn-analysis-03.
>> 
>
>maybe, but for a document (gap analysis) that should state 
>potential issues when turning IPv4 off in a network,

Med: If IPv4 is turned off, then no host will be dual-stack serviced...so there is no issue at all with NAT64/DNS64. The issue is when there are a mixture of IPv6-only connectivity and DS connectivity; but that one can be solved in various was as having distinct dns servers or using one of the solutions listed in the behave draft. 

 I think 
>that issue (two sets of stacks in an IPv6-only network with 
>NAT64)  is relevant to be listed.  
>
>Maybe it is a short paragraph that points to the others (such 
>as the one you are referencing to), so we avoid multiple 
>discussions. I leave it to the editors to review the 
>referenced texts and write whatever is appropriate.
>
>Marc.
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Aug 2012 21:19:56 -0400

>>>>> "mohamed" == mohamed boucadair <[email-masked]> writes:
    mohamed> Med: If IPv4 is turned off, then no host will be dual-stack
    mohamed> serviced...so there is no issue at all with
    mohamed> NAT64/DNS64. The issue is when there are a mixture of
    mohamed> IPv6-only connectivity and DS connectivity; but that one
    mohamed> can be solved in various was as having distinct dns servers
    mohamed> or using one of the solutions listed in the behave draft.  

Is a dual-home host (smartphone: wifi+3G) in scope?
wifi could be IPv6 only, 3G could well be (and is for me) NAT44-only.

The wifi infrastructure thinks it is dealing/providing an IPv6 only
network.  The phone however seems to be DS.  The phone might otherwise
enable Teredo or something to get connectivity to V6-only hosts over NAT44.

If the infrastructure could signal NAT64/DNS64, then the phone could know
for sure.  

-- 
Michael Richardson
-at the cottage-

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Aug 2012 11:43:40 -0400

> If the infrastructure could signal NAT64/DNS64, then the phone could know

That's a very good point IMHO.

Thanks!
Simon

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Aug 2012 13:52:28 -0400

>>>>> "Simon" == Simon Perreault <[email-masked]> writes:

    Simon> That's a very good point IMHO.

But, is this in scope for sunset4?

This thread has devolved into "but, we (over there: 6man/behave, I
think), that this was out of scope.  

-- 
Michael Richardson
-at the cottage-

---

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Aug 2012 16:15:07 -0400

> think), that this was out of scope.

Well, IMHO NAT64 is an IPv4 sunsetting technology and sunset4 is 
concerned with IPv4 sunsetting, and behave is shutting down, and it's 
out of scope for v6ops, so.....

But I'm no chair/AD.

Simon

---

From: Hui Deng <[email-masked]>
Date: Sat, 25 Aug 2012 10:31:37 +0800

http://tools.ietf.org/html/draft-korhonen-mif-ra-offload-04

2012/8/25 Simon Perreault <[email-masked]>

> Well, IMHO NAT64 is an IPv4 sunsetting technology and sunset4 is concerned
> with IPv4 sunsetting, and behave is shutting down, and it's out of scope
> for v6ops, so.....
>
> But I'm no chair/AD.
>
> Simon
>
> ______________________________**_________________
> sunset4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/sunset4<https://www.ietf.org/mailman/listinfo/sunset4>
>

---

From: Hui Deng <[email-masked]>
Date: Wed, 29 Aug 2012 09:49:34 +0800

excuse me for being late, vocation this week,

I guess this target both MIF and Sunset scenario. if it prefer IPv4
connection whatever it is wifi or 3G.
for NAT64, today only 3G deployment is XLAT464,  it can support Ipv4
connection as well,
whether to use nat44 in ipv4 or XLAT464 in 3g network might related to MIF
happy eyeball.

-Hui

2012/8/27 Michael Richardson <[email-masked]>

>
> >>>>> "Hui" == Hui Deng <[email-masked]> writes:
>     Hui> http://tools.ietf.org/html/draft-korhonen-mif-ra-offload-04
>
> okay, so this motivated so that the IPv6 3G can say to use the NAT44 on
> the wifi.   It seems that it can also let the IPv6 enabled wifi say,
> "please prefer this connection for IPv4".
>
> I'm not clear that it can say "please perfer this connection via
> DNS64/NAT64".
>
> Can you offer some opinion about whether or not it should be in scope
> for sunset4, or is this really a mif issue?
>
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works
>
>
>