Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-nat64-experience-00.txt

From: Rémi Després <[email-masked]>
Date: Fri, 9 Mar 2012 16:30:52 +0100

Gang, 

1.
This kind of draft is IMHO useful because it discusses the global picture.
Maybe calling it NAT64 operational "issues" or "scenarios", would better describe its contents than just "experiences" which, IMHO suggests a report on already observed behaviors.

2.
One point of substance: sec. 3.6 says "One approach avoiding this issue is to configure IPv4 MTU>=1260, which would forbid the occurence of PTB<1280". It should be possible for the IPv6 Internet to IPv4 network scenario of sec. 3,  but not for the IPv6 network to IPv4 Internet scenario of sec 2. This should IMHO be clarified.  

3. 
Couldn' understand this sentence of sec. 1:
"Since the scenario of "The IPv6 Internet to the IPv4 Internet" seems the ideal case for in-network translation technology, this document has focused on the three cases and categorized different NAT64 usages as NAT64-CGN and NAT64-CE."

4.
Minor noted typos:
- 3.3
"might a good choice" => "might be a good choice"
- 3.1
"is to distributed" => "is to distribute"
- 3.5 
" a synthetic AAAA records" => "a synthetic AAAA record"
- 3.6 
"occurence" => "occurrence"

5.
For a further version, I would suggest to include more referenced documents (in particular about Lawful traceability, IAP, ALGs other than FTP, SYN Proxy-cookie). 

Regards,
RD

Le 2012-02-14 à 05:11, GangChen a écrit :

> Hello all,
> 
> We have published draft-chen-v6ops-nat64-experience-00, which
> described NAT64 operational expriences and updated with all the
> information from the presentation of draft-chen-v6ops-nat64-cpe at
> last meeting. Considering the new changes, authors would like to
> retire the old draft (i.e. draft-chen-v6ops-nat64-cpe) and continue
> the discussion on nat64 experiences.
> 
> All comments are welcome.
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
>      Title           : NAT64 Operational Experiences
>      Author(s)       : Gang Chen
>                              Zhen Cao
>                              Cameron Byrne
>                              QiBo Niu
>      Filename        : draft-chen-v6ops-nat64-experience-00.txt
>      Pages           : 11
>      Date            : 2012-02-13
> 
> This document summarizes some stateful NAT64 deployment scenarios and
> operational experiences for NAT64-CGN and NAT64-CE.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-00.txt
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: GangChen <[email-masked]>
Date: Sat, 10 Mar 2012 18:17:53 +0800

Hello Remi,

> This kind of draft is IMHO useful because it discusses the global picture.

Thanks for the supports.

> Maybe calling it NAT64 operational "issues" or "scenarios", would better
> describe its contents than just "experiences" which, IMHO suggests a report
> on already observed behaviors.

Your interpretation is correct. The word of "experiences" came from
last meeting discussions. People expected the draft provides NAT64
operational views and document experiences. It would like to draft
what we have observed more than what we recommended to let IETF do
some protocol enhancements.  Therefore, I guess "experiences" is good
to express the intention.

> 2.
> One point of substance: sec. 3.6 says "One approach avoiding this issue is
> to configure IPv4 MTU>=1260, which would forbid the occurence of PTB<1280".
> It should be possible for the IPv6 Internet to IPv4 network scenario of sec.
> 3,  but not for the IPv6 network to IPv4 Internet scenario of sec 2. This
> should IMHO be clarified.

Agree. It should be clarified. I will do in next version.

> "Since the scenario of "The IPv6 Internet to the IPv4 Internet" seems the
> ideal case for in-network translation technology, this document has focused
> on the three cases and categorized different NAT64 usages as NAT64-CGN and
> NAT64-CE."

Considering potential audiences, who want to get the information for
their possible deployment of NAT64 in near future, we are focusing
three common cases of NAT64.  "The IPv6 Internet to the IPv4 Internet"
may be too early to state some experiences.

> "occurence" => "occurrence"

Many thanks. I would fix that in next version.

> 5.
> For a further version, I would suggest to include more referenced documents
> (in particular about Lawful traceability, IAP, ALGs other than FTP, SYN
> Proxy-cookie).

Will do in next version.

BRs

Gang

---

From: GangChen <[email-masked]>
Date: Tue, 13 Mar 2012 10:59:08 +0800

Hello all,

Replying the comments received on the list, we updated the draft and
published -01 for NAT64 experiences. Please check the side-by-side
diff as below

http://tools.ietf.org/rfcdiff?url1=draft-chen-v6ops-nat64-experience-00&difftype=--html&submit=Go%21&url2=draft-chen-v6ops-nat64-experience-01

Your further comments are appreciated

       Title           : NAT64 Operational Experiences
       Author(s)       : Gang Chen
                         Zhen Cao
                         Cameron Byrne
                         QiBo Niu
       Filename        : draft-chen-v6ops-nat64-experience-01.txt
       Pages           : 11
       Date            : 2012-03-12

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-01.txt

BRs

Gang

---

From: "George, Wes" <[email-masked]>
Date: Sat, 24 Mar 2012 08:58:21 -0400

Some additional comments on this new version

Section 2.3 - This only briefly mentions logging translation events and offline traceability. The amount of logging data generated by other NAT implementations such as NAT444 is potentially onerous. It would be helpful to discuss whether this shares a similar concern, and characterize the amount of logging generated in typical usage by comparison, whether optimizations are possible similar to draft-donley-behave-deterministic-cgn to reduce the logging, etc.

Also in this same section, I disagree with the statements " Lawful intercept[RFC3924] is normally part of the access network, in
   which an optical splitter is used to bypass all traffic for
   subsequent filtering process." And "even if that
   may not a major case in current practices"

Optical split is actually a fairly uncommon method to do LI in most broadband access networks, and is also not really the method defined in 3924. I don't think that the second half of this phrase (the part talking about optical splits and whether LI of one sort or another is common) is actually adding much to the discussion, and it should probably just be removed. That said, you assert that LI is easily added, and I think that it would be better to expand on that, either with a reference to where this is discussed in detail elsewhere, or additional text to explain how.

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> GangChen
> Sent: Monday, March 12, 2012 10:59 PM
> To: [email-masked]
> Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-nat64-experience-00.txt
>
> Hello all,
>
> http://tools.ietf.org/rfcdiff?url1=draft-chen-v6ops-nat64-experience-
> 00&difftype=--html&submit=Go%21&url2=draft-chen-v6ops-nat64-experience-01
>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: GangChen <[email-masked]>
Date: Sun, 25 Mar 2012 06:37:41 +0800

Hello George,

Thanks for the comments.
Reply is in line.

2012/3/24, George, Wes <[email-masked]>:
> Section 2.3 - This only briefly mentions logging translation events and
> offline traceability. The amount of logging data generated by other NAT
> implementations such as NAT444 is potentially onerous. It would be helpful
> to discuss whether this shares a similar concern, and characterize the
> amount of logging generated in typical usage by comparison, whether
> optimizations are possible similar to draft-donley-behave-deterministic-cgn
> to reduce the logging, etc.

Good suggestions. That are useful arguments to strengthen the
discussion. We would add texts on the tradeoff between address
multiplexing efficiency & logging storage compression in next version.

> Also in this same section, I disagree with the statements " Lawful
> intercept[RFC3924] is normally part of the access network, in
> Optical split is actually a fairly uncommon method to do LI in most
> broadband access networks,

I guess that is a vendor-specific situation

>and is also not really the method defined in 3924.

Yes. rfc3924 is focusing on LI framework. Not implementation-specific

>  I don't think that the second half of this phrase (the part talking
> about optical splits and whether LI of one sort or another is common) is
> actually adding much to the discussion, and it should probably just be
> removed. That said, you assert that LI is easily added, and I think that it
> would be better to expand on that, either with a reference to where this is
> discussed in detail elsewhere, or additional text to explain how.

Acknowledged. I guess the statement should be modified from
generalized views other than deriving from a particular implementation
case. I would prefer to update texts to compliant with
draft-ietf-behave-lsn-requirements

BRs

Gang

> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely for
> the use of the individual or entity to which it is addressed. If you are not
> the intended recipient of this E-mail, you are hereby notified that any
> dissemination, distribution, copying, or action taken in relation to the
> contents of and attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify the
> sender immediately and permanently delete the original and any copy of this
> E-mail and any printout.
>