After more thinking, I can offer another possibility for debate:
If we plan to update UDP/IPv6 behaviour, I think we should revisit the case for a slightly different change, but one that presents a cleaner interface and does not start to introduce additional layering rules and new procedures for tunnels. - For IPv6, could we allow the use of the UDP-Lite procedure (RFC 3828) using protocol 17 (i.e. the value assigned for UDP)? That is, let tunnel endpoints use the UDP-Lite algorithm setting the UDP length to 8 to indicate checksum coverage only of the pseduo-header, but use protocol 17? IP type = 17 UDP Len = 8 cksum = only pseudoheader (fixed value per flow) - UDP-Lite doesn't require rules for tunnel layering, nor is it expected to lead to strange interactions with existing stacks. We could avoid all, but the last of the pitfalls in section 1.4 of the draft. - One objection to this could be that stacks would need to be changed (but the changes are minor and code exists for systems that already support UDP-Lite). Since UDP-Lite defaults to UDP, other applications that use the UDP Length in the traditional way would still work. - A tunnel receiver application would need to call-down to the socket layer to say it was going to use reduced checksum coverage, and the sender would set UDP length to 8. The transport would then handle the checking of fields, and wouldn't require the application to bind or check specific fields itself. It's simpler to build a well-designed application too. - Incremental updating of checksums is allowed with UDP-Lite, so middleboxes can process as per UDP. A middlebox that recalculates or verifies the checksum would require an IPv6 NAT update to revise the cksum. Thoughts? Gorry Fairhurst -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
