Subject: [v6ops] Fw: New Version Notification for draft-sun-v6ops-xlat-multi-00.txt

From: Qiong <[email-masked]>
Date: Tue, 8 Jul 2014 09:57:36 +0800

Hi All,

We submitted a new draft about deploying multiple PLATs in 464XLAT. Your
comments are more than welcome. Thanks a lot!

Best wishes
Qiong

 *From:* internet-drafts <[email-masked]>
*Date:* 2014-07-04 21:31
*To:* Qiong Sun <[email-masked]>; Qiong Sun
<[email-masked]>; Zhirong
Zhang <[email-masked]>; Qin Zhao <[email-masked]>; Qin Zhao
<[email-masked]>; Zhirong Zhang <[email-masked]>
*Subject:* New Version Notification for draft-sun-v6ops-xlat-multi-00.txt

A new version of I-D, draft-sun-v6ops-xlat-multi-00.txt
has been successfully submitted by Qiong Sun and posted to the
IETF repository.

Name: draft-sun-v6ops-xlat-multi
Revision: 00
Title: Running Multiple PLATs in 464XLAT
Document date: 2014-07-04
Group: Individual Submission
Pages: 8
URL:
http://www.ietf.org/internet-drafts/draft-sun-v6ops-xlat-multi-00.txt
Status:         https://datatracker.ietf.org/doc/draft-sun-v6ops-xlat-multi/
Htmlized:       http://tools.ietf.org/html/draft-sun-v6ops-xlat-multi-00

Abstract:
   The IPv6 transition has been an ongoing process throughout the world
   due to the exhaustion of the IPv4 address space.  The
   464XLAT[RFC6877] provides a solution with limited IPv4 connectivity
   across an IPv6-only network, and the android system (version 2.3 and
   above) has already implemented the 464XLAT[RFC6877] and the the
   Prefix discovery solution [RFC7050].  However, the current 464XLAT
   architecture can only deal with the scenario with single PLAT in the
   network.  When operator deploys multiple PLATs with different Pref64
   prefixes, 464XLAT cannot cope with multiple prefixes for different
   destination addresses.

   This document describes the architecture with multiple PLATs and also
   the deployment considerations.

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.

The IETF Secretariat

---

From: Dan Wing <[email-masked]>
Date: Sun, 20 Jul 2014 13:36:09 -0700

On Jul 7, 2014, at 6:57 PM, Qiong <[email-masked]> wrote:

> Hi All,
> 
> We submitted a new draft about deploying multiple PLATs in 464XLAT. Your comments are more than welcome. Thanks a lot!

draft-sun-v6ops-xlat-multi says that networks like this exist:

                      PLAT "A" ----- IPv4-only servers in a data center
                     /
   IPv6-only node---<
                     \
                      PLAT "B" ----- IPv4 Internet

but I wonder why there are IPv4-only servers in a data center.  I see two operational approaches, which do not require changing 464XLAT.

1. I bet those IPv4-only servers exist because there are IPv4-only nodes (subscribers) on the same network, which similarly also need to access both the IPv4-only servers in the datacenter and also the IPv4 Internet.  Those IPv4-only subscribers might (or might not) be going through a NAT; it doesn't matter.

                       [maybe NAT44] ----- IPv4-only servers in a data center
                     /
   IPv4-only node---<
                     \
                       [maybe NAT44] ----- IPv4 Internet

                       PLAT "A" ----- IPv4-only servers in a data center
                     /
   IPv6-only node---<
                     \
                      PLAT "B" ----- IPv4 Internet

Of course, those IPv4-only nodes aren't doing anything special; that is, they don't know how the routing occurs to cause some of their traffic to go towards the data center and the rest of their traffic towards the Internet.

I do not believe 464xlat needs the IPv6-only 464xlat host to be aware of which NAT64 is handling its traffic.  Instead, the network operator can route the specific IPv6 /96 addresses that belong to the data center to a different PLAT -- just like is probably done today for the IPV4-only clients.

2.  Stick a NAT64 in front of the IPv4-only datacenter.

-d

> 
> Best wishes
> Qiong 
> 
>  
> From: internet-drafts
> Date: 2014-07-04 21:31
> To: Qiong Sun; Qiong Sun; Zhirong Zhang; Qin Zhao; Qin Zhao; Zhirong Zhang
> Subject: New Version Notification for draft-sun-v6ops-xlat-multi-00.txt
>  
> URL:            http://www.ietf.org/internet-drafts/draft-sun-v6ops-xlat-multi-00.txt
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Qiong <[email-masked]>
Date: Mon, 21 Jul 2014 18:10:14 +0800

Hi Dan,

Thanks a lot for your review and your comments. Please see my explanation
inline ~~

On Mon, Jul 21, 2014 at 4:36 AM, Dan Wing <[email-masked]> wrote:

> but I wonder why there are IPv4-only servers in a data center.  I see two
> operational approaches, which do not require changing 464XLAT.
>
> 1. I bet those IPv4-only servers exist because there are IPv4-only nodes
> (subscribers) on the same network, which similarly also need to access both
> the IPv4-only servers in the datacenter and also the IPv4 Internet.  Those
> IPv4-only subscribers might (or might not) be going through a NAT; it
> doesn't matter.
>
>
> [Qiong] In 464XLAT, it allows IPv6 UE running IPv4-only application across
IPv6-only network and access IPv4-only servers. One survey of IPv6
readiness in the Android Market showed approximately 85% of applications
being IPv6-capable. (https://sites.google.com/site/tmoipv6/464xlat)  For
these applications, most applications can only support IPv6 in the client
side, but not on the server side.

> Of course, those IPv4-only nodes aren't doing anything special; that is,
> they don't know how the routing occurs to cause some of their traffic to go
> towards the data center and the rest of their traffic towards the Internet.
>

> I do not believe 464xlat needs the IPv6-only 464xlat host to be aware of
> which NAT64 is handling its traffic.  Instead, the network operator can
> route the specific IPv6 /96 addresses that belong to the data center to a
> different PLAT -- just like is probably done today for the IPV4-only
> clients.
>
[Qiong] In 464XLAT, it does not require the network to deploy DNS64, so the
client cannot know the Pref64 by using DNS64. The current implementation is
to use Prefix discovery method in [RFC7050
<http://tools.ietf.org/html/rfc7050>] to get the Pref64 but it can not be
applied in multiple Pref64 case. So in the current implementation, all the
traffic will have the same Pref64, and thus the network operator cannot
distinguish different Pref64 prefixes for different PALTs.

Best wishes
Qiong

> *To:* Qiong Sun <[email-masked]>; Qiong Sun <[email-masked]>;
> Zhirong Zhang <[email-masked]>; Qin Zhao <[email-masked]>; Qin
> Zhao <[email-masked]>; Zhirong Zhang <[email-masked]>
> Status:
> https://datatracker.ietf.org/doc/draft-sun-v6ops-xlat-multi/

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/
<http://sourceforge.net/projects/laft6/>*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/
<http://sourceforge.net/projects/pcpportsetdemo/> *
===============================================