Hi, Tom (et al.),
On 4/27/2015 1:53 PM, Tom Herbert wrote:
> It's just that I don't see much benefit in these approaches other than
> the four bytes savings. IMO, the main drawback of directly encapsulating
> IP in UDP is that it instantly becomes a feature frozen in time. We can
> never improve upon it or extend it-- we can't change IP fragmentation,
> we can't add a header checksum to get to circumvent the unpleasantness
> of using the UDP zero checksum with IPv6, we can't add security, etc.
Right - this is one of my concerns with the current draft for IP-in-UDP.
We know of at least four things that tunnels need that IP-in-UDP ignores:
- stronger checksums
- fragmentation support
- signalling support (e.g., to test whether a tunnel is up or
to measure MTUs)
- support for robust ID fields (related to fragmentation,
e.g., to overcome the limits of IPv4 ID as per RFC 6864)
That minimally argues for an intermediate header, which at that point
needs to have a version number too. That would then require at least
(IMO) 64 bits up front:
1 bit - version (0)
1 bit - type (0 = UDP packet, 1 = signal)
1 bit - more fragments flag (0 for last one)
13 bits - frag offset (in 8-byte blocks, like IPv4 and IPv6)
16-bit - stronger checksum of the whole packet, e.g., CRC-16
(I'd rather CRC-32, but CRC-16 might be sufficient)
32 bits - ID field
(if fragmented or keep as 0 if not used
to avoid variable processing)
Note: this is a little like what SEAL attempts, but:
- it ignores the outer IP ID, which might be 0 as per
RFC 6484
- it adds a required checksum
- it's not extensible
I don't think this is a horrible idea to add this shim header, but IMO
it's important to add these capabilities to the IP-in-UDP to make it
more than a passing hack.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
