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. > 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
