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

[<mohamed.boucadair at orange-ftgroup.com>]

Hi Dan,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:dwing at cisco.com] 
Envoyé : samedi 7 novembre 2009 22:45
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : 'Christian Huitema'; teemu.savolainen at nokia.com; ajs at shinkuro.com; behave at ietf.org; draft-boucadair-behave-dns-a64 at tools.ietf.org
Objet : RE: draft-boucadair-behave-dns-a64-00.txt [was RE: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]

 

> -----Original Message-----
> From: mohamed.boucadair at orange-ftgroup.com
> [mailto:mohamed.boucadair at orange-ftgroup.com]
> Sent: Friday, November 06, 2009 1:00 AM
> To: Dan Wing
> Cc: 'Christian Huitema'; teemu.savolainen at nokia.com; ajs at shinkuro.com; 
> behave at ietf.org; draft-boucadair-behave-dns-a64 at tools.ietf.org
> Subject: RE: draft-boucadair-behave-dns-a64-00.txt [was RE: 
> [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]
> 
> 
> Hi Dan, all,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> -----Message d'origine-----
> De : Dan Wing [mailto:dwing at cisco.com] Envoyé : jeudi 5 novembre 2009 
> 19:07 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : 'Christian Huitema'; 
> teemu.savolainen at nokia.com; ajs at shinkuro.com; behave at ietf.org; 
> draft-boucadair-behave-dns-a64 at tools.ietf.org
> Objet : RE: draft-boucadair-behave-dns-a64-00.txt [was RE: 
> [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]
> 
>  
> 
> > -----Original Message-----
> > From: mohamed.boucadair at orange-ftgroup.com
> > [mailto:mohamed.boucadair at orange-ftgroup.com]
> > Sent: Thursday, November 05, 2009 6:49 AM
> > To: Dan Wing
> > Cc: 'Christian Huitema'; teemu.savolainen at nokia.com; 
> ajs at shinkuro.com; 
> > behave at ietf.org; draft-boucadair-behave-dns-a64 at tools.ietf.org
> > Subject: RE: draft-boucadair-behave-dns-a64-00.txt [was RE: 
> > [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]
> > 
> > 
> > Dear Dan,
> > 
> > Please see inline.
> > 
> > Cheers,
> > Med
> > 
> > -----Message d'origine-----
> > De : Dan Wing [mailto:dwing at cisco.com] Envoyé : vendredi 30 octobre 
> > 2009 18:09 À : BOUCADAIR Mohamed NCPI/NAD/TIP Cc : 'Christian 
> > Huitema'; teemu.savolainen at nokia.com; ajs at shinkuro.com; 
> > behave at ietf.org; draft-boucadair-behave-dns-a64 at tools.ietf.org
> > Objet : RE: draft-boucadair-behave-dns-a64-00.txt [was RE: 
> > [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt]
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: mohamed.boucadair at orange-ftgroup.com
> > > [mailto:mohamed.boucadair at orange-ftgroup.com]
> > > Sent: Sunday, October 25, 2009 6:34 AM
> > > To: Dan Wing
> > > Cc: 'Christian Huitema'; teemu.savolainen at nokia.com; 
> > ajs at shinkuro.com; 
> > > behave at ietf.org; draft-boucadair-behave-dns-a64 at tools.ietf.org
> > > 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.
> 
> 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?
> 
> 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?

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.  

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

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?

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. 

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

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.

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.

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

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.

Med: Agreed.

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.

Med: Agreed.

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