Hi Joe, You are right, and Tom's GUE already has all of this as does AERO which has taken the place of SEAL. But, thanks for remembering about SEAL, as it was a useful stepping stone in getting to this point.
Thanks - Fred [email protected] > -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of Joe Touch > Sent: Monday, April 27, 2015 3:04 PM > To: Tom Herbert > Cc: [email protected] > Subject: Re: [Int-area] Why combine IP-in-UDP with GUE? > > 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 _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
