Subject: [BEHAVE] tsv-dir review of draft-ietf-behave-nat64-learn-analysis-01

From: Songhaibin <[email-masked]>
Date: Sun, 06 Nov 2011 02:17:47 +0000

Hello,

I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC [email-masked] if you reply to or forward this review.

SUMMARY

This draft is basically ready for publication, but has nits that should be fixed before publication.

One comment:

In section 5 (Conclusion), it compares DHCP/RA like solutions to DNS like solutions, and gives the recommendation of using DNS method, but without comparing that with STUN like methods. Is it possible to add it or people think there is obvious reason (DNS is better than STUN)? 

Another minor comment:

In section 4.6.1 , [I-D.boucadair-dhcpv6-shared-address-option] also support NAT64 prefix allocation for building IPv4-embedded IPv6 address using DHCPv6 option. And this should be mentioned in the document.

BR,
-Haibin

---

From: jouni korhonen <[email-masked]>
Date: Tue, 8 Nov 2011 11:51:58 +0200

Hi Haibin,

Thank you for the review. See my comments inline.

> In section 5 (Conclusion), it compares DHCP/RA like solutions to DNS like solutions, and gives the recommendation of using DNS method, but without comparing that with STUN like methods. Is it possi…

Good point. We should add some text along lines: "a host does not need to implement STUN where as DNS is in practice required anyway. Also, STUN protocol would be needed to changed on both host and network side to support the discovery of NAT64".

Would that work for you?

> In section 4.6.1 , [I-D.boucadair-dhcpv6-shared-address-option] also support NAT64 prefix allocation for building IPv4-embedded IPv6 address using DHCPv6 option. And this should be mentioned in the…

Ok. Will add this.

Thanks,
	Jouni

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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 08 Nov 2011 09:11:02 -0500

jouni korhonen wrote, on 11/08/2011 04:51 AM:
> Also, STUN
> protocol would be needed to changed on both host and network side to support
> the discovery of NAT64

Would it? Please explain why.

If you send a STUN request using IPv6 transport and get a reply containing an
IPv4 mapped address, you can be pretty sure that you're behind some kind of NAT64...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Simon Perreault <[email-masked]>
Date: Tue, 08 Nov 2011 13:25:30 -0500

jouni korhonen wrote, on 11/08/2011 12:09 PM:
> Because of the text few WG participants wanted us to included into the analysis when using STUN for NAT64 discovery. That resulted to the text below, which very much implies protocol work to me:
> 
>  After learning the IPv6 address of a STUN server the STUN client
>  sends a request to the STUN server containing new 'SENDING-TO'
>  attribute that tells to the server the IPv6 address the client sent
>  the request to.  In a reply the server includes another new attribute
>  called 'RECEIVED-AS', which contains server's IP address the request
>  arrived on.  After receiving the reply the client compares
>  'SENDING-TO' and 'RECEIVED-AS' attributes to find out an NSP
>  candidate.

Can you point me to the rationale for these additional parameters?

Thanks,
Simon

---

From: jouni korhonen <[email-masked]>
Date: Tue, 8 Nov 2011 21:07:27 +0200

> Can you point me to the rationale for these additional parameters?

Ask Dan, Christian, Teemu and Med.

- Jouni

---

From: jouni korhonen <[email-masked]>
Date: Tue, 8 Nov 2011 19:09:09 +0200

Simon,

- JOuni

---

From: Songhaibin <[email-masked]>
Date: Fri, 11 Nov 2011 01:18:51 +0000

Hi Jouni,

> -----Original Message-----
> From: jouni korhonen [mailto:[email-masked]]
> Sent: Tuesday, November 08, 2011 5:52 PM
> To: Songhaibin
> Cc: [email-masked]; Behave WG;
> [email-masked]; TSV Dir
> Subject: Re: [BEHAVE] tsv-dir review of draft-ietf-behave-nat64-learn-analysis-01
> 
> Hi Haibin,
> 
> > I've reviewed this document as part of the transport area directorate's ongoing
> effort to review key IETF documents. These comments were written primarily for
> the transport area directors, but are copied to the document's authors for their
> information and to allow them to address any issues raised. The authors should
> consider this review together with any other last-call comments they receive.
> Please always CC [email-masked] if you reply to or forward this review.
> >
> > SUMMARY
> >
> > In section 5 (Conclusion), it compares DHCP/RA like solutions to DNS like
> solutions, and gives the recommendation of using DNS method, but without
> comparing that with STUN like methods. Is it possible to add it or people think
> there is obvious reason (DNS is better than STUN)?
> 
> Good point. We should add some text along lines: "a host does not need to
> implement STUN where as DNS is in practice required anyway. Also, STUN
> the discovery of NAT64".

The text looks good to me.

> 
> >
> > Another minor comment:
> >
> > In section 4.6.1 , [I-D.boucadair-dhcpv6-shared-address-option] also support
> NAT64 prefix allocation for building IPv4-embedded IPv6 address using DHCPv6
> option. And this should be mentioned in the document.
> 
> Ok. Will add this.
> 

Then I am okay with this draft.

Thanks,
-Haibin