Subject: [BEHAVE] draft-korhonen-behave-nat64-learn-analysis-00

From: Rémi Després <[email-masked]>
Date: Mon, 18 Oct 2010 14:29:03 +0200

Hi, Jouni and Teemu,

1.
As previously discussed on this list, this draft is IMHO important.
I hope it can quickly be discussed and become a WG document.

2. 
In the list of CONs of section 4.1.2, it has "Requires a host resolver changes and a mechanism/additions to the host resolver API (or flags, hints etc) to deliver a note to the querying application that the address is synthesized and what is the NSP prefix length."

An alternative, that IMHO should be considered, is that the resolver API directly presents an IPv4 address to the application. Thus, in my understanding, dual-stack-compatible applications wouldn't need to be modified.

Regards, 
RD

---

From: xuxiaohu 41208 <[email-masked]>
Date: Mon, 18 Oct 2010 18:58:03 +0100

Hi,

Are the recommended solutions tightly coupled with DNS64?

Xiaohu 

----- 原邮件 -----
发件人: Rémi Després <[email-masked]>
日期: 星期一, 十月 18日, 2010 下午1:29
主题: [BEHAVE] draft-korhonen-behave-nat64-learn-analysis-00
收件人: jouni korhonen <[email-masked]>, Teemu Savolainen <[email-masked]>
抄送: Behave WG <[email-masked]>

> In the list of CONs of section 4.1.2, it has "Requires a host 
> resolver changes and a mechanism/additions to the host resolver 
> API (or flags, hints etc) to deliver a note to the querying 
> application that the address is synthesized and what is the NSP 
> prefix length."
> 
> An alternative, that IMHO should be considered, is that the 
> resolver API directly presents an IPv4 address to the application. 
> Thus, in my understanding, dual-stack-compatible applications 
> wouldn't need to be modified.
> 
> Regards, 
> RD  
> 
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Oct 2010 14:16:27 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rémi Després
> Sent: Monday, October 18, 2010 5:29 AM
> To: jouni korhonen; Teemu Savolainen
> Cc: Behave WG
> Subject: [BEHAVE] draft-korhonen-behave-nat64-learn-analysis-00
> 
> Hi, Jouni and Teemu,
> 
> 1.
> In the list of CONs of section 4.1.2, it has "Requires a host resolver
> changes and a mechanism/additions to the host resolver API (or flags,
> hints etc) to deliver a note to the querying application that the
> address is synthesized and what is the NSP prefix length."
> 
> An alternative, that IMHO should be considered, is that the resolver
> API directly presents an IPv4 address to the application. Thus, in my
> understanding, dual-stack-compatible applications wouldn't need to be
> modified.

You mean, presents an IPv4-mapped IPv6 address to the application 
(::ffff:1.1.1.1)?

-d

---

From: <[email-masked]>
Date: Tue, 19 Oct 2010 08:09:08 +0200

I would prefer giving the synthetic IPv6 addresses to applications as received from the network, but possibly prioritize those lower than native IPv4 (see ongoing RFC3484 revisit work). This also will ensure unmodified applications avoid NAT64 in dual-stack access.

Best regards,

Teemu

> From: ext Dan Wing [mailto:[email-masked]]
> Sent: 19. lokakuuta 2010 00:16
> To: 'Rémi Després'; 'jouni korhonen'; Savolainen Teemu (Nokia-
> MS/Tampere)
> Cc: 'Behave WG'
> Subject: RE: [BEHAVE] draft-korhonen-behave-nat64-learn-analysis-00
> 
> 
> 
> resolver

---

From: <[email-masked]>
Date: Tue, 19 Oct 2010 08:40:43 +0200

Hi Xiaohu,

DNS-based solutions apply only when the outgoing communication involves the DNS. If DNS is not involved, an IPv6 host may not be able to select the appropriate IPv6 address and therefore NAT64 function can be used to reach a dual stack host. This can be critical in scenarios where NAT64 traversal is required.  As an example, referral can enclose indication about the source of the address and its scope (e.g., http://tools.ietf.org/html/draft-carpenter-behave-referral-object-01). Such indication would let a remote peer select among a set of candidate IPv6 addresses and avoid useless invocation of NAT64. 

I already raised this point to Jouni:

* I agree with the edns0 recommendation. Edns0 is superior to my own A64 proposal. I thought an enhancement might be needed for the edns0 to allow using IPv4-Converted IPv6 address in authoritative servers. But it seems this is not in scope of the scenarios covered in this I-D. 
 
* I don't think recommending only DNS-based solution are sufficient and that complementary solutions such as the referral object/DHCPv6 option may be considered.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de xuxiaohu 41208
Envoyé : lundi 18 octobre 2010 19:58
À : Rémi Després
Cc : jouni korhonen; Behave WG
Objet : [BEHAVE] 回复 : draft-korhonen-behave-nat64-learn-analysis-00

Hi,

Xiaohu 

----- 原邮件 -----
发件人: Rémi Després <[email-masked]>
日期: 星期一, 十月 18日, 2010 下午1:29
主题: [BEHAVE] draft-korhonen-behave-nat64-learn-analysis-00
收件人: jouni korhonen <[email-masked]>, Teemu Savolainen <[email-masked]>
抄送: Behave WG <[email-masked]>

*********************************
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: Rémi Després <[email-masked]>
Date: Tue, 19 Oct 2010 08:59:47 +0200

> You mean, presents an IPv4-mapped IPv6 address to the application 

No.
The de-synthesized IPv4 address 1.1.1.1.

RD

---

From: jouni korhonen <[email-masked]>
Date: Tue, 19 Oct 2010 10:41:23 +0300

Hi,

> The de-synthesized IPv4 address 1.1.1.1.

That you can do already today.

- Jouni

---

From: Rémi Després <[email-masked]>
Date: Tue, 19 Oct 2010 10:36:20 +0200

Le 19 oct. 2010 à 09:41, jouni korhonen a écrit :
>>>> ...

Yes.

That's why any solution that tells the resolver which IPv6 addresses are synthesized from IPv4 addresses doesn't, per se, require resolvers to have "a mechanism/additions to the host resolver API (or flags, hints etc) to deliver a note to the querying application that the address is synthesized."

My point was about such a "requirement" being listed as a CON the solution of 4.1 (and also that of 4.4).

If the resolver just returns IPv4 addresses to applications, all IPv4-capable applications will work without any change.
A change of the application API is NOT required for this.

Of course, this doesn't permit IPv6-only client applications to reach IPv4-only server applications, but client applications should rather be dual-stack if they may need to talk to IPv4-only server applications.

RD

---

From: xuxiaohu 41208 <[email-masked]>
Date: Tue, 19 Oct 2010 11:51:36 +0100

> * I don't think recommending only DNS-based solution are 
> sufficient and that complementary solutions such as the referral 
> object/DHCPv6 option may be considered.

Agree.

Best wishes,
Xiaohu
 
> ? : Rémi Després
> 收件人: jouni korhonen <[email-masked]>, Teemu Savolainen 
> <[email-masked]>抄送: Behave WG <[email-masked]>
> 
> > Hi, Jouni and Teemu,
> > 
> > 1.
> If you are not the intended addressee of this message, please 
> cancel it immediately and inform the sender.