Subject: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt

From: [email-masked]
Date: Mon, 19 Oct 2009 11:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
	Author(s)       : M. Bagnulo, et al.
	Filename        : draft-ietf-behave-dns64-01.txt
	Pages           : 29
	Date            : 2009-10-19

DNS64 is a mechanism for synthesizing AAAA records from A records.
DNS64 is used with an IPv6/IPv4 translator to enable client-server
communication between an IPv6-only client and an IPv4-only server,
without requiring any changes to either the IPv6 or the IPv4 node,
for the class of applications that work through NATs.  This document
specifies DNS64, and provides suggestions on how it should be
deployed in conjunction with IPv6/IPv4 translators.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-dns64-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 19 Oct 2009 14:15:56 -0400

Dear colleagues,

> 	Filename        : draft-ietf-behave-dns64-01.txt

I believe that the draft addresses all the concerns raised since the
last draft.  The editors would appreciate feedback.  I was late
getting this to the others, so any errors or omissions you can blame
on me alone.

A

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

---

From: <[email-masked]>
Date: Tue, 20 Oct 2009 15:46:53 +0200

Hi,

The draft contains question about multihoming:"In particular, how is the multi-homed host supposed to know that a given AAAA is synthetic?".

I just updated my MIF related draft http://tools.ietf.org/html/draft-savolainen-mif-dns-server-selection-01 to contain also this case.

The multi-homed host does not necessarily need to know AAAA is synthetic: it could assume split DNS can happen in IPv6 domain as well, and thus consider all AAAA responses it gets as interface local - not as host global. 

Anyhow, I don't think DNS64 specification has to solve this, as MIF WG exist to look at this problem domain. It is good to mention in DNS64 document, though.

Best regards,

	Teemu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Andrew Sullivan
>Sent: 19 October, 2009 21:16
>To: [email-masked]
>Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt
>
>Dear colleagues,
>
>> 	Title           : DNS64: DNS extensions for Network 
>Address Translation from IPv6 Clients to IPv4 Servers
>I believe that the draft addresses all the concerns raised 
>since the last draft.  The editors would appreciate feedback.  
>I was late getting this to the others, so any errors or 
>omissions you can blame on me alone.
>
>A
>
>
>--
>Andrew Sullivan
>[email-masked]
>Shinkuro, Inc.
>_______________________________________________
>Behave mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/behave
>

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 20 Oct 2009 10:01:16 -0400

> The multi-homed host does not necessarily need to know AAAA is synthetic: it could assume split DNS can happen in IPv6 domain as well, and thus consider all AAAA responses it gets as interface loca…

Ok, I see.

> Anyhow, I don't think DNS64 specification has to solve this, as MIF WG exist to look at this problem domain. It is good to mention in DNS64 document, though.

I'll put in a reference.  Thanks.

A

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

---

From: Christian Huitema <[email-masked]>
Date: Wed, 21 Oct 2009 16:39:31 +0000

> The draft contains question about multihoming:"In particular, how is the
> multi-homed host supposed to know that a given AAAA is synthetic?".

Wonder about that too. Isn't the best solution to create a new record type, say A4A6, that would contain the mapped addresses of IPv4 only hosts?

-- Christian Huitema

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 21 Oct 2009 13:05:35 -0400

On Wed, Oct 21, 2009 at 04:39:31PM +0000, Christian Huitema wrote:
> Wonder about that too. Isn't the best solution to create a new
> record type, say A4A6, that would contain the mapped addresses of
> IPv4 only hosts?

As I've been saying to someone else off-list about proposals like
that, the point of this whole DNS64 exercise is that we don't want to
have to rely on everyone in the world being upgraded in order to
provide a semblance of service continuity.  Anything that begins with
"let's add a DNS RRTYPE" isn't going to fly not because it's hard to
add DNSRRs (it'd be very easy for this case), but because getting all
the systems upgraded in order to achieve the goal is not possible.  If
we could do that, we could just get everyone onto IPv6, I think.  No?

A

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

---

From: <[email-masked]>
Date: Thu, 22 Oct 2009 13:44:39 +0200

Dear Christian, all,

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

	Title           : A64: DNS Resource Record for IPv4-mapped IPv6 Address
	Author(s)       : M. Boucadair, E. Burgey
	Filename        : draft-boucadair-behave-dns-a64-00.txt
	Pages           : 9
	Date            : 2009-10-18

In this context of IPv4-IPv6 interconnection, several solutions have been proposed.  Some of these solutions require the definition of a new IPv4-mapped IPv6 address [I-D.ietf-behave-address-format] which is used to represent an IPv4-only host in an IPv6 realms and the definition of a new mechanism called DNS64 for synthesizing a AAAA record, representing an IPv4-mapped IPv6 address in the DNS system, from the A record representing the IPv4 address of the IPv4-only host [I-D.ietf-behave-dns64].  This IPv4-mapped IPv6 address, when managed by a translator, is to be considered as "fake" address in a DNS system since it is not necessarily assigned to any host's interface qualified by the associated name.  This document defines a new DNS record type and query type to identify IPv4-mapped IPv6 address [I-D.ietf-behave-address-format] from native IPv6 ones.  The new record type and query type aim at helping the remote party to enforce its policies and avoid NAT64 boxes when possible.  Native addresses are to be preferred.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-boucadair-behave-dns-a64-00.txt

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Christian Huitema
Envoyé : mercredi 21 octobre 2009 18:40
À : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt

> The draft contains question about multihoming:"In particular, how is 
> the multi-homed host supposed to know that a given AAAA is synthetic?".

-- Christian Huitema

*********************************
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, 22 Oct 2009 10:08:31 -0700

> 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: Xuewei Wang <[email-masked]>
Date: Fri, 23 Oct 2009 16:12:21 +0800

Hi, mohamed,
I have noticed your new draft draft-boucadair-behave-dns-a64-00.  If i understand it correctly this draft makes DNS server to add a new a64 RR to represent an IPv4-mapped IPv6 addresses. Because the DNS server don't serve any specific NAT64s, so the prefix64 which the DNS server uses to construct a64 RR must be a Well-Known Prefix rather than a Network-Specific Prefix, is my understand correct?

Xuewei Wang
----- Original Message ----- 
From: <[email-masked]>
To: "Christian Huitema" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, October 22, 2009 7:44 PM
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt

Dear Christian, all,

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Christian Huitema
Envoyé : mercredi 21 octobre 2009 18:40
À : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt

-- Christian Huitema

---

From: <[email-masked]>
Date: Fri, 23 Oct 2009 10:34:39 +0200

Dear Xuewei, all,

The A64 proposal does not make any assumption about the type of the pref6 to be used. Both WKP and LIR prefixes are supported. We are currently updating the draft to describe a mode in which an authoritative server can be updated to support A64 (and therefore a LIR pref can be used).

Cheers,
Med 

-----Message d'origine-----
De : Xuewei Wang [mailto:[email-masked]] 
Envoyé : vendredi 23 octobre 2009 10:12
À : BOUCADAIR Mohamed NCPI/NAD/TIP; Christian Huitema; [email-masked]; [email-masked]; [email-masked]
Objet : [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-DAction:draft-ietf-behave-dns64-01.txt]

Hi, mohamed,

Xuewei Wang
----- Original Message -----
From: <[email-masked]>
To: "Christian Huitema" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, October 22, 2009 7:44 PM
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt

Dear Christian, all,

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Christian Huitema
Envoyé : mercredi 21 octobre 2009 18:40
À : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt

-- Christian Huitema

---

From: Xuewei Wang <[email-masked]>
Date: Fri, 23 Oct 2009 16:56:53 +0800

Looking forward to your updating draft ! 

Xuewei Wang
----- Original Message ----- 
From: <[email-masked]>
To: "Xuewei Wang" <[email-masked]>; "Christian Huitema" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: "BURGEY Eric RD-CORE" <[email-masked]>
Sent: Friday, October 23, 2009 4:34 PM
Subject: Re: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-DAction:draft-ietf-behave-dns64-01.txt]

Dear Xuewei, all,

Cheers,
Med 

-----Message d'origine-----
De : Xuewei Wang [mailto:[email-masked]] 
Envoyé : vendredi 23 octobre 2009 10:12
À : BOUCADAIR Mohamed NCPI/NAD/TIP; Christian Huitema; [email-masked]; [email-masked]; [email-masked]
Objet : [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-DAction:draft-ietf-behave-dns64-01.txt]

Hi, mohamed,

Xuewei Wang
----- Original Message -----
From: <[email-masked]>
To: "Christian Huitema" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, October 22, 2009 7:44 PM
Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt

Dear Christian, all,

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Christian Huitema
Envoyé : mercredi 21 octobre 2009 18:40
À : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt

-- Christian Huitema

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 23 Oct 2009 12:22:36 +0200

> of disadvantage to that technique.  Please share.

I am not sure there would be an actual practical reason for not doing 
that, but from a purist point of view (in case it is not a contradiction 
in terms talking about purism and nats in the same sentence), i 
understand that we would be overloading the DO and CD bits if we do that.

In particular, it would imply that you could not get the dns server to 
do the validation _and_ distinguish synthetic RR, i guess

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 23 Oct 2009 13:13:50 +0200

actually, i guess it makes more sense for the NSP prefix than for the WK 
prefix, since synthetic RR containing addresses witht he WKP can be 
distinguished by the WKP, i guess

Regards, marcelo

---

From: <[email-masked]>
Date: Fri, 23 Oct 2009 17:37:15 +0200

Dear Marcelo, all,

Agreed. 

Cheers,
Med

-----Message d'origine-----
De : marcelo bagnulo braun [mailto:[email-masked]] 
Envoyé : vendredi 23 octobre 2009 13:14
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Xuewei Wang; Christian Huitema; [email-masked]; [email-masked]; [email-masked]; BURGEY Eric RD-CORE
Objet : Re: [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: I-DAction:draft-ietf-behave-dns64-01.txt]

actually, i guess it makes more sense for the NSP prefix than for the WK prefix, since synthetic RR containing addresses witht he WKP can be distinguished by the WKP, i guess

Regards, marcelo

[email-masked] escribió:
> De : Xuewei Wang [mailto:[email-masked]] Envoyé : vendredi 23 
> octobre 2009 10:12 À : BOUCADAIR Mohamed NCPI/NAD/TIP; Christian 
> Huitema; [email-masked]; [email-masked]; [email-masked] 
> Objet : [BEHAVE] draft-boucadair-behave-dns-a64-00.txt [was RE: 
> I-DAction:draft-ietf-behave-dns64-01.txt]
>
> Hi, mohamed,
> To: "Christian Huitema" <[email-masked]>; 
> <[email-masked]>; <[email-masked]>; <[email-masked]>
> IPv4-mapped IPv6 addresses. An updated version of the draft will be 
> submitted soon
>
> De : [email-masked] [mailto:[email-masked]] De la 
> part de Christian Huitema Envoyé : mercredi 21 octobre 2009 18:40 À : 
> [email-masked]; [email-masked]; [email-masked] Objet : 
> Re: [BEHAVE] I-D Action:draft-ietf-behave-dns64-01.txt
>
>

---

From: <[email-masked]>
Date: Sun, 25 Oct 2009 14:34:06 +0100

Hi Dan, all,

I'm aware about that mode. In fact it is also part of draft-boucadair spec. 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"?

Cheers,
Med 

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

> IPv4-mapped IPv6 addresses. An updated version of the draft will be 

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: "Dan Wing" <[email-masked]>
Date: Fri, 30 Oct 2009 10:09:27 -0700

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

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

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.

-d

> 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]
> 
> 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.
> 
> 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. 
> If you are not the intended addressee of this message, please 
> cancel it immediately and inform the sender.