2011/11/8, Ole Troan <[email protected]>: >>> 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. > the MAP node cannot any longer listen to a single IPv6 address for MAP > traffic, but has to intercept packets for a whole prefix.
Yes. I see there are two choices when MAP nodes process incoming packages i) Should we let MAP node interface bind to a single static IPv6 address ii) Should we let MAP node interface bind to a route to IPv4-translatable IPv6 prefix In translation case, above two cases are possible. That is implementation specific. So I suggest to put above design as int-id candidate for more inputs from the community BRs Gang _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
