Le 2012-03-28 à 11:17, Satoru Matsushima a écrit : > I remember that what Remi said during the meeting, is that 4rd-u is a > brand-new transport protocol
I doubt I said "brand new transport protocol": - 4rd-U builds on a lot of previous work - it isn't a transport-layer protocol. However, I did say and now confirm that, unlike -T, it doesn't use RFC6145. Consequently, RFC6145 doesn't need to be modified for U to be deployed. RD > which doesn't need to follow rfc6145 translation spec. > If it is true, 4rd-u doesn't need to take care checksum consistency of any > kind of L4 protocols. > On the other word, 4rd-u can support transparency of original packet so not > only the CNP, but also checksum recalculation are not required. > > cheers, > --satoru > > > On 2012/03/28, at 11:02, Simon Perreault wrote: > >> 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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
