On 03/28/12 10:48, Satoru Matsushima wrote:
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
b) checksum non-neutrality
- additional code necessary for each transport protocol
- limited set of supported transport protocols
Less code, more transport protocols. I think the choice is easy.
There's a reason NPTv6 and NAT64 chose checksum neutrality...
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
