On Tue, Apr 28, 2015 at 11:29 AM, Joe Touch <[email protected]> wrote:
>
>
> On 4/28/2015 11:24 AM, Lucy yong wrote:
>> Hi Fred,
>>
>> GUE uses UDP port to indicate GUE encapsulation as UDP payload and
>> GUE has prototype field to indicate the payload type. Making an
>> exception and requiring inspection of first nibble at end points is
>> not a good idea.
>>
>> I don't like the combination approach.
>
> If you examine the first 4-bits of the IP field, you will:
>
> - work with any IP version in the future
> - no need new GUE codepoints for new IP versions
>
> If you keep duplicate information in the header, you will:
>
> - need to explain what you do when the two fields
> do not match
>
> - still need to check the first 4 bits of the IP
> header anyway
>
We've already been handling these case for more than twenty years in
having two Ethertypes for IPv4 and IPv6. This is not a new issue for
the implementation.
> - still need to check some bits in the GUE header
>
> There's no downside to using the existing IP version field here, and
> there are many downsides to using a duplicate field.
Fred's approach is only an optimization that could be applied when
encapsulating an IPv4 or v6 packet without any GUE options and so no
GUE header. When the GUE header is present then the protocol field is
set to indicate what the next protocol is. This is the way any other
multi-protocol encapsulation works (e.g. GRE, ESP, IP extension
headers). If you have a proposal for an alternate encoding that
eliminates the proto field please demonstrate it. The UDP-GUE headers
are below. Proto/ctype is an IP protocol number when C bit is not set.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source port | Destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0x0|C| Hlen | Proto/ctype | Flags |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Fields (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension flags (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Extension fields (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Private data (optional) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
