Subject: [v6ops] New updates are available for draft-ietf-v6ops-nat64-experience

From: GangChen <[email-masked]>
Date: Tue, 9 Jul 2013 14:41:30 +0800

Wg,

We just finished the updates on draft-ietf-v6ops-nat64-experience. The
latest draft incorporates all the comments during the WGLC.
You may find the following changes to echo reviews on the
mailing list, including

1) Restructure the document for better readability
2) Share several testing results to better convey the experiences.
3) Improve the discussions on several aspects of NAT64-CGN & NAT64-FE
deployment, including networking location, redundancy, Geo-location,
Quality of Experience and MTU considerations.

It would be great if the draft could receive your further reviews/comments

Many thanks for your kind helps

Best Regards

Gang

---------- Forwarded message ----------
From: [email-masked]
Date: Mon, 08 Jul 2013 23:03:31 -0700
Subject: I-D Action: draft-ietf-v6ops-nat64-experience-02.txt
To: [email-masked]
Cc: [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-02.txt
	Pages           : 19
	Date            : 2013-07-08

Abstract:
   This document summarizes NAT64 function deployment scenarios and
   operational experience.  Both NAT64-CGN (NAT64 Carrier Grade NATs)
   and NAT64-FE (NAT64 server Front End) 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-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-experience-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Dan Wing <[email-masked]>
Date: Tue, 9 Jul 2013 10:04:47 -0700

> Quality of Experience and MTU considerations.

On geolocation of a shared IPv4 address, I would prefer a citation to rfc6967 (which analyzes several solutions) rather than the individual document draft-chen-behave-nat64-radius-extension (which details one specific solution).

-d

> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: GangChen <[email-masked]>
Date: Wed, 10 Jul 2013 15:38:24 +0800

2013/7/10, Dan Wing <[email-masked]>:
> On geolocation of a shared IPv4 address, I would prefer a citation to
> rfc6967 (which analyzes several solutions) rather than the individual
> document draft-chen-behave-nat64-radius-extension (which details one
> specific solution).

rfc6967 has already cited at the beginning of the section 5.2. rfc6967
didn't include the radius-based method, so the
draft-chen-behave-nat64-radius-extension is mentioned to provide a
link for the further descriptions of "We have investigated to deliver
NAT64 BIBs ...".  (BTW, the solution may be useful if geo-location
systems are already built on a Radius database). Since that is an
individual document, the draft is listed as a Informative Reference.

Your suggestion may intend to provide various possibilities for
operator's deployment. So I propose following changes. Please kindly
check.

OLD

   o  The NAT64-CGN equipments may not implement XFF.  Geo-location
      based on shared IPv4 address is rather inaccurate in that case.
      It's desirable to offer geo-location system more information, for
      example port number to retrieve the internal IPv6 address, which
      has meaning in global scale.  We have investigated to deliver
      NAT64 BIBs and Session Table Entrys (STEs) to a Radius
      server[I-D.chen-behave-nat64-radius-extension], since current geo-
      location systems rely on a Radius database to inspect location
      information, for example the information provided in [RFC5580].
      Those methods could convey original source address through same
      message bus.  Another approach is to ask NAT64-CGN providing
      application aware gateway to insert IPv6 source addresses.
      However, that may introduce complexity and performance
      degradation.

New

   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.

BRs

Gang