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

You response looks proper for me.

Sheng

>-----Original Message-----
>From: GangChen [mailto:phdgang@gmail.com]
>Sent: Wednesday, September 04, 2013 4:03 PM
>To: Sheng Jiang
>Cc: Fred Baker; v6ops@ietf.org
>Subject: Re: [v6ops] draft-ietf-v6ops-nat64-experience WGLC
>
>Hi Sheng,
>
>Thank you for your detailed review. Please see my reply inline.
>
>2013/9/3, Sheng Jiang <jiangsheng@huawei.com>:
>> 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.
>
>We will address that at the next update.
>
>> 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.
>
>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.
>
>
>> 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 ?
>
>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
>
>> Best regards，
>>
>> Sheng
>>
>>>-----Original Message-----
>>>From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf
>>>Of Fred Baker
>>>Sent: Monday, September 02, 2013 2:00 AM
>>>To: v6ops@ietf.org
>>>Subject: [v6ops] draft-ietf-v6ops-nat64-experience WGLC
>>>
>>>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.
>>>_______________________________________________
>>>v6ops mailing list
>>>v6ops@ietf.org
>>>https://www.ietf.org/mailman/listinfo/v6ops
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>