Masataka-san, I was wondering whether my understanding that CLAT-to-CLAT traffic MUST always go via the PLAT might be due to a misunderstanding, but these additional details do confirm it.
This clarifies that the scopes of the two solutions are different: - stateful vs stateless (flexible IPv4-address assignments vs simplicity and scalability) - hub&spoke-only vs possibly mesh Sorry for asking what I could have understood from the document. Regards, RD Le 1 nov. 2011 à 07:03, MAWATARI Masataka a écrit : > Dear Remi-san, > > Thank you for your comments. Please see inline below. > > * On Mon, 31 Oct 2011 10:25:03 +0100 > * Remi Despres <[email protected]> wrote: > >> 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? > > 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 > > >> 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 > > > Kind Regards, > Masataka MAWATARI > > > -- > Japan Internet Exchange > MAWATARI Masataka <[email protected]> > tel:+81-3-3243-9579 > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
