>>>> 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.
everything can be _implemented_, that's not the point. > => Clarifying this point would IMHO be useful. it is clearly requiring bigger changes to tunnel code. which unlike NAT code is attached to 'one' endpoint. it makes co-existence of a MAP endpoint and native IPv6 nodes within a single /64 much harder. let us turn this around. what's the point in embedding a new set of CNP bits in the IPv6 address, when the L4 checksum can be incrementally updated. that's what everyone has existing code to do already... cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
