Subject: [draft-eubanks-chimento-6man-00.txt] Another possibility for solving this issue.

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 20 Mar 2009 19:03:48 +0000

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