Subject: [v6ops] new version is available: draft-ietf-v6ops-nat64-experience-03.txt

From: GangChen <[email-masked]>
Date: Wed, 2 Oct 2013 10:35:44 +0800

Wg,

We have just submitted the new version to address the comments during the WGLC.
The main changes are
1) Add the ULAs statement to feedback Lorenzo's comments
2) Add the description of bulk port allocation in Section 5.1
suggested by Mikael
3) Add the experience description for geo-location service in Section
5.2 according to Dan Wing and Mikael comments
4) Add sub-levels in Section 3.1 and improve the description in
section 3.1.2 to echo Sheng's comments
5) Polish the entire draft according to the suggestions from
IETF#87“Document Language Editing Session”

Please kindly check if all comments are addressed in this version.

Many thanks

Gang

2013/10/2, [email-masked] <[email-masked]>:
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the IPv6 Operations Working Group of the
> IETF.
>
> 	Title           : NAT64 Operational Experiences
> 	Author(s)       : Gang Chen
>                           Zhen Cao
>                           Chongfeng Xie
>                           David Binet
> 	Filename        : draft-ietf-v6ops-nat64-experience-03.txt
> 	Pages           : 20
> 	Date            : 2013-10-01
>
> Abstract:
>    This document summarizes NAT64 function deployment scenarios and
>    operational experience.  Both NAT64 Carrier Grade NAT (NAT64-CGN) and
>    NAT64 server Front End (NAT64-FE) are considered in this document.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-experience
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-v6ops-nat64-experience-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-experience-03
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 8 Oct 2013 03:51:52 +0000

Hi, all

I support this new version. The ULA statement is valuable guide to the real deployment.

B.R.
Bing

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of GangChen
> Sent: Wednesday, October 02, 2013 10:36 AM
> To: v6ops
> Subject: [v6ops] new version is available:
> draft-ietf-v6ops-nat64-experience-03.txt
> 
> Wg,
> 
> IETF#87"Document Language Editing Session"
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 8 Oct 2013 18:06:20 +0900

Comments on the ULA section only:

1. Please do not cite RFC 3484 anywhere. It is obsolete and thus
irrelevant; hosts that implement it are not compliant with current IETF
standards. Instead, say that compliant host implementations will never
prefer ULA over IPv4. The logical conclusion is to say that ULA addresses
are not recommended for use on a NAT64-CGN, because they will never be used.

2. Don't cite RFC 6555, it has nothing to do with issuing both A and AAAA
DNS requests. Issuing both an AAAA lookup and an A lookup is standard for
RFC 6724 implementations that have both IPv4 and IPv6 addresses.

---

From: GangChen <[email-masked]>
Date: Tue, 8 Oct 2013 18:04:46 +0800

Hello Lorenzo,

Many thanks for the message.
I make following changes to incorporate your comments
Please kindly check.

==OLD===
   When the host has both IPv4 and IPv6 address, it would initiate both
   A and AAAA record lookup may due to Happy Eyeballs [RFC6555], then
   both original A record and DNS64-generated AAAA record would be
   received.  The host would prefer the AAAA record as the destination,
   if the address selection process still follows the recommendation of
   [RFC3484].  While, if the host implements the default policy table as
   defined in [RFC6724], since the IPv4 takes the precedence over ULA
   (which is difference than [RFC3484]), an IPv4 path will be always
   preferred.  It may be undesirable because the traffic path is
   unexpected due to vary implementations on hosts.  Operators have to
   make site-specific rules to gauge the host's behaviors, which may
   likely add the operational complexity.

==New==
    When the host has both IPv4 and IPv6 address, it
    would initiate both A and AAAA record lookup, then
    both original A record and DNS64-generated AAAA record would be
    received.  A host, which is compliant with [RFC6724], will never
    prefer ULA over IPv4. An IPv4 path will be always
    selected. It may be undesirable because the NAT64-CGN will never be
    used. Operators may consider to add additional site-specific rows
    to the default table to steer traffic flows going through NAT64-CGN.
    However, it involves significant costs to change terminal's  behavior.
    Therefore, operators are not suggested to configure ULAs on a NAT64-CGN.

BRs

Gang

2013/10/8, Lorenzo Colitti <[email-masked]>:
>> > We have just submitted the new version to address the comments during
>> > the
>> > WGLC.
>> > The main changes are

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 8 Oct 2013 10:06:41 +0000

> The logical conclusion is to say that ULA addresses are not recommended for use on a NAT64-CGN, because they will never be used.

[Bing]IMHO, it goes too far to say "ULA addresses are not recommended for use on a NAT64-CGN". If the admins deploy site-specific addr-select policy tables, it is OK to use ULA. I think it is enough to just make a caution for the authors that ULA prefix would be invalid under default policy.

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, October 08, 2013 5:06 PM
To: Liubing (Leo)
Cc: GangChen; v6ops
Subject: Re: [v6ops] new version is available: draft-ietf-v6ops-nat64-experience-03.txt

1. Please do not cite RFC 3484 anywhere. It is obsolete and thus irrelevant; hosts that implement it are not compliant with current IETF standards. Instead, say that compliant host implementations will never prefer ULA over IPv4. The logical conclusion is to say that ULA addresses are not recommended for use on a NAT64-CGN, because they will never be used.

2. Don't cite RFC 6555, it has nothing to do with issuing both A and AAAA DNS requests. Issuing both an AAAA lookup and an A lookup is standard for RFC 6724 implementations that have both IPv4 and IPv6 addresses.

On Tue, Oct 8, 2013 at 12:51 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
Hi, all

B.R.
Bing

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of GangChen
> 2013/10/2, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>:
> >
> > until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
> >
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 8 Oct 2013 19:23:03 +0900

On Tue, Oct 8, 2013 at 7:06 PM, Liubing (Leo) <[email-masked]>wrote:

>  > The logical conclusion is to say that ULA addresses are not
> recommended for use on a NAT64-CGN, because they will never be used.****
>
> ** **
>
> [Bing]IMHO, it goes too far to say “ULA addresses are not recommended for
> use on a NAT64-CGN”. If the admins deploy site-specific addr-select policy
> tables, it is OK to use ULA. I think it is enough to just make a caution
> for the authors that ULA prefix would be invalid under default policy.
>

But for that to work, the operator needs to control both the CGN and all
the devices, right? Then say it's not recommended unless the operator
controls both the CGN and all the devices.

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 9 Oct 2013 01:56:32 +0000

>IETF#87“Document Language Editing Session”

Thanks for address my comments. I support this document to go forward.

Regards,

Sheng