On Tue, Apr 28, 2015 at 10:13 AM, Templin, Fred L <[email protected]> wrote: > 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? >
The IP version number would need to coincide with the first four bits of the GUE header-- this is a two bit GUE protocol version number, the control bit, and one bit of the header length which is 5 bits. The only way I think it could work would be to expand the version field to four bits and shift the control bit right by two bits. This would result in loss of two flag bits and I don't see how to make this forward compatible with the current spec. Tom > 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
