Subject: Re: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-D Action:draft-ietf-behave-dns64-01.txt]

From: <[email-masked]>
Date: Wed, 4 Nov 2009 12:10:09 +0100

Hello Dan,
I hope that the answer to your question is more clear in the new version of the draft:  "draft-boucadair-behave-dns-a64-01.txt"

Just to summarize:
Querying an existing DNS64 with CD and DO bits set is just a specific request, but as we explain at the end of section 3.1 it is not enough. We need a specific record type to manage static entries in DNS pointing to IPv4-mapped-IPv6 addresses.
Such case append when NAT64 is used to interconnect IPv6 internet to an IPv4 network.
As explain in section A.4 of "draft-ietf-behave-dns64-01" the best way to address this scenario is to built a static entry in the authoritative DNS server with an IPv4-mapped-IPv6 address built with the Pref64::/n used by the operator of this domain. But if an AAAA record is used for this record a dual-stack host would prefer this AAAA records compared to the A record and all communications will pass through the NAT64 and may experience trouble with the ALG mechanisms.
An A64 records is just like an AAAA records but with a priority lower than a A records for a dual-stack host. An A64 records may be used in an Authoritative server and is not necessarily synthesized by the local DNS resolver.

Bets regards

	Eric BURGEY

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : jeudi 22 octobre 2009 19:09
À : BOUCADAIR Mohamed NCPI-NAD-TIP
Cc : 'Christian Huitema'; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : draft-boucadair-behave-dns-a64-00.txt [was RE: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]

> FYI, we have submitted a draft to describe the A64 record for 
> IPv4-mapped IPv6 addresses. An updated version of the draft 
> will be submitted soon

draft-boucadair-behave-dns-a64-00 requires the DNS64 and the host to implement
a new DNS resource record, A64, in order to learn if the DNS64 synthesized a
response.

Instead, have you considered just having the host query an
existing DNS64 with the CD and DO bits set (which disables the
DNS64's AAAA synthesis) and have the host do its own DNS64 
processing?  See item #3 in
http://tools.ietf.org/html/draft-ietf-behave-dns64-01#section-5.5

If you have considered that technique, I expect you found some sort
of disadvantage to that technique.  Please share.

-d

---

From: <[email-masked]>
Date: Thu, 5 Nov 2009 15:48:40 +0100

Dear Dan, 

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : vendredi 30 octobre 2009 18:09
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : 'Christian Huitema'; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : RE: draft-boucadair-behave-dns-a64-00.txt [was RE: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Sunday, October 25, 2009 6:34 AM
> To: Dan Wing
> Cc: 'Christian Huitema'; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: RE: draft-boucadair-behave-dns-a64-00.txt [was RE: 
> [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]
> 
> 
> Hi Dan, all,
> 
> I'm aware about that mode. In fact it is also part of draft-boucadair 
> spec.

Where?  I cannot find the string "CD", "DO", or "bit".

Med: Yes. What I meant is that draft-boucadair assumes that draft-behave-dns64 can be seen as the first step of deployment. Therefore, the dsn64 spec applies. 

> The procedure described in
> draft-ietf-behave-dns64 is assumed as the first step. 
> draft-boucadair is a step forward to solve some pending issues as 
> elaborated in 01 version of draft-boucadair. Please refer to Section 
> Q/A of the updated draft for more discussion.
> 
> Do you have in mind explicit "disadvantages"?

DNS64 already supports the ability for a host to get an un-synthesized response (that is, effectively send a query that does not invoke the DNS64 function).  A dual-stack host can simply do that -- without needing changes to the DNS64 specification and without needing a new RR.

Med: Yes, but the dual stack host does not have any means to prefer native records from synthesised ones. Consequently, the traffic may go through the translators even if this can be avoided. This is typically one of the contributions of A64 record. As Eric said earlier A64 records is just like an AAAA records but with a priority lower than a records for a dual-stack host.

-d

> Cheers,
> Med
> De : Dan Wing [mailto:[email-masked]] Envoyé : jeudi 22 octobre 2009 
> 19:09 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : 'Christian Huitema'; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Objet : draft-boucadair-behave-dns-a64-00.txt [was RE: 
> [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]
> 
> > IPv4-mapped IPv6 addresses. An updated version of the draft will be 
> > submitted soon
> 
> draft-boucadair-behave-dns-a64-00 requires the DNS64 and the host to 
> implement a new DNS resource record, A64, in order to learn if the 
> DNS64 synthesized a response.
> 
> Instead, have you considered just having the host query an existing 
> DNS64 with the CD and DO bits set (which disables the DNS64's AAAA 
> synthesis) and have the host do its own
> DNS64 processing?  See item #3 in
> If you have considered that technique, I expect you found some sort of 
> disadvantage to that technique.  Please share.
> 
> -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.
> ********************************
> 

*********************************
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: "Dan Wing" <[email-masked]>
Date: Thu, 5 Nov 2009 10:03:59 -0800

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Wednesday, November 04, 2009 3:10 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> I hope that the answer to your question is more clear in the 
> new version of the draft:  "draft-boucadair-behave-dns-a64-01.txt"

The new Section 3.1 helps, yes.  Thanks.  In summary, it seems
A64 is intended to help a dual-stack host determine IPv6/IPv4 
translation will occur, and thus prefer native IPv4 connectivity 
instead of (the RFC3484 default) IPv6 connectivity through a 6/4 
translator.

There is text in DNS64 that points out a dual-stack host should
not query a DNS64,
http://tools.ietf.org/html/draft-ietf-behave-dns64-02#section-6,
which seems to eliminate a few -- but not all -- of the points
in http://tools.ietf.org/html/draft-boucadair-behave-dns-a64-01#section-3.1

> Just to summarize:
> Querying an existing DNS64 with CD and DO bits set is just a 
> specific request, but as we explain at the end of section 3.1 
> it is not enough.
>
> We need a specific record type to manage 
> static entries in DNS pointing to IPv4-mapped-IPv6 addresses.
> As explain in section A.4 of "draft-ietf-behave-dns64-01" the 
> best way to address this scenario is to built a static entry 
> in the authoritative DNS server with an IPv4-mapped-IPv6 
> address built with the Pref64::/n used by the operator of 
> this domain. But if an AAAA record is used for this record a 
> dual-stack host would prefer this AAAA records compared to 
> the A record and all communications will pass through the 
> NAT64 and may experience trouble with the ALG mechanisms.
> An A64 records is just like an AAAA records but with a 
> priority lower than a A records for a dual-stack host. An A64 
> records may be used in an Authoritative server and is not 
> necessarily synthesized by the local DNS resolver.

Ok.  I understand the purpose now.  Thanks for the additional
text in -01 and for this email response.

-d

> Cc : 'Christian Huitema'; [email-masked]; 
> [email-masked]; [email-masked];

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Nov 2009 10:06:56 -0800

> Sent: Thursday, November 05, 2009 6:49 AM
> To: Dan Wing
> Cc: 'Christian Huitema'; [email-masked]; 
> Objet : RE: draft-boucadair-behave-dns-a64-00.txt [was RE: 
> Med: Yes. What I meant is that draft-boucadair assumes that 
> draft-behave-dns64 can be seen as the first step of 
> deployment. Therefore, the dsn64 spec applies. 
> 
> 
> DNS64 already supports the ability for a host to get an 
> un-synthesized response (that is, effectively send a query 
> that does not invoke the DNS64 function).  A dual-stack host 
> can simply do that -- without needing changes to the DNS64 
> specification and without needing a new RR.
> 
> Med: Yes, but the dual stack host does not have any means to 
> prefer native records from synthesised ones. Consequently, 
> the traffic may go through the translators even if this can 
> be avoided. This is typically one of the contributions of A64 
> record. As Eric said earlier A64 records is just like an AAAA 
> records but with a priority lower than a records for a 
> dual-stack host.

I would be interested in how we might detect a dual-stack host
is querying a DNS64; afterall, if we can detect that, and we
can have the DNS64 not do its AAAA synthesis in that case, I 
believe we would achieve the same goal as A64 -- correct?

-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: <[email-masked]>
Date: Fri, 6 Nov 2009 09:59:47 +0100

Hi Dan, all,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : jeudi 5 novembre 2009 19:07
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : 'Christian Huitema'; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : RE: draft-boucadair-behave-dns-a64-00.txt [was RE: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]

> De : Dan Wing [mailto:[email-masked]] Envoyé : vendredi 30 octobre 
> 2009 18:09 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : 'Christian 
> Huitema'; [email-masked]; [email-masked]; 
> [email-masked]; 

Med: as far as dual stack are concerned, my answer to your question is: YES (an alternative solution would be to use the solution defined in http://tools.ietf.org/html/draft-boucadair-behave-dns64-discovery-00#section-3.1). But, we still have other issues as listed in the draft. Below an excerpt from draft-boucadair-behave-dns-a64-01:

 2.  [I-D.ietf-behave-dns64] points out in appendix A.4 the needs to
       introduce IPv4-mapped IPv6 address in DNS server that are
       authoritative for a specific QNAME.  The IPv6 prefix used to
       build this IPv4-mapped IPv6 address has been chosen by the
       administrator of the requested QNAME and is not necessarily known
       by the operator providing the Internet access service to the
       requesting host.  So to solve this problem, a mechanism is needed
      to exchange information between Internet access provider to
       distinguish an IPv4-mapped IPv6 address from a native IPv6
       address.  Exchanging A64 records for IPv4-mapped IPv6 address
       instead of AAAA records between DNS recursors and authoritative
       server solves this issue;

   3.  [I-D.ietf-behave-dns64] describes in appendix B cases where both
       IPv4-mapped IPv6 address and native IPv6 can be returned in AAAA
       records and points out that without a specific mechanism to
       distinguish between them the standard process may choose the
       IPv4-mapped IPv6 address.  Using A64 records for IPv4-mapped IPv6
       address solves this issue;

   4.  A dual-stack application receiving an IPv4-mapped IPv6 address is
       not aware that the destination application entity is using an
       IPv4 address.  That application entity may not be able to
       understand any reference in the packet payload to an IPv6
       address.  With the introduction of A64 records, it is possible to
       develop a new API so that updated (i.e., A64-compliant) dual-
       stack applications are able to learn that the IPv6 address comes
       from an A64 records and is an IPv4-mapped IPv6 address.
       Operating systems with this new API may embed a sDN64 function to
       deal with non updated IPv6 applications (i.e., non A64 compliant
       applications).

Cheers,
Med

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 7 Nov 2009 13:44:33 -0800

> Sent: Friday, November 06, 2009 1:00 AM
> To: Dan Wing
> Med: as far as dual stack are concerned, my answer to your 
> question is: YES (an alternative solution would be to use the 
> solution defined in 
> http://tools.ietf.org/html/draft-boucadair-behave-dns64-discov
> ery-00#section-3.1).

Thanks for the pointer.  That basically says that the client
should always get a normal DNS server configured via DHCP
(normal = not a DNS64 nameserver), and if the client is IPv6-only,
it can query that nameserver to learn of a DNS64 nameserver 
it should be using instead.  Is that an accurate summary?

> But, we still have other issues as 
> listed in the draft. Below an excerpt from 
> draft-boucadair-behave-dns-a64-01:
> 
>  2.  [I-D.ietf-behave-dns64] points out in appendix A.4

For reference, that section is describing "IPv6 Internet to an
IPv4 network".  

> the needs to

I believe what you are describing is a situation where the DNS operator
is a different entity than the operator of the IPv6->IPv4 translator.  
For example, where someone has outsourced their DNS service but
is unaware of when the IPv6 address of their IPv6->IPv4 translator 
changes, they need to tell their DNS operator about the change. 
I'm not entirely clear on the scenario, but I think that's what you're
describing.  This seems akin to outsourcing your IPv6 server (or your
IPv4 server), and that whenever its IPv6 (or IPv4) address changes,
the DNS needs to be updated to reflect that change.  Would not DNS 
UPDATE [RFC2136] not be the mechanism to update the DNS record 
when the IPv6 address changes?

>        address solves this issue;

Agreed that A64 would solve that issue.  But so would
draft-wing-behave-learn-prefix, I think; after learning the prefix of the
local network's translator the RFC3484 tables could be adjusted to have lower
preference for translated addresses -- in much the same way A64 proposes that
A64 responses have lower preference than AAAA responses.

>        deal with non updated IPv6 applications (i.e., non A64 

The same opportunity for applications to be smarter is created with
draft-wing-behave-learn-prefix, I believe -- but draft-wing-behave-learn
prefix only optimizes the case where the translator is operated by the same
local network as the client.

Instead, A64 appears to optimize the case where an IPv6->IPv4 translator is in
front of an IPv4 host (e.g., a IPv4-only webserver), and you're trying to
*not* prefer RFC3484 rules to access that host; rather, you're trying to
prefer (native) IPv4 connectivity to access that host.  So, A64 would become a
'last resort' solely intended for use by IPv6-only hosts that have only one
choice to access that server -- that choice is to use the 6->4 translator in
front of the IPv4 server.

Please let me know where I have gone astray.

-d

---

From: <[email-masked]>
Date: Mon, 9 Nov 2009 15:35:25 +0100

Hi Dan,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : samedi 7 novembre 2009 22:45
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : 'Christian Huitema'; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Objet : RE: draft-boucadair-behave-dns-a64-00.txt [was RE: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]

> De : Dan Wing [mailto:[email-masked]] Envoyé : jeudi 5 novembre 2009 
> 19:07 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : 'Christian Huitema'; 

Med: It says that a host can be updated to be aware that: when a DNS64 service is used, it should not be preferred than what is retrieved from "normal" DNS servers. DNS64 service is used only when no record is retrieved using normal DNS service.  

Med: The scenario is where the NAT64 is not located in the domain managed by the underlying IP network provider which provides the connectivity to the requesting end host. Appropriate records are then injected in DNS by a remote service provider. That service provider can use A64 to store those records. These records can be retrieved recursively or interrogatively. 

Med: Agreed. draft-wing-behave-learn-prefix can be used when the NAT64 is located in the same domain as the one of the SP which provides the connectivity to the end host.

Med: Agreed.

Med: Agreed.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 9 Nov 2009 10:49:14 -0500

On Mon, Nov 09, 2009 at 03:35:25PM +0100, [email-masked] wrote:

> Med: The scenario is where the NAT64 is not located in the domain
> managed by the underlying IP network provider which provides the
> connectivity to the requesting end host. Appropriate records are
> then injected in DNS by a remote service provider. That service
> provider can use A64 to store those records. These records can be
> retrieved recursively or interrogatively.

What do you mean by "in the domain" here?  (Channelling Peter Koch,
I'll say that hosts are not really "in" a domain for the purposes of
lookup.)

A

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

---

From: <[email-masked]>
Date: Mon, 9 Nov 2009 17:02:35 +0100

Re-,

"domain" is to be understood as AS (Autonomous System).

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Andrew Sullivan
Envoyé : lundi 9 novembre 2009 16:49
À : [email-masked]
Objet : Re: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-D Action:draft-ietf-behave-dns64-01.txt]

On Mon, Nov 09, 2009 at 03:35:25PM +0100, [email-masked] wrote:

> connectivity to the requesting end host. Appropriate records are then 
> injected in DNS by a remote service provider. That service provider 
> can use A64 to store those records. These records can be retrieved 
> recursively or interrogatively.

What do you mean by "in the domain" here?  (Channelling Peter Koch, I'll say that hosts are not really "in" a domain for the purposes of
lookup.)

A

--
Andrew Sullivan
[email-masked]
Shinkuro, Inc.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave