Gorry Fairhurst wrote:
Stig Venaas wrote:
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
>
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.
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
