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

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 <dwing@cisco.com> wrote:

>
> On Jul 7, 2014, at 6:57 PM, Qiong <bingxuere@gmail.com> 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
>
>
> [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

>
>
> 2.  Stick a NAT64 in front of the IPv4-only datacenter.
>
> -d
>
>
> Best wishes
> Qiong
>
>
>  *From:* internet-drafts <internet-drafts@ietf.org>
> *Date:* 2014-07-04 21:31
> *To:* Qiong Sun <sunqiong@ctbri.com.cn>; Qiong Sun <sunqiong@ctbri.com.cn>;
> Zhirong Zhang <zhangzhr@ctbri.com.cn>; Qin Zhao <zhaoq@bupt.edu.cn>; Qin
> Zhao <zhaoq@bupt.edu.cn>; Zhirong Zhang <zhangzhr@ctbri.com.cn>
> *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
>
>  _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>

-- 
==============================================
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/> *
===============================================