Subject: Updated UDP tunneling specification: draft-fairhurst-6man-tsvwg-udptt-01

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 29 Jun 2009 12:19:27 +0100

I've submitted a revision of the I-D below, and would be keen to see 
some discussion on this list as to whether this could solve the 
perceived problem that some tunnel protocols do not wish to employ the 
UDP checksum as specified in RFC 2460.

I would like to present this short draft in Stockholm, but would 
appreciate feedback before the meeting from anyone with comments or 
thoughts on this topic.

Best wishes,

gorry

The UDP Tunnel Transport mode
draft-fairhurst-6man-tsvwg-udptt-01
Independent Submission
Number_of_pages: 16
http://tools.ietf.org/html/draft-fairhurst-6man-tsvwg-udptt-01

Abstract:
This document proposes a standards track protocol called the UDP
Tunnel Transport.  This protocol updates the UDP processing of RFC
2460 for hosts and routers.  The update enables a sender to generate
a UDP datagram where the UDP checksum is replaced by a header check
determined only by the protocol header information.  For this use,
the document also updates the way the IPv6 UDP length field is
interpreted.  This mode is intended to minimise the processing cost
for the transport of tunnel packets using UDP.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 29 Jun 2009 11:28:48 -0700

I think this is a good idea, just some minor comments.

The draft says that the checksum will usually be constant for a UDP
flow. This is nice. For some tunnels it can even be computed at
configuration time (when the end-points are determined). I guess
the main case where this isn't the case, is when some datagrams
are fragmented but not all).

Regarding middleboxes. It says:

    o  Middleboxes SHOULD NOT truncate IPv6 datagrams where the IP length
       exceeds the Length specified in the UDP Header.

I guess some middleboxes might currently also just discard them? Or
maybe discarding is a kind of truncation :) I also wonder whether it
would be better to say MUST? At least they cannot support UDPTT unless
it is a MUST. Or at least a MUST when the length is 8.

Stig

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 29 Jun 2009 20:07:31 +0100

> are fragmented but not all).
I think I agree. IPv6 fragmentation results in some unwanted issues.

draft-eubanks-chimento-6man-00 notes:
        The tunneling protocol and implementation must not use
        fragmentation of the inner packets being carried.

So, in the current version of UDPTT (-01) it says:
       The tunneling protocol and implementation MUST NOT be used to
       transport IPv4 or IPv6 packets that use network-layer
       fragmentation.

> it is a MUST. Or at least a MUST when the length is 8.
OK, this may also be good advice for the next revision.

> Stig

Gorry

---

From: Stig Venaas <[email-masked]>
Date: Mon, 29 Jun 2009 12:23:47 -0700

>       transport IPv4 or IPv6 packets that use network-layer

But you are then talking about the packets being transported
(encapsulated inside UDPTT) not being fragments, right?

I believe the UDPTT checksum may depend on whether the UDPTT datagrams
get fragmented after encapsulation.

Anyway, not a big deal, and I agree that all fragmentation is evil :)

Stig

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 29 Jun 2009 21:18:15 +0100

> Anyway, not a big deal, and I agree that all fragmentation is evil :)
Ah, I see. I'm not sure we can do much about this. However I think it 
doesn't change the UDPTT checksum - since this is basically the 
pseudoheader of the datagram.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 29 Jun 2009 14:50:46 -0700

> pseudoheader of the datagram.

But the "next header" field in the pseudoheader is the "next header"
field from the outer IP header, right? So that would change from UDP
(17) to "fragmentation header" (44). Hence the checksum changes. Or
have I misunderstood? Well, all I'm saying is that it's good that the
checksum is fixed for a flow and the only reason I can think of it
varying would be fragmentation. Or maybe there are other headers that
might vary for a flow.

Stig

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 30 Jun 2009 07:36:17 +0100

OK, so the action I take is that I think there should be some text added 
to explain this case. When I get to making the next revision, I'll send 
you the text to make sure this is covered.

Thanks,

Gorry