Hi Tom, > -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: Monday, April 27, 2015 5:11 PM > To: Joe Touch > Cc: Templin, Fred L; [email protected] > Subject: Re: [Int-area] Why combine IP-in-UDP with GUE? > > 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.
This loops back again to whether the first four bits of the payload could be used such as: 4 - a native IPv4 packet 6 - a native IPv6 packet X - a GUE-encapsulated packet I know you mentioned that it would require a re-work of the GUE header, but it looks like you have some spare bits to play with there, right? Thanks - Fred [email protected] > >> 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
