2012/3/20 Rémi Després <[email protected]> > > Le 2012-03-19 à 16:12, Maoke a écrit : > > > > 2012/3/20 Rémi Després <[email protected]> > >> >> Le 2012-03-19 à 15:30, Maoke a écrit : >> >> >> >> 2012/3/19 Rémi Després <[email protected]> >> >>> >>> Le 2012-03-19 à 11:38, Maoke a écrit : >>> ... >>> >>> >>>>> let me draw an example for that: >>>>> >>>>> A --- CE ----(IPv6 domain; router R1 here)---- BR ----(IPv4 Internet; >>>>> router R2 here)--- B >>>>> >>>>> ... >>> >>> 4rd-u isn't concerned with what happens between A and CE. >>>> There, internal hosts have RFC1918 addresses and external hosts public >>>> IPv4 addresses. >>>> >>> >>> no problem here for 4rd-u, but RFC6145/6146 work also in the case the >>> translator is not located next to the end hosts. then i understand 4rd-u is >>> less flexible. >>> >>> >>> I don't see the configuration you have in mind. >>> >>> >> >> people often insert a router between the home CE and their computers ;-) >> sometimes, e.g., because the CE has limited number of ports for connection >> or less funtioning. >> >> >> >> I still don't see the problem with a NAT44 in the CE. >> >> > > the topic is about 0.0.0.0 as the source address for the ICMPv6-translated > ICMPv4 message's IP header. if there is a router between the CE and the > host, the packet with 0.0.0.0 will be discarded rather than being > forwarded, according to the common definition of the "unspecified address". > > > As I already said, 0.0.0.0 never appears on any wire: neither in IPv6, of > course, nor in IPv4 where the only in-site IPv4 addresses are RFC1918. > Anything missed? > > well, not understood at all. Remi, may you please make a numerical example to explain in detail how the "unspecified IPv4 address" is used in 4rd-u/NAT64+? thanks in advance!
- maoke > RD > > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
