On 10 Jun 2008, at 15:59, Carsten Bormann wrote: > > 2) Given this transport, the end system is likely to want back the > feature of UDPv4 that allowed sending a zero checksum. This transport > is a nice example for how it was a mistake to conflate policy and > mechanism in UDPv6: Encoding the *policy* not to send packets without > a checksum that includes a pseudo-header with the *mechanism* to never > allow zero checksums in UDPv6.
Yes, it would have been nicer if the mandatory pseudoheader was part of the IPv6 header, rather than having to be reimplemented by every transport protocol using IPv6, including ICMP. The pseudoheader check is necessary. The payload check is not. That's what UDP-Lite gives. > Of course, you should not have mechanism that a policy makes sure you > will never use, but the mechanism is already there for IPv4, and the > example is exactly one such case where the policy would not imply non- > use of the mechanism. > > Obviously, if an end system does not want protection from UDP (and it > shouldn't want it in the ISA100 case), it should say so by setting the > checksum to zero. No. It should either: a. Use UDP-Lite, to avoid checksum coverage of its payload, and still get a pseudoheader check from UDP. b. Implement its own transport protocol, in parallel with UDP/TCP/ SCTP, with its own pseudoheader check, doing payload coverage however it likes. The endhost pseudoheader check has to come from somewhere. > The mechanism/policy conflation mentioned above > makes that impossible. Not impossible. It comes down to the pain of using UDP-Lite, or the pain of writing your own proper gets-a-protocol-number transport protocol with its own pseudoheader check. Either is better from layering/size/complexity viewpoints than layering over UDP and turning UDP checksums off. > Changing UDPv6 at this stage is a big step. If that is not what we > (the IETF/the IPv6 implementers community) want to do, there is no way > for the end system to make that statement. This does not mean that we > shouldn't honor it. Sorry, I'm unclear on the meaning of your last sentence here; the double negative (triple from the previous sentence) doesn't help. tschuess, L. DTN work: http://info.surrey.ac.uk/Personal/L.Wood/saratoga/ <http://info.surrey.ac.uk/Personal/L.Wood/><[EMAIL PROTECTED]> _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
