Hi, all, One remark, and one correction, about this recent email:
Remark: If the second solution below is adopted (4V6-specific IID in 4rd-4V6 IPv6 addresses), the first solution (4V6-specific protocol number) is no longer necessary. However, it better separates functions, and makes no harm. The suggestion remains therefore to adopt both solutions (but I have no objection if only the second is adopted). Correction: The proposed 4V6 IID (ISATAP based with null IPv4 address), because it is globally unique, must have its "u" bit has to be 1 (ref sec. 6.1 of RFC 5214). It is then 20:5efe:0:0. (This is in fact what ensures that this IID differs from all non-globally-unique IID's that hosts are permitted to have.) Regards, RD Le 22 juil. 2011 à 12:20, Rémi Després a écrit : > > Le 21 juil. 2011 à 19:27, Wojciech Dec a écrit : > ... >>> . Packet X is submitted to ordinary IPv6 routing because its payload IS NOT >>> an IPv4 packet. >>> . Packet Y has its contents directly submitted to the CE NAT44 because its >>> payload IS an IPv4 packet. (The 4V6 address 2001:db8:a::1, never treated as >>> a destination on any IPv6 link, is in fact a "dummy address".) >>> =============== >> >> Please describe what you mean by an IPv6 "dummy address", or where can >> one find it described? > > OK, ignore the "dummy address" bit. > (The behavior is AFAIK clear, with no need for a new name.) > > Let's now be constructive, with solutions. > >> Oh, one other thing: Say that IPv6 Host H was actually running an >> IPinIP tunnel/application and wants to receive such traffic. How does >> the model you describe work then? > > OK, that's a good point: if hosts behind a 4V6 CE are permitted to have any > addresses that start with the CE assigned IPv6 prefix, a host whose address > is the same as the specified 4V6 address won't be able to do IPv4 in IPv6 > tunneling per RFC 2473. > > SOLUTION: > This is easily avoided if the 4V6E encapsulation is done with a Protocol > number different from 41. > Since Protocol 41 is in IANA for point-to-point tunnels of RFC 2473, it makes > sense to have a new one for stateless multipoint tunnels. > > >> ... in the S46 set-up with the >> characteristics as outlined in my initial reply, without system >> elements having duplicate IPv6 addresses, the problem you mention does >> not appear in neither translation nor tunneling modes. > > OK, but the setup of your initial reply is only for CE's being assigned a > /64, which imposes a single LAN-side link. Shorter IPv6 prefixes assigned to > multiple-link sites lead to more complex analysis. > > SOLUTION: > If the IID of 4V6 addresses is one that never needs to be assigned to work in > IPv6, which isn't difficult to ensure, no conflict is possible between a > hosts IPv6 address and a 4V6 address. > > A possible IID value is that of an embedded IPv4 address (as in ISATAP), with > a reserved IPv4 address that no network would use. > If this address is 0.0.0.0, the 4V6 IID is 0:5efe:0:0. > (If a completely new address is preferred,it could for instance be 192.0.0.0, > to be registered by IANA to mean "unspecified IPv4 address", the equivalent > of :: in IPv6. > > > Both solutions are AFAIK extremely simple, and do solve the two issues. > I hope they will be looked at constructively. > > > Regards, > RD > > > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
