Le 8 nov. 2011 à 09:36, Ole Troan a écrit : >>> 1. Checksum neutrality being an open question, it is relevant here. >>> 2. It is useful AFAIK to distinguish CE addresses from BR addresses. >>> >>> The best proposal I know so far is as follows (with CNP = Checksum >>> neutrality preserver) >>> >>> CE ADDRESS >>> >>> <- - - - - - IPv6 Unformatted address (104 bits) - - - -> >>> +-------------------+----------+----------+---------------+ >>> | Rule IPv6 prefix |IPv4 suff.| Max PSID | Padding = 0 | >>> +-------------------+----------+----------+---------------+ >>> : >>> :<- - - - - - - - - 64 - - - - - >:<- - - - 40 - - - - ->: >>> : :\ \ >>> : <8> :<- 16 -> >>> : : : : : >>> +----------------------------------'-'----------------------+--------+ >>> | IPv6 unformatted address (part 1)|V| | CNP | >>> >>> +----------------------------------+-+----------------------+--------+ >>> <- - - - - - - - - - - IPv6 address (108 bits) - - - - - - - - - - > >>> >>> >>> >>> BR ADDRESS >>> >>> +------------------------------------+-+-----------------+-+-------+ >>> | BR IPv6 prefix |V| IPv4 address |0| CNP | >>> +------------------------------------+-+-----------------+-+-------+ >>> < - - - - - - - - - 64 - - - - - - ><8><- - - 32 - - -><8>< 16 > >>> >> >> +1 >> The checksum neutrality is desirable for translation case. >> I suggest to take above format into consideration > > the consequence of that is that the destination IPv6 address will change for > every flow.
If a source ignores the destination PSID length, yes, IPv6 addresses of two flows going to the same CE may differ. But so what? - The IPv4 packet submitted to the CE NAT is the same as the source IPv4 packet - The final destinations behind the NAT may differ too > the MAP node cannot any longer listen to a single IPv6 address for MAP > traffic, but has to intercept packets for a whole prefix. - BR's of double translation have always had this property. - Talking with Mark townsley, I got the understanding that this wasn't a real problem, at least with IOS. => Clarifying this point would IMHO be useful. Cheers, RD > > cheers, > Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
