Le 2012-03-28 à 12:20, Maoke a écrit : > > > 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.
The problem with RDP exists only for shared-address CEs. For this, the specification doesn't propose to do anything (RDP isn't more supported for shared-address CEs in U than in T or E). > > - 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." Never forgotten. Actually already applied well before stated by Jon (that was in the seventies... the old X.25 times !) > 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. The proposal is not to add CNP in E, only to have U instead of E+T (or just T or just E). RD > > 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
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
