On Mon, Apr 27, 2015 at 4:08 PM, Joe Touch <[email protected]> wrote: > > > > 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? > Without any optional fields or flags, the difference with GUE is an additional four byte header between the UDP header and the encapsulated IP header. For IPv4 that header is 0x00040000, and for IPv6 the header is 0x00290000.
Fragmentation is an optional eight byte field (draft-herbert-gue-fragmentation-00), and the GUE checksum is an optional 4 byte field with that contains a UDP-lite like checksum (value and length of checksum'ed data) (draft-herbert-guecsum-00). A stronger checksum has not been defined for GUE, it could be but I'd really like a better sense of the use case. We already get UDP checksum computation for free (NIC checksum offload), and CRC doesn't provide for security. DTLS might be better to encourage than CRC. Also, it would be an interesting question as to whether a stronger checksum should include a pseudo header. Tom > > 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
