On Mon, Apr 27, 2015 at 4:33 PM, Joe Touch <[email protected]> wrote: > > > On 4/27/2015 4:26 PM, Tom Herbert wrote: >> On Mon, Apr 27, 2015 at 4:08 PM, Joe Touch <[email protected]> wrote: > ... >>> 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. > > OK, well, then, I have to say that I think that's a lot of space to > waste for information that's already available in the first 4 bits of > the payload. > > Does GUE actually treat the contents differently based on the type of > packet *while in transit*? If not, then, IMO, it'd be better to drop > those unnecessary 4 bytes. > They're not unnecessary! GUE defines a protocol header, and my example was to demonstrate the bare minimum header to just do IP-in-UDP. The other bits provide the extensibility for fragmentation, checksum, virtual networking, security, etc. and also the protocol number (GUE can encapsulate anything that can be expressed as an IP protocol). See draft-ietf-nvo3-gue-00.
>> Fragmentation is an optional eight byte field >> (draft-herbert-gue-fragmentation-00), > > That's a bit long, IMO. 6 is more than sufficient, including the MF flag. > >> 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). > > Sorry, but "ick". IMO, that's a lot of bytes to waste on a weak > checksum. CRC-16 would be stronger and shorter; CRC-32 would be much > stronger than that. > >> 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. > > The purpose of the checksum is to protect against reassembly errors > ONLY. IMO, a checksum that can't detect misordering that's half-word > aligned (i.e., the Internet checksum) is a bad choice for that. > >> Also, it would be an interesting question as to whether a stronger >> checksum should include a pseudo header. > > If the purpose is to protect against reassembly errors, then it wouldn't > need to do that. > > Joe > > >> >> 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
