Subject: [Softwires] 464XLAT - clarification? - relationship with 4rd-U

From: Rémi Després <[email-masked]>
Date: Mon, 31 Oct 2011 10:25:03 +0100

Hi Masataka-san,

1.
Thank you for sharing your interesting experience with the JPIX trial service based on 464XLAT.
Could you, for clarification, describe in more details formats of XLAT prefixes in this trial? 

2.
Objectives of 464XLAT and 4rd-U look very similar (ref draft-despres-softwire-4rd-u-01).

Indeed:
- Both use "DHCPv6 prefix delegation or another method" to inform CLAT/CEs of their IPv6 prefixes.
- Both "can implement traffic engineering based on IPv4 source address and IPv4 destination address" (a feature that, as noted in your draft, is missing in encapsulation).

OTOH, unless I miss something, 464XLAT doesn't provide incoming connectivity of CLATs in case of shared IPv4 addresses (while 4rd-U does provide it to CEs). In this respect 4rd-U seems functionally more complete.

Thoughts?

Regards,
RD

Le 27 oct. 2011 à 07:44, MAWATARI Masataka a écrit :

> Greetings Alain-san,
> 
> 
> Please let me make a presentation at IETF 82 Meeting.
> I would like to introduce the following draft as a v4->v6->v4
> translation experience in softwire working group.
> 
> ---
> Topic: "464XLAT: Combination of Stateful and Stateless Translation"
> Draft name: draft-mawatari-softwire-464xlat-01
> Time needed: 5-10minutes
> Presenter's name: Masataka Mawatari
> ---
> 
> This is a simple technique to provide IPv4 access service across
> IPv6 network just by using twice IPv4/IPv6 translation standardized
> in [RFC6145] and [RFC6146].
> 
> http://tools.ietf.org/html/draft-mawatari-softwire-464xlat
> 
> 
> Regards,
> Masataka MAWATARI
> 
> 
> * On Wed, 26 Oct 2011 18:22:04 +0200
> * Remi Despres <[email-masked]> wrote:
> 
>> Hi Alain,
>> 
>> Can you please schedule a time slot for a 4rd-U presentation:
>> 
>> Title	: A Unified stateless solution for IPv4 residual Deployments (4rd-U)
>> Document: draft-despres-softwire-4rd-u-01
>> Duration: 20 min (incl questions, expected to be numerous)
>> 
>> Thanks.
>> RD
> 
> -- 
> Japan Internet Exchange
> MAWATARI Masataka <[email-masked]>
> tel:+81-3-3243-9579
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 31 Oct 2011 06:09:15 -0700

On Oct 31, 2011 2:25 AM, "Rémi Després" <[email-masked]> wrote:
> - Both "can implement traffic engineering based on IPv4 source address
and IPv4 destination address" (a feature that, as noted in your draft, is
missing in encapsulation).
>
> OTOH, unless I miss something, 464XLAT doesn't provide incoming
connectivity of CLATs in case of shared IPv4 addresses (while 4rd-U does
provide it to CEs). In this respect 4rd-U seems functionally more complete.
> Thoughts?

The difference, imho, is stateful vs stateless.

Many operators like myself do not have enough ipv4 addresses to
incrementally grow with a stateless solution. It is not possible to
renumber the existing network and flash everyone into a stateless solution,
so I require a more scalable solution ...starting with very few address.

Also, given the very small amount of existing ipv4, the per port
allocations of a stateless solution are not acceptable for me.  Others may
have different starting positions therefore may find stateless helpful.

Cb

---

From: Rémi Després <[email-masked]>
Date: Mon, 31 Oct 2011 14:18:59 +0100

Le 31 oct. 2011 à 14:09, Cameron Byrne a écrit :

> Many operators like myself do not have enough ipv4 addresses to incrementally grow with a stateless solution.
> 
Sharing the orders of magnitude you have to face would help to appreciate this constraint (reminding that hosts that are dual-stack don't need as many IPv4 ports as others).

> It is not possible to renumber the existing network and flash everyone into a stateless solution, so I require a more scalable solution ...starting with very few address.
> 
> Also, given the very small amount of existing ipv4, the per port allocations of a stateless solution are not acceptable for me. 
> 
Same point as above.

Regards,
RD

> Others may have different starting positions therefore may find stateless helpful.
> 
> Cb
> >
> > Regards,
> > RD
> >
> >
> >
> >

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 31 Oct 2011 07:34:45 -0700

>> Many operators like myself do not have enough ipv4 addresses to
incrementally grow with a stateless solution.
>
> Sharing the orders of magnitude you have to face would help to appreciate
this constraint (reminding that hosts that are dual-stack don't need as
many IPv4 ports as others).

I believe the draft is addressing the scenario where the host and access
network are NOT dual stack due to address constraints.

For my use-case, without exposing my own forecasts, you can probably google
for mobile device growth to understand my growth magitude, regarding
available address space ...consider it non-existent within less than 12
months... to the point that adding new stores of ipv4 address is not a
feasible input to strategic planning. Imho, I simply do not believe there
is any *strategic* value in stateless solutions.

Yes, if we completely reinvented the service to use a scheme of stateless
address sharing there may be a path, but you cannot get there from here...
at least not in my case.

I believe we have discussed this before.  I hope my thoughts clarified your
question regarding the draft.

Cb

>> It is not possible to renumber the existing network and flash everyone
into a stateless solution, so I require a more scalable solution
...starting with very few address.
>> Also, given the very small amount of existing ipv4, the per port
allocations of a stateless solution are not acceptable for me.

---

From: MAWATARI Masataka <[email-masked]>
Date: Tue, 01 Nov 2011 15:03:24 +0900

Dear Remi-san,

Thank you for your comments. Please see inline below.

* On Mon, 31 Oct 2011 10:25:03 +0100

> Could you, for clarification, describe in more details formats of XLAT prefixes in this trial? 

IPv6 address for translation have IPv4 address embedded in the
low-order 32 bits of the IPv6 address, as you well know.
http://tools.ietf.org/html/draft-mawatari-softwire-464xlat-02#section-6.1

I might not understand what you want to know.
I described 464XLAT address translation chart here.

                                        source IPv4 address
                                        +-----------------------------+
                                        | IPv4 [global] (32bit)       |
                                        | [assigned to IPv4 pool@PLAT]|
                             +--------+ +-----------------------------+
                             |  IPv4  | destination IPv4 address
                             | server | +-----------------------------+
                             +--------+ | IPv4 [global] (32bit)       |
                                 ^      + [assigned to IPv4 server]   |
                                 |      +-----------------------------+
                             +--------+
                             |  PLAT  | Stateful XLATE (v4:v6=1:n)
                             +--------+
                                 ^
                                 |
source IPv6 address         (IPv6 cloud)
 +--------------------------------------+-----------------------------+
 |  XLAT prefix for src (96bit)         | IPv4 [private] (32bit)      |
 |  [assigned to each consumer of ISP]  | [assigned to IPv4 client]   |
 +--------------------------------------+-----------------------------+
destination IPv6 address
 +--------------------------------------+-----------------------------+
 |  XLAT prefix for dst (96bit)         | IPv4 [global] (32bit)       |
 |  [assigned to PLAT]                  | [assiend to IPv4 server]    |
 +--------------------------------------+-----------------------------+
                            (IPv6 cloud)
                                 ^
                                 |
                             +--------+
                             |  CLAT  | Stateless XLATE (v4:v6=1:1)
                             +--------+
                                 ^      source IPv4 address
                                 |      +-----------------------------+
                             +--------+ | IPv4 [private] (32bit)      |
                             |  IPv4  | | [assigned to IPv4 client]   |
                             | client | +-----------------------------+
                             +--------+ destination IPv4 address
                                        +-----------------------------+
                                        | IPv4 [global] (32bit)       |
                                        + [assigned to IPv4 server]   |
                                        +-----------------------------+

additional reference (sorry, a bit outdated)
http://www.apricot.net/apricot2011/media/Masataka_Mawatari_IPv6v4_Exchange_Service_for_sharing_IPv4_address.pdf

> OTOH, unless I miss something, 464XLAT doesn't provide incoming connectivity of CLATs in case of shared IPv4 addresses (while 4rd-U does provide it to CEs). In this respect 4rd-U seems functionally…

Kind Regards,
Masataka MAWATARI