Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt

[Joe Touch <[e-mail]>]

Hi, Tom,

On 5/25/2017 9:00 AM, Tom Herbert wrote:
> IPv4 and IPv6 can be directly encapsulated since they have a protocol
> number (can be encapsulated by version 0).
>
> As I mentioned previously, Ethernet could be directly encapsulated via
> EtherIP that has a 4 bit version number at the beginning of its
> header. The way this would work is to set a version 1 pattern to
> indicate EtherIP. For example, we could specify that 0101  would be
> EtherIP. When GUE receives such a packet it will notice it's version
> one and then see that it is EtherIP (differentiated from IPv4 0100 and
> IPv6 0110 values). The first four bits are then overwritten by 0011 to
> make it a valid EtherIP header and then the packet is resubmitted to
> the stack as EtherIP.
If you use the first 4 bits as the type identifier (which I think you
should, as noted below), then you could easily support a bunch of
encapsulations without needing the 4-byte overhead.

E.g.:
    0000 = GUE control (your "Version 0")
    0100 = IPv4
    0101 = IPv6

That leaves 13 other codes you can use for other protocols (including
MPLS, Ethernet, etc.), as long as you burn at least those 4 bits.

EtherIP effectively burns 2 bytes rather than 4 bits, but has the same
net effect.

> Transport protocols (TCP, UDP, SCTP) might also be nice to support
> with direct encapsulation in version 1, but unfortunately since they
> start with a variable port number there's no way to do that.
That works the same way as EtherIP - burn at least 4 bits indicating the
transport.

Joe

------
>From my previous post:

When we look at the first 2 bits of a GUE packet, we see:
    00 = GUE version 0
    01 = IPv4 or IPv6
    10 = undefined
    11 = undefined

That's nearly the same as looking at the first 4 bits as simply the IP
version number, and defining some of the unused IP versions as control:
    0000 (IPv0) = GUE control
    0001 (IPv1) = GUE control
    0010 (IPv2) = GUE encapsulation using the GUE header
    0011 (IPv3) = GUE encapsulation using the GUE header
    0100 (IPv4) = direct encapsulation of IPv4, with no intervening GUE
header
    0101 (IPv5) = direct encapsulation of IPv5 (ST), with no intervening
GUE header
    0110 (IPv6) = direct encapsulation of IPv6, with no intervening GUE
header
    0111 (IPv7) = direct encapsulation of IPv7 (TP/IX), with no
intervening GUE header
    1000 (IPv8) = direct encapsulation of IPv8 (PIP), with no
intervening GUE header
    1001 (IPv9) = direct encapsulation of IPv9 (TUBA), with no
intervening GUE header
    1010 (IPv10) = direct encapsulation of IPv10, when assigned
    1010 (IPv11) = direct encapsulation of IPv11, when assigned
    1010 (IPv12) = direct encapsulation of IPv12, when assigned
    1010 (IPv13) = direct encapsulation of IPv13, when assigned
    1010 (IPv14) = direct encapsulation of IPv14, when assigned
    1010 (IPv15) = direct encapsulation of IPv15, when assigned

I.e., all you're basically doing is defining the first four version
numbers of IP as your control plane. Unless we come back and assign them
in the future, any mechanism that encapsulates IP packets (which should,
IMO, be able to handle ALL IP versions, by definition) should be able to
include GUE-style signaling.

IMO, it's simpler to explain this all using this fixed-field
demultiplexer - in which case, you could even use just the IPv0 pattern
for control and the IPv1 pattern for encapsulation using the GUE header,
leaving the IPv2 and IPv3 equivalent patterns for future expansion.

Joe