> a. Use UDP-Lite, to avoid checksum coverage of its payload, and > still get a pseudoheader check from UDP.
How does that help with getting rid of the checksum? With UDP-lite, you now have two, with different coverage. > b. Implement its own transport protocol, in parallel with UDP/TCP/ > SCTP, with its own pseudoheader check, doing payload coverage > however it likes. That's what they did. They want to do this on top of UDP, which is a usual way to build new transport protocols these days (cf. RTP). If UDPv6 were like UDPv4, this would be a better fit. >> 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. I don't agree with "better" here. Being able to use UDP reduces complexity here; certainly from an implementation point of view (if you consider that there will be hosts with common operating systems on e.g. Ethernets that want to talk to lowpans). >> 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. I'm just saying that, in the first-hop/last-hop case, HC could help 2460 a little here, just (as you noted) NATs tend to "help" with maintaining that checksum, by proxying out the UDP checksum generation/ check to the next hop, as long as there is something else that provides e2e protection. In the first-hop case, it is easy for the host to make the statement (by providing a mechanism for eliding the checksum); in the last-hop case, there would need to be some agreement (implied or signaled). Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
