On 5/26/2016 11:35 AM, Templin, Fred L wrote: > Hi Joe and Tom, > >> -----Original Message----- >> From: Joe Touch [mailto:[email protected]] >> Sent: Thursday, May 26, 2016 11:26 AM >> To: Tom Herbert <[email protected]> >> Cc: Templin, Fred L <[email protected]>; [email protected] >> Subject: Re: [Int-area] Call for adoption of draft-xu-intarea-ip-in-udp-03 >> >> >> >> On 5/26/2016 11:22 AM, Tom Herbert wrote: >>> On Thu, May 26, 2016 at 10:56 AM, Joe Touch <[email protected]> wrote: >>>> On 5/26/2016 10:52 AM, Tom Herbert wrote: >>>>> On Thu, May 26, 2016 at 10:41 AM, Joe Touch <[email protected]> wrote: >>>>>> Here's the problem: >>>>>> >>>>>> The first 4 bits are either part of the GUE header or IPv4 or IPv6. >>>>>> >>>>>> In the diagrams in draft-ietf-nvo3-gue and RFC791 they're indicated in >>>>>> the >>>>>> following bit order: 0,1,2,3 >>>>>> >>>>>> In GUE, these are 0,0,x,x >>>>>> >>>>>> In IPv4, these are 0,0,1,0 >>>>>> >>>>>> In IPv6, these are 0,1,1,0 >>>>>> >>>>> IPv4 is 0,1,0,0. >>>> Not LSB to MSB, which is how both GUE and RFC791 define the header: >>>> >>> >From RFC791: >>> >>> "Whenever an octet represents a numeric quantity the left most bit in >>> the diagram is the high order or most significant bit. That is, the >>> bit >>> labeled 0 is the most significant bit." >> Arrgh. >> >> Yup. OK, so the reason this would work is only because we no longer use >> IP versions 0..3. >> >> Got it. > I for one like it, and I am using it in my AERO implementation. As Joe points > out > however it does not account for fragmentation, identification etc. But, as > long > as you use it in a carefully controlled environment it should be OK.
Nothing accounts for fragmentation except to reassemble the contents if you have to do DPI on-path that examines the body of ANY IP packet, though. That's worth noting, but my advice would be to not examine the packet that way on-path. We really need to push back on that. > Can we have this added back to the GUE spec? I wonder why we would bother - it just saves 4 bytes in the default case, but it also disables use of extension headers and the magic number trick in section 4.6.2. Are losing both of those features really worth that few bytes of overhead AND the special-case processing? Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
