2012/3/28 Simon Perreault <[email protected]> > 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 >
FYI. Remi has clarified: no code specific to transport protocol having destination port position and pseudo-header as same as TCP has. but other protocols are exceptions, needing specific codes. exceptions include at least: 1. ICMP; 2. RDP. > - supports all current and future transport protocols > again, supports current and future transport protocols, which follows TCP layout and TCP checksum's pseudo-header definition. > b) checksum non-neutrality > - additional code necessary for each transport protocol > - limited set of supported transport protocols > see above, CNP is also a limited improvement. > > Less code, more transport protocols. I think the choice is easy. > > There's a reason NPTv6 and NAT64 chose checksum neutrality... to me, we'd better never forget Jon Postel's law for the Internet robustness, which is written in RFC793: "be conservative in what you do, be liberal in what you accept from others." a better world could be achieved by having the L4-checksum adjustment as mandatory while, when possible, having the CNP as an operational complement. as implementor, we are conservative to consider some operation circumstances may not have CNP instead of requiring all operators MUST doing so; as operator, we are also conservative to consider some protocols may not have been fully supported by the translators, and we attach the CNP in our address formation in order to survive those protocol as better as we can. requiring others offering anything into our standard is really an easy life. but it is, a sort of, selfish. thanks, maoke > > > 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 >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
