I wanted to write to my 4rd friends that I think that CE is not the right term to use and would suggest using Customer Edge (CE) router instead. This is what RFC 6204 uses and is consistent with BBF terminology. So use CE router anywhere instead of CE.
--b > > 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
