 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Gorry Fairhurst wrote:
Stig Venaas wrote: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).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.
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
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.OK, this may also be good advice for the next revision.StigGorry