>>> 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
Softwires@...
https://www.ietf.org/mailman/listinfo/softwires
