On 4/27/2015 3:14 PM, Templin, Fred L wrote: > 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.
Right, but the question is whether there's use for a lightweight variant that has ONLY the stuff below. How different would IP-in-UDP + the stuff below be from AERO or GUE? Joe > > 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
