Le 2012-03-25 à 03:50, Maoke a écrit : > > > 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!
OK, there is a point for ICMPv4 whose source is not a public IPv4 address. I agree that using 0../0 in this case creates a problem because some routers or FWs may discard packets having this address as source. This should be avoided by coming back to what there was in draft-03, i.e. 192.70.192.254 Thanks. Regards, RD > > - maoke > > RD > > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
