Subject: [BEHAVE] DNS64 Resolvers and Dual-Stack Hosts, draft-wing-behave-dns64-config-00

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Jan 2010 14:26:46 -0800

draft-wing-behave-dns64-config-00 should be of interest to both 3Gv6 and
BEHAVE.  The draft is related to recent threads on both mailing lists
discussing a DNS64 recursive resolver being used by a dual-stack host.

Abstract:
   Some networks are expected to support IPv4-only, dual-stack, and
   IPv6-only hosts at the same time.  Such networks also want to IPv6/
   IPv4 translation for the IPv6-only host so it can access servers on
   the IPv4 Internet.  On such a network, the synthesized AAAA responses
   from a DNS64 can cause traffic to be translated.  This document
   describes two solutions to avoid that translation:  modifying default
   address selection on the host, and using DHCP to configure different
   DNS recursive resolvers.

http://tools.ietf.org/html/draft-wing-behave-dns64-config-00

Comments welcome.

-d

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 7 Jan 2010 15:50:18 -0800 (PST)

Hi Dan,
  I read your draft. 
Looking from mobility point of view, I think that on page 4, to the protocols that have trouble with NAT64, MIPv6 should be added. 

However the solutions you proposed would not be good for MIPv6. That's the problem I have with your draft. I have not followed related discussions on Behave list, maybe some solutions have already been proposed there.

Regards,

Behcet

----- Original Message ----
> From: Dan Wing <[email-masked]>
> To: [email-masked]; Behave WG <[email-masked]>
> Sent: Thu, January 7, 2010 4:26:46 PM
> Subject: [3gv6] DNS64 Resolvers and Dual-Stack Hosts, draft-wing-behave-dns64-config-00
> 
> _______________________________________________
> 3gv6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/3gv6

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 7 Jan 2010 16:05:36 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
> Sent: Thursday, January 07, 2010 3:50 PM
> To: Dan Wing; [email-masked]; Behave WG
> Subject: Re: [BEHAVE] [3gv6] DNS64 Resolvers and Dual-Stack 
> Hosts,draft-wing-behave-dns64-config-00
> 
> Hi Dan,
>   I read your draft. 
> Looking from mobility point of view, I think that on page 4, 
> to the protocols that have trouble with NAT64, MIPv6 should be added. 

I understand FTP, but I don't understand MIPv6.  Is there something
I could read that explains the trouble that MIPv6 would have with
NAT64?  Would the trouble depend on which side of the MIPv6 gateway 
that the NAT64 exists?

> However the solutions you proposed would not be good for 
> MIPv6. That's the problem I have with your draft. I have not 
> followed related discussions on Behave list, maybe some 
> solutions have already been proposed there.

Not to my knowledge.

I'm not a mobile IP guy, so ideas on how this is solvable on
a 3GPP network are certainly welcome.  And I am interested in 
how tethered PCs (Windows 7, OSX) would work with any such 
solution.

-d

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

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 7 Jan 2010 16:21:39 -0800 (PST)

Hi Dan,

> NAT64?  Would the trouble depend on which side of the MIPv6 gateway

There are certain issues after roaming. Mainly, to do with the
construction of the v6 address/prefix for the target v4 destination.
draft-haddad identified few issues. Couple of us thought of proposing
a small solution for it, Teemu also had some related work in this
area. There is some minor work/clarifications needed. For 3GPP, the
considerations may be slightly different when compared to the
traditional MIPv6 approach. You may want to take a look at Wassim's
draft-haddad-behave-nat64-mobility-harmful-00.txt.

Regards
Sri

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 08 Jan 2010 10:28:26 +0800

Hi Dan,

Are the approaches defined in your proposal suitable in the following
scenario?

                                +-----------------+
                                |                 |
   +-----------------+          | IPv6 Internet   |  +-----+  +------------+
   | Dual-stack      +----------+                 +--+NAT64+--+ IPv4-only  |
   | IPv6-only mixed |          +-----------------+  +-----+  |            |
   |   +---------+   |                                        |   +----+   |
   |   | H1(D-S) |   | +-----+  +-----------------+           |   | H2 |   |
   |   +---------+   +-+NAT64+--+                 +-----------+   +----+   |
   +-----------------+ +-----+  | IPv4 Internet   |           +------------+
                                |                 |
                                +-----------------+
We are now writing a proposal about how to use the Hybrid Type Prefix, which
starts with a well-known value (e.g., "0x0064" ) and is topologically
aggregatable in the IPv6 Internet, to distinguish synthetic IPv6 addresses
from regular ones.

The following statement is quoted from the proposal mentioned above:

"...Preventing dual-stack hosts from using DNS64 service [DNS64] is not a
feasible way to address the above issue for this scenario since synthetic
AAAA records may be added to authoritative DNS servers.

Configuring NSP prefixes within H1’s address selection policy-table and
assigning them a lower selection priority is also unpractical for this
scenario since the NSPs used by the IPv4 only networks are various."

Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Dan
> Wing
> 发送时间: 2010年1月8日 6:27
> 收件人: [email-masked]; 'Behave WG'
> 主题: [BEHAVE] DNS64 Resolvers and Dual-Stack

---

From: Zhen Cao <[email-masked]>
Date: Fri, 8 Jan 2010 13:03:37 +0800

Hi Dan,

By specifying a new RR, draft-boucadair-behave-dns-a64-01 can also solve the
problem.

Thanks,
Zhen

---

From: <[email-masked]>
Date: Fri, 8 Jan 2010 14:17:00 +0800

hi Dan

I think the solution 2 will increase the complexity for DHCP server. if the DHCPV4 server is combined with DHCPV6 server, then these two DHCP procedures can share the same information of the client identifier  of the host.

but if the DHCPv4 server is seperated from DHCPV6 server ,then how to synchroniaze the state of  the entry of the client idertifier of the host may be a problem.  Does the DHCPv4 server notify the DHCPV6 server or the DHCPV6 server query related information from DHCPV4 server ?

Best Regards
---------------------------------------------------
Hui Xu
System & Standard Dept.
Datang Mobile Communications Equipment Co. Ltd. （CATT）

Tel:  +86 10 58833105
Fax: +86 10 58832784
Mailto: [email-masked]

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Dan Wing
发送时间: 2010年1月8日 6:27
收件人: [email-masked]; 'Behave WG'
主题: [3gv6] DNS64 Resolvers and Dual-Stack Hosts,draft-wing-behave-dns64-config-00

draft-wing-behave-dns64-config-00 should be of interest to both 3Gv6 and BEHAVE.  The draft is related to recent threads on both mailing lists discussing a DNS64 recursive resolver being used by a dual-stack host.

Abstract:

Comments welcome.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 08 Jan 2010 12:14:57 +0100

> Looking from mobility point of view, I think that on page 4, to the protocols that have trouble with NAT64, MIPv6 should be added. 

I don't think the problem is specific to MIPv6. the problem is general 
to any configuration that:
- Does not use the Well know prefix (i.e. if the WK prefix is used, 
there is no problem and everything works just fine)
- The node is using a dns server that is not in the same domain that the 
NAT64 the node is connected too.

For example you could have the same problem if you are connected to the 
local network that is providing NAT64 services and you decide to use a 
DNS server that is located in a different domain.

Regards, marcelo

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 8 Jan 2010 06:04:20 -0800

On Fri, Jan 8, 2010 at 3:14 AM, marcelo bagnulo braun
<[email-masked]> wrote:
>>  I read your draft. Looking from mobility point of view, I think that on
>> page 4, to the protocols that have trouble with NAT64, MIPv6 should be
>> added.
>
> I don't think the problem is specific to MIPv6. the problem is general to
> any configuration that:
> - Does not use the Well know prefix (i.e. if the WK prefix is used, there is
> no problem and everything works just fine)
> local network that is providing NAT64 services and you decide to use a DNS
> server that is located in a different domain.

Agreed.  This was covered on the BEHAVE list a while ago.

>
> Regards, marcelo
>
>> However the solutions you proposed would not be good for MIPv6. That's the
>> problem I have with your draft. I have not followed related discussions on
>> Behave list, maybe some solutions have already been proposed there.
>>
>> Regards,
>>
>> Behcet
>>
>>
>>

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 8 Jan 2010 09:52:18 -0500

> By specifying a new RR, draft-boucadair-behave-dns-a64-01 can also solve the

The new-RR approach is, as I have already argued, doomed.  It
certainly won't work for mixed networks like described in Dan's draft,
because for it to be useful everyone needs to upgrade (I've read the
arguments about why everyone doesn't need to upgrade, and they all
boil down to, "Well, it'll be less efficient if people haven't
upgraded.")

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 8 Jan 2010 08:08:18 -0800

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, January 07, 2010 10:17 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: re: [3gv6] DNS64 Resolvers and Dual-Stack 
> I think the solution 2 will increase the complexity for DHCP 
> server. if the DHCPV4 server is combined with DHCPV6 server, 
> then these two DHCP procedures can share the same information 
> of the client identifier  of the host.
> 
> but if the DHCPv4 server is seperated from DHCPV6 server 
> ,then how to synchroniaze the state of  the entry of the 
> client idertifier of the host may be a problem.  Does the 
> DHCPv4 server notify the DHCPV6 server or the DHCPV6 server 
> query related information from DHCPV4 server ?

Yes, it requires the DHCPv4 and DHCPv6 servers to communicate state with each
other, as I wrote in Section 3.2.2:

3.2.2. DHCPv4 and DHCPv6 Server Requirements

   The DHCPv4 and DHCPv6 servers have the following requirements:

   1.  the DHCPv4 and DHCPv6 servers MUST be able to communicate with
       each other both client-identifiers [RFC4361] and if an IPv4
       address is assigned to that client-identifier; and,
  ...

-d

> draft-wing-behave-dns64-config-00 should be of interest to 
> both 3Gv6 and BEHAVE.  The draft is related to recent threads 
> on both mailing lists discussing a DNS64 recursive resolver 
> being used by a dual-stack host.
> 
> Abstract:

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 8 Jan 2010 08:50:25 -0800

> From: Zhen Cao [mailto:[email-masked]] 
> Sent: Thursday, January 07, 2010 9:04 PM
> To: Dan Wing
> Cc: 3gv6; Behave WG
> Subject: Re: [BEHAVE] DNS64 Resolvers and Dual-Stack Hosts, 
> draft-wing-behave-dns64-config-00
> 
> Hi Dan, 
> 
> By specifying a new RR, draft-boucadair-behave-dns-a64-01 can 
> also solve the problem. 

It requires changing DNS all over the place, though, and not just in the
network that is operating the NAT64/DNS64 infrastructure.  I don't see how to
get that deployed.  There was a lengthy thread on BEHAVE about it, starting
approximately at
http://www.ietf.org/mail-archive/web/behave/current/msg07324.html

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 8 Jan 2010 09:14:21 -0800

> From: marcelo bagnulo braun [mailto:[email-masked]] 
> Sent: Friday, January 08, 2010 3:15 AM
> To: Behcet Sarikaya
> Cc: Dan Wing; [email-masked]; Behave WG
> Hosts, draft-wing-behave-dns64-config-00
> 
> > Looking from mobility point of view, I think that on page 
> 4, to the protocols that have trouble with NAT64, MIPv6 
> should be added. 
> >   
> 

But well-known prefix does not 'just work' if the local network
is not operating a NAT64 at all.  For example, if the local
network is dual-stack, it has no reason to operate a NAT64.
But if the dual-stack host is pointing to an off-site DNS64, 
and that off-site DNS64 is returning synthesized AAAA records
containing the well-known prefix, the dual-stack host will
be unable to connect to anything without timing out and
falling back to IPv4.

> For example you could have the same problem if you are 
> connected to the local network that is providing NAT64 
> services and you decide to use a DNS server that is 
> located in a different domain.

Yes, we should encourage hosts to Not Do That with DNS64.

I just read draft-haddad-mext-nat64-mobility-harmful-00, and I believe the
problems described in its Section 3 could be resolved by the MN following the
recommendation of draft-savolainen-mif-dns-server-selection -- namely, only
use a DNS response on the same interface as the DNS response itself.  This
means that the DNS query should be sent over the same interface as the tunnel
interface (to the foreign network), and the response is only valid for that
same interface.  This can be difficult on many stacks, though (because many
stacks do not concern themselves with which interface received a DNS
response).  That difficulty can be eased if all the networks are using NAT64
with their own network-specific prefix (NSP, as described in
draft-ietf-behave-address-format), as the different NSP allows RFC3484 address
selection rules can choose the correct interface.

-d

> both 3Gv6 and

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 8 Jan 2010 09:41:15 -0800 (PST)

----- Original Message ----
> From: marcelo bagnulo braun <[email-masked]>
> To: Behcet Sarikaya <[email-masked]>
> Cc: Dan Wing <[email-masked]>; [email-masked]; Behave WG <[email-masked]>
> Sent: Fri, January 8, 2010 5:14:57 AM
> Subject: Re: [BEHAVE] [3gv6] DNS64 Resolvers and Dual-Stack Hosts, draft-wing-behave-dns64-config-00
> 
> > Looking from mobility point of view, I think that on page 4, to the protocols 
> that have trouble with NAT64, MIPv6 should be added. 
> >  
> 

Is it feasible though? In draft-wing-behave-dns64-config-00, there are two different prefixes are mentioned in Section 3.3 already.

> DNS server that is located in a different domain.

Agreed.

Regards,

Behcet

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 08 Jan 2010 19:55:11 +0100

> network is dual-stack, it has no reason to operate a NAT64.
are you assuming that the mobile node is dual stack of IPv6 only?

Regards, marcelo

>>>> Subject: [3gv6] DNS64 Resolvers and Dual-Stack Hosts, 
>>>>         
>>>> BEHAVE.  The draft is related to recent threads on both 
>>>>         
>> mailing lists
>>     
>>>> discussing a DNS64 recursive resolver being used by a 
>>>>         
>> dual-stack host.
>>     
>>>> Abstract:
>>>>   IPv6-only hosts at the same time.  Such networks also 
>>>>         
>> want to IPv6/
>>     
>>>>   IPv4 translation for the IPv6-only host so it can access 
>>>>         
>> servers on
>>     
>>>>   the IPv4 Internet.  On such a network, the synthesized 
>>>>         
>> AAAA responses
>>     
>>>>   describes two solutions to avoid that translation:  
>>>>         
>> modifying default
>>     
>>>>   address selection on the host, and using DHCP to 
>>>>         
>> configure different
>>     
>>>>   DNS recursive resolvers.
>>>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 08 Jan 2010 20:01:53 +0100

> Is it feasible though? In draft-wing-behave-dns64-config-00, there are two different prefixes are mentioned in Section 3.3 already.
what do you mean?
the network admin can choose to use whatever prefix it wants, so if he 
decides to use the WKP, then some of these issues will go away.

Regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 8 Jan 2010 11:30:04 -0800

> [mailto:[email-masked]] On Behalf Of marcelo bagnulo braun
> Sent: Friday, January 08, 2010 10:55 AM
> To: Dan Wing
> Cc: [email-masked]; 
> 'Behcet Sarikaya'; [email-masked]; 'Behave WG'

I'm not sure it matters:

Let's assume the mobile node is dual-stack, and encounters a 
dual-stack network that is not operating a NAT64.  If that 
mobile node (for whatever reason) sends a query to a DNS64
somewhere on the Internet which returns an AAAA with the
well-known prefix (64:FF9B::/96) such as, for example, 
64:FF9B::192.0.2.1, the mobile node will send a TCP SYN to
64:FF9B::192.0.2.1 which won't route anywhere.  The mobile
node will timeout its attempted TCP connection.

Let's assume the mobile node is IPv6-only, and encounters a
dual-stack network that is not operating a NAT64.  If that
mobile node (for whatever reason) sends a query to a DNS64
somewhere on the Internet which returns an AAAA with the
well-known prefix (64:FF9B::/96) such as, for example, 
64:FF9B::192.0.2.1, the mobile node will send a TCP SYN to
64:FF9B::192.0.2.1 which won't route anywhere.  The mobile
node will timeout its attempted TCP connection.

-d

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 8 Jan 2010 13:41:52 -0800 (PST)

----- Original Message ----
> Sent: Fri, January 8, 2010 1:01:53 PM
> >> From: marcelo bagnulo braun 
> >> To: Behcet Sarikaya 
> >> Cc: Dan Wing ; [email-masked]; Behave WG 
> page 4, to the protocols      
> >> I don't think the problem is specific to MIPv6. the problem is general to any 
> configuration that:
> > Is it feasible though? In draft-wing-behave-dns64-config-00, there are two 
> different prefixes are mentioned in Section 3.3 already.
> > 
> >  
> what do you mean?
> the network admin can choose to use whatever prefix it wants, so if he decides 
> to use the WKP, then some of these issues will go away.
> 

How about collocating NAT64 box with the mobility entities like LMA or HA, as we proposed for NAT44 box of DS-Lite in 

draft-sarikaya-softwire-dslitemobility-01? I think that also solves the problem, even if the different networks use different prefixes.

Regards,

Behcet

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 09 Jan 2010 12:58:06 +0100

Behcet Sarikaya escribió:
>>>> Subject: Re: [BEHAVE] [3gv6] DNS64 Resolvers and Dual-Stack Hosts, 
>>>>         

In the case of MIP,
i doubt that would solve the problem. I mean, if the node decides to use 
the DNS server provided by the visited network and uses the NAT64 in its 
hme network, and they happen to be using different prefixes, not matter 
whehter the NAT64 is located in the HA or somewhere else in the home 
network, the communications will fail if they use the BT mode.

The solution is to make sure that the mn uses the dns64 and the nat64 
use the same prefix, which can be done by using the WKP or by using a 
paired nat64 and dns64

In the case of PMIP, if the mobility is within a single domain, then we 
could easily assume the the dns64 and the na64 are run in the same 
domain, and that would address the issue

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 09 Jan 2010 13:06:43 +0100

Dan Wing escribió:
>>>> - Does not use the Well know prefix (i.e. if the WK prefix 
>>>>         
>> is used, 
>>     
> Let's assume the mobile node is dual-stack,

if the mobile node is dual stack, it should be running dsmip, i guess 
and i don't think it would make sense to expose dns64 information to 
it... but maybe more dsmip experts can correct me here

so i would focus on the ipv6 only mn case imho
>  and encounters a 
correct, but what is the alternative?
I mean, if the dns64 creates the synthetic RR, it is because there is no 
real AAAA RR, so the target host is IPv4 only.
So, the only option for communication between the IPv6 only MN and the 
IPv4 only CN is to use a NAT64.
If there is no NAT64 available, the communication will fail, and this is 
not a problem of the type of prefix used for the communication.

So, i would argue that in this case, the communication fails, but not 
because the nat64 is harmful, but due to the lack of nat64.

So, my argument that the WKP shoudl solve this particular type of cases, 
in all the cases the communication could possibly work.

So, for dual stack MN, use dsmip
For IPv6 only nodes, use nat64/dns64 plus the WKP.

makes sense?

Regards, marcelo

>>> I just read draft-haddad-mext-nat64-mobility-harmful-00, 
>>>       
>> and I believe the
>>     
>>> problems described in its Section 3 could be resolved by 
>>>       
>> the MN following the
>>     
>>> recommendation of draft-savolainen-mif-dns-server-selection 
>>>       
>> -- namely, only
>>     
>>> use a DNS response on the same interface as the DNS 
>>>       
>> response itself.  This
>>     
>>> means that the DNS query should be sent over the same 
>>>       
>> interface as the tunnel
>>     
>>> interface (to the foreign network), and the response is 
>>>       
>> only valid for that
>>     
>>> same interface.  This can be difficult on many stacks, 
>>>       
>> though (because many
>>     
>>> response).  That difficulty can be eased if all the 
>>>       
>> networks are using NAT64
>>     
>>> draft-ietf-behave-address-format), as the different NSP 
>>>       
>> allows RFC3484 address
>>     
>>>>>>   Some networks are expected to support IPv4-only, 
>>>>>>             
>> dual-stack, and
>>

---

From: <[email-masked]>
Date: Mon, 11 Jan 2010 16:40:58 +0100

Dear Dan, all,

I'm still convinced that you don't need to upgrade all the DNS in place. We have already documented this in the draft. Furthermore, we think that a first step is to update authoritative servers in realms which support translators and rely on http://tools.ietf.org/html/draft-bellis-dns-recursive-discovery-00 to discover an authoritative server. Doing so does not require to update intermediary DNS recursive servers. Other alternatives to solve the backward compatibility issue is to rely on what is specified in http://tools.ietf.org/html/draft-boucadair-behave-dns64-discovery-00 for the discovery of DNS64 service (e.g., DNS SRV, DHCPv6). It does not require any cooperation between service elements located at the service provider realm but requires a decision-making process to be supported by client to drive the invocation of DNS64 service or native IPv6 DNS server appropriately.

Unlike the A64, the proposal defined in your draft does not cover the general use case since it may solve the problem only when the hosts and the translators are attached to the same administrative domain, otherwise it won't work (i.e., translators will be crossed even if DS hosts are involved in the path)...

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : vendredi 8 janvier 2010 17:50
À : 'Zhen Cao'
Cc : '3gv6'; 'Behave WG'
Objet : Re: [3gv6] [BEHAVE] DNS64 Resolvers and Dual-Stack Hosts, draft-wing-behave-dns64-config-00

-d

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 Jan 2010 11:24:08 -0500

> use the same prefix, which can be done by using the WKP or by using a  

I think this is already clear in the dns64 draft: the dns64 needs to
be using the same prefix, even though there's no state automatically
shared with the nat64.  Isn't it?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 11 Jan 2010 09:27:35 -0800

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Monday, January 11, 2010 7:41 AM
> To: Dan Wing; 'Zhen Cao'
> Cc: '3gv6'; 'Behave WG'
> Subject: RE: [3gv6] [BEHAVE] DNS64 Resolvers and Dual-Stack 
> I'm still convinced that you don't need to upgrade all the 
> DNS in place. We have already documented this in the draft. 
> Furthermore, we think that a first step is to update 
> authoritative servers in realms which support translators and 
> rely on 
> http://tools.ietf.org/html/draft-bellis-dns-recursive-discover
> y-00 to discover an authoritative server. Doing so does not 
> require to update intermediary DNS recursive servers. Other 
> alternatives to solve the backward compatibility issue is to 
> rely on what is specified in 
> http://tools.ietf.org/html/draft-boucadair-behave-dns64-discov
> ery-00 for the discovery of DNS64 service (e.g., DNS SRV, 
> DHCPv6). It does not require any cooperation between service 
> elements located at the service provider realm but requires a 
> decision-making process to be supported by client to drive 
> the invocation of DNS64 service or native IPv6 DNS server 
> appropriately.
> 
> Unlike the A64, the proposal defined in your draft does not 
> cover the general use case since it may solve the problem 
> only when the hosts and the translators are attached to the 
> same administrative domain, otherwise it won't work (i.e., 
> translators will be crossed even if DS hosts are involved in 
> the path)...

The problem I was trying to solve in draft-wing-behave-dns64-config is:

  "how can we prevent a dual-stack host from unnecessarily 
   getting NAT64 translation"

The documents you cited above are attempting to solve a different problem,
which might be summarized as:

  "how can an IPv6-only host be configured with its DNS64"

In draft-wing-behave-dns64-config, I proposed two solutions to the dual-stack
host trying to avoid NAT64:

  1. adjust the host's RFC3484 table (to prefer IPv4 over IPv6 addresses with
     the translator's prefix).  This would allow the dual-stack host to use a
     DNS64 and effectively never use the synthesized AAAA responses

  2. using DHCPv4 and DHCPv6 servers, detect if the host is dual-stack,
     and configure it with a 'normal' DNS server or DNS64 server, as
     appropriate.  And at the very top of that section the document
     says:

       "Note:  due to the limitations of this solution (see
        Section 3.2.5), it may have little or no value."

When I finished draft-wing-behave-dns64-config, I reached the conclusion that
the DHCP solution is hard, and doesn't work on commonly-deployed OSs, so
should not be pursued.  

That leaves RFC3484 tweaking as a possible solution to investigate further for
the problem of avoiding NAT64 translation for a dual-stack host.  

Alternatively, we could decide that optimizing out NAT64 for dual-stack hosts
is not a problem worth solving, considering that NAT44 is likely on the IPv4
path for that same dual-stack host.

-d

> This message and any attachments (the "message") are 
> confidential and intended solely for the addressees. 
> If you are not the intended addressee of this message, please 
> cancel it immediately and inform the sender.

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 11 Jan 2010 17:05:27 -0800 (PST)

----- Original Message ----
> Sent: Sat, January 9, 2010 5:58:06 AM
> >>>> From: marcelo bagnulo braun To: Behcet Sarikaya Cc: Dan Wing ; 
> [email-masked]; Behave WG Sent: Fri, January 8, 2010 5:14:57 AM
> any        
> > draft-sarikaya-softwire-dslitemobility-01? I think that also solves the 
> problem, even if the different networks use different prefixes.
> > 
> >  
> 
> In the case of MIP,
> i doubt that would solve the problem. I mean, if the node decides to use the DNS 
> server provided by the visited network and uses the NAT64 in its hme network, 
> and they happen to be using different prefixes, not matter whehter the NAT64 is 
> located in the HA or somewhere else in the home network, the communications will 
> fail if they use the BT mode.
> 
> The solution is to make sure that the mn uses the dns64 and the nat64 use the 
> same prefix, which can be done by using the WKP or by using a paired nat64 and 
> dns64
> 
> In the case of PMIP, if the mobility is within a single domain, then we could 
> easily assume the the dns64 and the na64 are run in the same domain, and that 
> would address the issue
> 

You may be right. I personally am not a fan of solutions that are not mobility friendly also requiring modifications to well established services like DNS.

What happened to the solutions developed in the years of 2000, when the transition was a hot issue?

No offense to you or your co-authors, though.

Regards,

Behcet

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 11 Jan 2010 18:52:46 -0800

> From: Behcet Sarikaya [mailto:[email-masked]] 
> Sent: Monday, January 11, 2010 5:05 PM
> To: marcelo bagnulo braun
> > >>>> - Does not use the Well know prefix (i.e. if the WK 
> prefix is used, there 
> > is        
> > >>> Is it feasible though? In 
> draft-wing-behave-dns64-config-00, there are two  
> >     
> > > How about collocating NAT64 box with the mobility 
> entities like LMA or HA, as 
> > we proposed for NAT44 box of DS-Lite in 
> You may be right. I personally am not a fan of solutions that 
> are not mobility friendly also requiring modifications to 
> well established services like DNS.

Yes, IPv6/IPv4 translation has side-effects.  Wish it wasn't
true, but IPv6 was not designed to be upgradable from IPv4.
If it was, we wouldn't be in the current predicament.

> What happened to the solutions developed in the years of 
> 2000, when the transition was a hot issue?

Are you referring to NAT-PT (RFC2766), published in February
2000?  RFC4966 happened to it, "Reasons to Move the Network 
Address Translator - Protocol Translator (NAT-PT) to Historic 
Status", http://tools.ietf.org/html/rfc4966.  Several months
after that, BEHAVE had its charter extended to cover IPv6/
IPv4 translation.  NAT-PT also munged with DNS, in a worse
way than DNS64.

> No offense to you or your co-authors, though.

No offense taken.  These discussions are important.

-d

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 12 Jan 2010 14:14:15 +0100

> shared with the nat64.  Isn't it?
yes, i was just restating this in ml

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 13 Jan 2010 09:49:22 +1300

Dan,

...
> If it was, we wouldn't be in the current predicament.

Just to be clear, the defect there is in IPv4. IPv4 was not
designed to be upgradable (e.g. by allowing for variable
length addresses). So we are condemned by history to choose
between dual stack and packet translation. Translation is
for cases where dual stack cannot be applied, and as Dan says
it has side effects. We've known that for 15 years.

> No offense taken.  These discussions are important.

What we are doing now is trying to minimise the side effects,
building on experience since NAT-PT was designed.
It's worth reading draft-penno-behave-64-analysis to
understand which side effects we can't elminate.

    Brian

---

From: David Crowe <[email-masked]>
Date: Thu, 14 Jan 2010 09:00:00 -0700

This is really an absurd statement. Nobody can require old protocols 
to predict the future. They can try, they can do some protection, but 
they'll usually get it wrong in some significant ways.

It's the responsibility of new protocols to deal with the known past 
not the responsibility of old protocols to deal with an unknown 
future.

- David Crowe

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Jan 2010 08:11:15 +1300

David,

You're missing my point. I don't mean to point the finger at the
IPv4 designers. But the *fact* is that the way IPv4 was designed
means that the available coexistence models are dual stack
or packet level translation. That is not a defect in IPv6,
it's just a fact of life.

Regards
   Brian Carpenter

On 2010-01-15 05:00, David Crowe wrote:
> This is really an absurd statement. Nobody can require old protocols to
> predict the future. They can try, they can do some protection, but
> It's the responsibility of new protocols to deal with the known past not
> the responsibility of old protocols to deal with an unknown future.
> 
> - David Crowe
> 
> 
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 15 Jan 2010 05:16:03 +0000

I just submitted a new version of the address format draft:

http://www.ietf.org/id/draft-ietf-behave-address-format-04.txt

Most of the changes in the new draft are editorial, e.g. hyphens, capitalizations, or replacing references to "hosts" by references to "nodes" when appropriate.

There are two substantial changes, in response to WGLC discussions and reviews:

1) There were several comments that the stateless discussion was hard to follow without an example. We added an example to the section discussing stateless address translation;

2) In response to a WG thread with Iljitsch and Brian Carpenter, we added a precision about address selection, stating:

   In some scenarios, a dual-stack host will unnecessarily send its
   traffic through an IPv6/IPv4 translator.  This can be caused by
   host's default address selection algorithm [RFC3484], referrals, or
   other reasons.  Optimizing these scenarios for dual-stack hosts is
   for future study.

We considered actually adding to the draft guidance about precedence of the various prefixes in address selection, but "it is complicated." For example, there are different rules for dual-stack hosts and IPv6-only hosts. We feel that it is best to leave that to a specialized document, and not overload the address format document.

-- Christian Huitema