2012/3/28 Maoke <[email protected]> > > > 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. >
grammatical erratus: ... current and future transport protocol that follows ... > > >> 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
