Subject: [v6ops] draft-ietf-v6ops-nat64-experience WGLC

From: Fred Baker <[email-masked]>
Date: Sun, 1 Sep 2013 11:00:10 -0700 (PDT)

This is to initiate a two week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience.  Please read it now. If you find nits
(spelling errors, minor suggested wording changes, etc), comment to the
authors; if you find greater issues, such as disagreeing with a
statement or finding additional issues that need to be addressed,
please post your comments to the list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 3 Sep 2013 07:34:44 +0000

Hi, v6ops and authors,

I volunteered to review this document during IETF87 meeting. The below is my comments.

In general, this document have done a good job on sharing their NAT64 experience. The information is useful for IPv6 society and the document has organized in a form easy to read and understand.

So I support this WGLC.

Some nits are as following. 

The second and fourth paragraphs are both describe the coexistence between IPv4 and IPv6. Merging them together would get better logicality.

Section 3.1 contains fairly long statements. It may be better to create sub-sections to gauge the discussion.

For the statement,
   
   Therefore, NAT64 may serve double roles in some cases,
   i.e. a translator and IPv6 forwarder.  Some failure cases may occur
   once NAT64 serves a IPv6 gateway but is configured only with IPv4 on

It should be noted native IPv6 paths may not traverse NAT64. You may add some discussions regarding this point.

Section 4.1 has done a good discussion on the different flavors of redundancy. It would be better to move the testing table into the appendix. You could detail the testing condition so audiences could compare it with their-own situation.

In section 4.2, you have the below text

      With the absence of DNS64, internal
      hosts could learn multiple IPv6 prefixes through the approaches
      defined in[I-D.ietf-behave-nat64-discovery-heuristic]...

However, I-D.ietf-behave-nat64-discovery-heuristic also requests DNS64 involvement. It may need some clarifications ?  

In section 5.2, it may be worth to add a quota or reference to rfc6967. It analyzes several potential solutions in geo-location area. 

Best regards，

Sheng

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Fred Baker
>Sent: Monday, September 02, 2013 2:00 AM
>To: [email-masked]
>Subject: [v6ops] draft-ietf-v6ops-nat64-experience WGLC
>
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

---

From: GangChen <[email-masked]>
Date: Wed, 4 Sep 2013 16:02:56 +0800

Hi Sheng,

Thank you for your detailed review. Please see my reply inline.

2013/9/3, Sheng Jiang <[email-masked]>:
> In general, this document have done a good job on sharing their NAT64
> experience. The information is useful for IPv6 society and the document has
> organized in a form easy to read and understand.
>
> So I support this WGLC.
>
> The second and fourth paragraphs are both describe the coexistence between
> IPv4 and IPv6. Merging them together would get better logicality.
>

We will address that at the next update.

> some discussions regarding this point.

I would make following changes on this point

OLD
---------------
   Operators should not expect to access IPv4 parts
   of a dual-stack server using NAT64/DNS64.  NAT64 would forwards all
   the traffic on IPv6 paths if dual-stack servers are targeted.  In
   some sense, it encourages IPv6 transmission and restrains NAT uses
   compared to NAT44(if used), on which all traffic flows have to
   traverse.  Therefore, NAT64 may serve double roles in some cases,
   i.e. a translator and IPv6 forwarder.  Some failure cases may occur
   once NAT64 serves a IPv6 gateway but is configured only with IPv4 on
   WAN links.  We tested on Top100 websites (referring to [Alexa]
   statistics) in such condition. 43% of websites are failed to be
   connected since those websites have both AAAA and A records.  To be
   reliable, it's recommended to enable NAT64 WAN links with dual-stack
   connections in the deployment.

NEW
-----------------
   Operators should not expect to access IPv4 parts
   of a dual-stack server using NAT64/DNS64. The traffic is forwarded
   on IPv6 paths if dual-stack servers are targeted. IPv6 traffic may be routed
   not going through NAT64. Only the traffic going to IPv4-only service
   would traverse NAT64. In some sense, it encourages IPv6 transmission
   and restrains NAT uses compared to NAT44(if used), on which all traffic
   flows have to be traversed and translated. In some cases, NAT64-CGN may
   serve double roles, i.e. a translator and IPv6 forwarder. Some failure
   cases may be occured once NAT64 serves a IPv6 gateway while is configured
   only with IPv4 on WAN links.  We tested on Top100 websites
(referring to [Alexa]
   statistics) in such condition. 43% of websites are failed to be
   connected since those websites have both AAAA and A records. Therefore, it's
   recommended to enable NAT64 WAN links with dual-stack connections
in such case.

> Section 4.1 has done a good discussion on the different flavors of
> redundancy. It would be better to move the testing table into the appendix.
> You could detail the testing condition so audiences could compare it with
> their-own situation.

It will be done at the next update.

> However, I-D.ietf-behave-nat64-discovery-heuristic also requests DNS64
> involvement. It may need some clarifications ?

Thank you for pointing me this issue. I would make following change

      For the applications not requiring DNS resolver, internal
      hosts could learn multiple IPv6 prefixes through the approaches
      defined in[I-D.ietf-behave-nat64-discovery-heuristic] and then
      select one based on a given prefix selection policy.

> In section 5.2, it may be worth to add a quota or reference to rfc6967. It
> analyzes several potential solutions in geo-location area.

It was mentioned at
http://www.ietf.org/mail-archive/web/v6ops/current/msg17131.html.
The new text for the statement is

   o  The NAT64-CGN equipments may not implement XFF.  Geo-location
      based on shared IPv4 address is rather inaccurate in that case.
      [RFC6967] analyzed several options to reveal the host identifier.
      Each one may have their-own specific usage. With regards to
      NAT64 deployment, it's desirable to offer geo-location system
      the internal IPv6 address, which has the meaning in global scale.
      For the geo-location systems relying on a Radius database[RFC5580], we
      have investigated to deliver NAT64 BIBs and Session Table Entrys (STEs)
      to a Radius server[I-D.chen-behave-nat64-radius-extension].
      This method could get along with [RFC5580] to convey original source
      address through same message bus.

Best Regards

Gang

>>http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience.  Please read
>> it
>>now. If you find nits

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 4 Sep 2013 10:00:15 +0000

You response looks proper for me.

Sheng

>From: GangChen [mailto:[email-masked]]
>Sent: Wednesday, September 04, 2013 4:03 PM
>To: Sheng Jiang
>Cc: Fred Baker; [email-masked]
>Subject: Re: [v6ops] draft-ietf-v6ops-nat64-experience WGLC
>
>Hi Sheng,
>
>> I volunteered to review this document during IETF87 meeting. The below is
>my
>> comments.
>>