>>> On the contrary, there is a big difference. The difference is that you are >>> only concerned with L3. L4 can change: UDP, TCP, ICMP, STCP, DCCP, etc, >>> etc, etc. You need a lot of code to handle all existing transport >>> protocols, and you still can't handle future protocols that people might >>> develop. >>> >>> Checksum neutrality is a *big* advantage. >> >> Cool. How many protocols we should support for just a *transition* mechanism? > > The way I see it, IPv4-over-IPv6 (e.g. 4rd) has potential to be used for a > longer time than IPv6-over-IPv4 (e.g. 6rd). Operators will need to keep > providing clients with residual IPv4 for a potentially loooooooooooong time. > So we need to be really careful to get this right, because we'll be stuck > with what we design for a long time. > > So you have two options: > > a) checksum neutrality > - no code specific to each transport prototol > - supports all current and future transport protocols
this comes with a number of caveats. and given that you need to look at the L4 to get the ports anyway... > b) checksum non-neutrality > - additional code necessary for each transport protocol existing code. existing standard. > - limited set of supported transport protocols the same issue applies above. > > Less code, more transport protocols. I think the choice is easy. > > There's a reason NPTv6 and NAT64 chose checksum neutrality... NAT64?? cheers, Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
