On Thu, May 26, 2016 at 10:41 AM, Joe Touch <[email protected]> wrote: > > > On 5/26/2016 10:08 AM, Templin, Fred L wrote: > > The only way the proposal "unambiguously" knows the difference is when >> the first 4 bits are 4 or 6, but those are valid configurations of the >> first 4 bits of other protocols (notably ICMPv4). > > There is more to it than that - Tom's proposal can unambiguously distinguish > raw IPv4/IPv6 from all others. > >> So if you see 4 or 6, you can't just assume that the GUE header is not >> present. > > You don't look for 4 or 6; you look for the 2nd-most significant bit being > set to 1. If it is set to 1, then you examine the 3rd and 4th MSBs and > act only of the combined 4 MSBs are either 4 or 6. > > 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. The first two bits of the GUE header are version number which is currently is 00, so if we declare that GUE version 01 is direct IP encapsulation this scheme does work. Normal GUE has version 00, direct IP is version 01.
> So you absolutely know the difference between GUE and IPv6, but not so much > for IPv4. For IPv4, you still then have no idea whether the GUE 4-byte > extension is used or not. > > You'd have to redesign GUE to move the 00 bits to the high-part of the first > nibble for this to work. > It's a matter of defining a new version that happens to work due to happenstance. It's feasible, but I am still worried that it's a limited use case and saving only four bytes of overhead is inconsequential. Tom > Joe > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
