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

[GangChen <[e-mail]>]

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 <[e-mail]>:
> 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.
>
>
> On Tue, Oct 8, 2013 at 12:51 PM, Liubing (Leo)
> <[e-mail]>wrote:
>
>> Hi, all
>>
>> I support this new version. The ULA statement is valuable guide to the
>> real deployment.
>>
>> B.R.
>> Bing
>>
>> > -----Original Message-----
>> > From: [e-mail] [mailto:[e-mail]] 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,
>> >
>> > 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, [e-mail] <[e-mail]>:
>> > >
>> > > 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
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/v6ops
>> > >
>> > _______________________________________________
>> > v6ops mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/v6ops
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>