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

[Dan Wing <[e-mail]>]

On Jul 7, 2014, at 6:57 PM, Qiong <[e-mail]> 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
>  
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops