Subject: [Int-area] I-D Action: draft-ietf-intarea-gue-04.txt

From: [email-masked]
Date: Thu, 18 May 2017 15:53:11 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Area Working Group of the IETF.

        Title           : Generic UDP Encapsulation
        Authors         : Tom Herbert
                          Lucy Yong
                          Osama Zia
	Filename        : draft-ietf-intarea-gue-04.txt
	Pages           : 37
	Date            : 2017-05-18

Abstract:
   This specification describes Generic UDP Encapsulation (GUE), which
   is a scheme for using UDP to encapsulate packets of different IP
   protocols for transport across layer 3 networks. By encapsulating
   packets in UDP, specialized capabilities in networking hardware for
   efficient handling of UDP packets can be leveraged. GUE specifies
   basic encapsulation methods upon which higher level constructs, such
   as tunnels and overlay networks for network virtualization, can be
   constructed. GUE is extensible by allowing optional data fields as
   part of the encapsulation, and is generic in that it can encapsulate
   packets of various IP protocols.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-gue/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-intarea-gue-04
https://datatracker.ietf.org/doc/html/draft-ietf-intarea-gue-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gue-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 19 May 2017 02:53:45 +0000

Hi all,

With regard to directly encapsulating IPvx packet in UDP, I think the following argument for using Version 1 of GUE is not valid:

"This technique saves encapsulation overhead on costly links
   for the common use of IP encapsulation, and also obviates the need to
   allocate a separate port number for IP-over-UDP encapsulation."

First, I don't think the encapsulation overhead of 4 bytes is a matter. However, the premise is that it's meaningful for the IETF to develop such a GENERIC and COVERALL encapsulation method which is still looking for nails:)  If I remembered correctly, this draft was originally adopted by the NVO3 WG which is focused on multi-tenancy, although this draft has nothing to do with multi-tenancy:) Latter it becomes a INTAREA WG draft. by the way, did I miss the WG adoption call for this draft in the INTAREA WG or the WG adoption call isn't occurred at all?

Second, UDP itself has been widely used as a tunnel technology due to its load-balancing capability. See LISP [RFC6830], VXLAN [RFC7346], MPLS-in-UDP [RFC7510], GRE-in-UDP [RFC8086], ESP-in-UDP [RFC3948], TRILL-in-UDP, NSH-in-UDP, VXLAN-GPE, GENEVE, GUE, ... The destination port is used to distinguish these different UDP tunnel payload types. For IP-in-UDP, there has been a draft (https://tools.ietf.org/html/draft-xu-intarea-ip-in-udp) which was originally discussed in Softwire WG (https://tools.ietf.org/html/draft-xu-softwire-ip-in-udp) . IMHO, it seems ugly to use a version field within the GUE header to distinguish IPvx header from the GUE header itself. Is the UDP destination port number resource running out? If so, why not use GRE-in-UDP to carry GUE so as to save one more UDP destination port number? 

Third, if the GUE devotes itself to save the UDP destination port number for the interest of the internet community, the 2-bit version field abused as a payload type indicator is obviously not enough:)

Best regards,
Xiaohu

> -----邮件原件-----
> 发件人: Int-area [mailto:[email-masked]] 代表
> [email-masked]
> 发送时间: 2017年5月19日 6:53
> 收件人: [email-masked]
> 抄送: [email-masked]
> 主题: [Int-area] I-D Action: draft-ietf-intarea-gue-04.txt
> 
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Tom Herbert <[email-masked]>
Date: Fri, 19 May 2017 07:56:36 -0700

Hi Xuxiaohu,

Thanks for the comments. Some response are inline.

On Thu, May 18, 2017 at 7:53 PM, Xuxiaohu <[email-masked]> wrote:
> First, I don't think the encapsulation overhead of 4 bytes is a matter.

I'm not sure everyone would agree with that. The case was made when we
were discussing it that the savings would be beneficial for some
deployments.

> However, the premise is that it's meaningful for the IETF to develop such a GENERIC and COVERALL encapsulation method which is still looking for nails:)

The protocol is called *Generic* UDP Encapsulation for reason.

> If I remembered correctly, this draft was originally adopted by the NVO3 WG which is focused on multi-tenancy, although this draft has nothing to do with multi-tenancy:) Latter it becomes a INTAREA WG draft. by the way, did I miss the WG adoption call for this draft in the INTAREA WG or the WG adoption call isn't occurred at all?
>
It was adopted after Seoul IETF.

> Second, UDP itself has been widely used as a tunnel technology due to its load-balancing capability. See LISP [RFC6830], VXLAN [RFC7346], MPLS-in-UDP [RFC7510], GRE-in-UDP [RFC8086], ESP-in-UDP [RFC3948], TRILL-in-UDP, NSH-in-UDP, VXLAN-GPE, GENEVE, GUE, ... The destination port is used to distinguish these different UDP tunnel payload types. For IP-in-UDP, there has been a draft (https://tools.ietf.org/html/draft-xu-intarea-ip-in-udp) which was originally discussed in Softwire WG (https://tools.ietf.org/html/draft-xu-softwire-ip-in-udp) . IMHO, it seems ugly to use a version field within the GUE header to distinguish IPvx header from the GUE header itself. Is the UDP destination port number resource running out?

>From RFC7605, section 6 "Conservation":

"Assigned port numbers are a limited resource that is globally shared
by the entire Internet community.  As of 2014, approximately 5850 TCP
and 5570 UDP port numbers had been assigned out of a total range of
49151.  As a result of past conservation, current assigned port use is
small and the current rate of assignment avoids the need for
transition to larger number spaces.  This conservation also helps
avoid the need for IANA to rely on assigned port number reclamation,
which is practically impossible even though procedurally permitted
[RFC6335].

Also, it's not just the assignment that is a pain, port numbers to
need to be managed in networks. If we introduce a new port number in
the datacenter management tools, firewalls, packet capture need to be
updated.

A feature of GUE is that the payload transform option allows DTLS to
be done on the payload. This obviates needing to ask for two port
numbers (a DTLS variant and non-DTLS variant) as several of the
encapsulation methods you listed above have done.

> If so, why not use GRE-in-UDP to carry GUE so as to save one more UDP destination port number?
>
Then we'd be talking about having to reserve an Ethertype for GUE.

> Third, if the GUE devotes itself to save the UDP destination port number for the interest of the internet community, the 2-bit version field abused as a payload type indicator is obviously not enou…
I'm not sure how it's "obviously not enough". Version 1 handles the
currently deployed two IP protocol versions. The technique allows for
supporting two more IP protocol versions to be supported without
burning another version number.

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 May 2017 14:04:35 -0700

Hi, all,

Speaking as lead of the IANA ports expert review team, and co-author of
RFCs 6335 and 7605 on port assignment and use...

> >From RFC7605, section 6 "Conservation":
Yes, they're a limited, finite resource.

No, they're not so critical that we cannot assign one  more.

However, there is a basic principle that "one" is fine, but "one" that
leads to another, then another, etc., generally is not.

That's why IANA expects that new assigned ports include version support,
so that new versions can reuse an assignment rather than requiring a new
one.

See RFC7605:

   >> New services SHOULD support security capabilities, either directly
   or via a content protection such as TLS [RFC5246 <https://tools.ietf.org/html/rfc5246>] or Datagram TLS
   (DTLS) [RFC6347 <https://tools.ietf.org/html/rfc6347>], or transport protection such as the TCP-AO
   [RFC5925 <https://tools.ietf.org/html/rfc5925>].  Insecure versions of new or existing secure services
   SHOULD be avoided because of the new vulnerability they create.

I.e., something like DTLS support would be expected. A non-DTLS variant
might be accommodated on the same port using negotiation, but a separate
assignment may no longer be appropriate (even though this was done in
the past, esp. where negotiation was not possible).

> ...
One of these version numbers could easily indicate a longer or
additional version field, which could be extended indefinitely.

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 May 2017 14:41:18 -0700

FWIW:

It might be useful for this document to be more clear in showing

a) the specific header it introduces, before it talks about variations
(e.g. in Sec 2 when it is introduced, rather than in subsections)

b) examples of that header in the context they would appear in a typical
packet, clearly indicating the GUE portion as distinct from that context

The current explanation is a bit confusing because it uses atypical terms:

    - sec 2, what is a UDP/IP header? When we say TCP/IP, we mean the
protocol suite, not a header

        AFAICT, this should show UDP and IP as separate:
[IP][UDP][GUE][GUE payload]

    - sec 3.1, 4.1, and 4.2 present a header format in a confusing way

        GUE doesn't change the UDP header; it's a header inside UDP, so
the UDP part should be omitted (making it consistent with what I expect
for sec 2)

         the representation in 3.1 is confusing in comparison to 3.3.2,
which is just the GUE header (again, omitting UDP from 3.1, 4.1, and 4.2
fixes this)

Sec 4.1 should make it clear that the fields shown are just that of the
IPv4 header - and the fact that the first two bits are 01 is what helps
GUE realize that this is a special case.

Sec 4.2 should do the same for IPv6.

It seems like you also need to address what happens for IPv5, IPv7, and
later values of IP (i.e., 00 = GUE, 01=IPv4-7, and what happens for 1x?).

Joe

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 20 May 2017 01:39:36 +0000

Hi Tom,

Thanks for your quick response. Please see my reply inline.

> -----邮件原件-----
> 发件人: Tom Herbert [mailto:[email-masked]]
> 发送时间: 2017年5月19日 22:57
> 收件人: Xuxiaohu
> 抄送: [email-masked]
> 主题: Re: [Int-area] Is the UDP destination port number resource running out?//
> re: I-D Action: draft-ietf-intarea-gue-04.txt
> 
> Hi Xuxiaohu,
> 
> > With regard to directly encapsulating IPvx packet in UDP, I think the following
> argument for using Version 1 of GUE is not valid:
> >
> I'm not sure everyone would agree with that. The case was made when we were
> discussing it that the savings would be beneficial for some deployments.

If the saving is beneficial, it'd better to assign a dedicated port number for each UDP payload type( e.g., IP packet), rather than combining the UDP port number dedicated for GUE and the version field within the GUE header together to indicate whether the UDP payload is GUE or IP (or even other payload type if the GUE is devoted to help save the UDP port number resource for the IETF community:))  

BTW, what happens if any other GUE payload has the same desire of saving the 4 byte GUE header overhead?

> > However, the premise is that it's meaningful for the IETF to develop
> > such a GENERIC and COVERALL encapsulation method which is still
> > looking for nails:)
> 

I know that you are trying to specify a generic UDP encapsulation. However, there has been a generic UDP encapsulation scheme that is GRE-in-UDP [RFC8086]. Furthermore, there is another generic UDP encapsulation scheme called GENEVE that the NVO3 group is working on. It's better for the IETF community to avoid specifying multiple similar encapsulation schemes and therefore the NVo3 WG co-chairs and the corresponding AD try their best to reach a consensus of working together on a single encapsulation on the basis of GENEVE among the WG members. Do you still believe it's helpful for the industry to specify one additional generic encapsulation scheme in another IETF WG?

> > If I remembered correctly, this draft was originally adopted by the NVO3 WG
> which is focused on multi-tenancy, although this draft has nothing to do with
> multi-tenancy:) Latter it becomes a INTAREA WG draft. by the way, did I miss
> the WG adoption call for this draft in the INTAREA WG or the WG adoption call
> isn't occurred at all?
> >
> > Second, UDP itself has been widely used as a tunnel technology due to its
> load-balancing capability. See LISP [RFC6830], VXLAN [RFC7346], MPLS-in-UDP
> [RFC7510], GRE-in-UDP [RFC8086], ESP-in-UDP [RFC3948], TRILL-in-UDP,
> NSH-in-UDP, VXLAN-GPE, GENEVE, GUE, ... The destination port is used to
> distinguish these different UDP tunnel payload types. For IP-in-UDP, there has
> been a draft (https://tools.ietf.org/html/draft-xu-intarea-ip-in-udp) which was
> originally discussed in Softwire WG
> (https://tools.ietf.org/html/draft-xu-softwire-ip-in-udp) . IMHO, it seems ugly to
> use a version field within the GUE header to distinguish IPvx header from the
> GUE header itself. Is the UDP destination port number resource running out?
> 
> "Assigned port numbers are a limited resource that is globally shared by the
> entire Internet community.  As of 2014, approximately 5850 TCP and 5570
> UDP port numbers had been assigned out of a total range of 49151.  As a
> result of past conservation, current assigned port use is small and the current
> rate of assignment avoids the need for transition to larger number spaces.  This
> conservation also helps avoid the need for IANA to rely on assigned port
> number reclamation, which is practically impossible even though procedurally
> permitted [RFC6335].

If the port number resource was scarce, it'd better for the IETF to recommend using the GRE-in-UDP [RFC8086] for any new payload type which is desired to be transported over UDP UNIFORMLY rather than SELECTIVELY, IMHO.

> Also, it's not just the assignment that is a pain, port numbers to need to be
> managed in networks. If we introduce a new port number in the datacenter
> management tools, firewalls, packet capture need to be updated.

The version numbers need to be managed as well:)

> A feature of GUE is that the payload transform option allows DTLS to be done
> on the payload. This obviates needing to ask for two port numbers (a DTLS
> variant and non-DTLS variant) as several of the encapsulation methods you
> listed above have done.
> 

EtherType is a two-octet field which has the same length as the UDP port number. Fortunately, it seems that the IEEE doesn't scant the assignment of the Ethertype code resource. Hence you don't need to worry about it.
 
> > Third, if the GUE devotes itself to save the UDP destination port
> > number for the interest of the internet community, the 2-bit version
> > field abused as a payload type indicator is obviously not enough:)
> >
> I'm not sure how it's "obviously not enough". Version 1 handles the currently
> deployed two IP protocol versions. The technique allows for supporting two
> more IP protocol versions to be supported without burning another version
> number.

It seems that your are attempting to repeat the notorious first nibble issue associated with MPLS (for more details about the first nibble issue, please refer to https://tools.ietf.org/html/draft-xu-mpls-payload-protocol-identifier-02) in your GUE design.

Best regards,
Xiaohu

> >> Please note that it may take a couple of minutes from the time of
> >> submission until the htmlized version and diff are available at tools.ietf.org.
> >>

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 May 2017 20:41:23 -0700

> If the saving is beneficial, it'd better to assign a dedicated port number for each UDP payload type( e.g., IP packet), rather than combining the UDP port number dedicated for GUE and the version f…
FWIW, IANA strives to assign one port for a service.

Services are expected to have version fields and subtype demultiplexing
indicators, to so that all message variants of current and future
versions can use a single port number.

Joe

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 20 May 2017 03:57:48 +0000

Hi Joe,

> -----邮件原件-----
> 发件人: Joe Touch [mailto:[email-masked]]
> 发送时间: 2017年5月20日 11:41
> 收件人: Xuxiaohu; Tom Herbert
> 抄送: [email-masked]
> 主题: Re: [Int-area] 答复: Is the UDP destination port number resource running
> out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
> 
> 
> 
> > If the saving is beneficial, it'd better to assign a dedicated port
> > number for each UDP payload type( e.g., IP packet), rather than
> > combining the UDP port number dedicated for GUE and the version field
> > within the GUE header together to indicate whether the UDP payload is
> > GUE or IP (or even other payload type if the GUE is devoted to help
> > save the UDP port number resource for the IETF community:))

Great. Hence IPvx should be taken as a service rather than taking IPvx and GUE as a service, IMO.

> indicators, to so that all message variants of current and future versions can use
> a single port number.

Sure, the version field within the IPvx packet could be used for demultiplexing purpose.

Best regards,
Xiaohu

---

From: Joe Touch <[email-masked]>
Date: Fri, 19 May 2017 21:15:01 -0700

> Great. Hence IPvx should be taken as a service rather than taking IPvx and GUE as a service, IMO.
GUE is supposed to be both signalling and content (data), where the data
are IP packets.

Take away the IP part and GUE isn't an E anymore.
> Sure, the version field within the IPvx packet could be used for demultiplexing purpose.

That demultiplexes within IPvx. There still needs to be a way to
demultiplex non-IPvx packets (control) from IPvx.

Joe

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 20 May 2017 06:09:45 +0000

> 发送时间: 2017年5月20日 12:15
> 主题: Re: 答复: [Int-area] 答复: Is the UDP destination port number resource
> running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
> 
> 
> 
> >> 主题: Re: [Int-area] 答复: Is the UDP destination port number resource
> >> running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
> >>
> >>
> >>
> >>> combining the UDP port number dedicated for GUE and the version
> >>> field within the GUE header together to indicate whether the UDP
> >>> payload is GUE or IP (or even other payload type if the GUE is
> >>> devoted to help save the UDP port number resource for the IETF
> >>> community:))
> GUE is supposed to be both signalling and content (data), where the data are IP
> packets.

Since IANA strives to assign one port for a service, IP packet within the UDP tunnel should be assigned a dedicated port. In other words, GUE and IP-in-UDP are distinguished by the different port numbers. 

> >> Services are expected to have version fields and subtype
> >> demultiplexing indicators, to so that all message variants of current
> >> and future versions can use a single port number.
> That demultiplexes within IPvx. There still needs to be a way to demultiplex
> non-IPvx packets (control) from IPvx.

Since GUE and IP-in-UDP have different UDP port numbers, I don't know why there is still a need to demultiplex GUE and IP-in-UDP.

Xiaohu

---

From: Tom Herbert <[email-masked]>
Date: Sat, 20 May 2017 08:45:47 -0700

> If the saving is beneficial, it'd better to assign a dedicated port number for each UDP payload type( e.g., IP packet), rather than combining the UDP port number dedicated for GUE and the version f…

Xuxiaohu,

We have already implemented the facility to directly encapsulate an IP
protocol directly in UDP. This is FOU-over-UDP (FOU) and in fact
GRE-in-UDP is just one sub case of the implementation. I know people
are using FOU for various protocols in their networks, however I doubt
we get very far if we requested 256 ports to directly encapsulate each
IP protocol! It might make sense to document FOU as informational.

> BTW, what happens if any other GUE payload has the same desire of saving the 4 byte GUE header overhead?

The only other candidate beyond IPv4 and IPv6 that has been suggested
is Ethernet which would be EtherIP. That is pretty feasible to support
if there is enough desire.

> I know that you are trying to specify a generic UDP encapsulation. However, there has been a generic UDP encapsulation scheme that is GRE-in-UDP [RFC8086]. Furthermore, there is another generic UDP…
Yes. The reason we needed to define GUE is that no other encapsulation
protocol satisfies the requirements. GRE comes close, and in fact GUE
is based on GRE. We love GRE for the datacenter. It's generic,
extensible, simple, flag-fields are super efficient, and all hardware
we tested works well with it. The downside of GRE is that it's
extensibility is quite limited; we can only get 12 bytes for fields.
That's just not enough. The particular need we had was to add security
to authenticate the header. We actually we're able to "find" 64 bits
of in the fields by overloading checksum and sequence number, but that
is really not enough for security. Besides that, there are other needs
for extensibility like fragmentation, checksum, payload transform.
We'll only ever need a handful of such extensions, but it's more than
can be fit into GRE. So GUE is an answer. It has the same efficiency
of GRE but is more extensible. Since it is a new protocol we are able
to add a few other nice to have features like header length, encap by
IP protocol, and private data block. Section 6 in the draft gives a
motivation for GUE.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Sat, 20 May 2017 09:00:35 -0700

> Since GUE and IP-in-UDP have different UDP port numbers, I don't know why there is still a need to demultiplex GUE and IP-in-UDP.
It's header compression. Consider a scenario that GUE is tunneling
IPv6 and IPv4 and will do GUE fragmentation if necessary on tunnel
ingress.  So some packets will have a fragmentation option and some
won't. For unfragmented packets with no GUE options, they can be sent
in direct encapsulation of IP. This could be done as version 1 of GUE
or in IP-in-UDP as you're suggesting. The problem with the latter is
that it doubles the number of flows in the network. So instead of
punching one hole for a tunnel in a firewall we need two (the fragment
tunnel and non-fragment UDP ports). Packets in individual flows now
can take different paths depending on whether they're fragmented so
this introduces OOO.

Tom

---

From: Joe Touch <[email-masked]>
Date: Sat, 20 May 2017 16:16:45 -0700

> Since IANA strives to assign one port for a service, IP packet within the UDP tunnel should be assigned a dedicated port. In other words, GUE and IP-in-UDP are distinguished by the different port n…
GUE is one service that includes both encapsulation of IP packets and
signaling.
Frankly, it seems like it would work anywhere IP works - where IPv0 is
defined as the signalling channel (which is sufficient because IPv0
isn't defined).

In that case, the first field after v0 needs to be a signal channel
version number, to allow for future updates.

> Since GUE and IP-in-UDP have different UDP port numbers, 
They don't and they shouldn't. That would complicate forwarding - a
single service needs to use a single port. Using separate ports
complicates configurations - this is a case where you want "fate
sharing" (either both IP encapsulation and the signal channel work or
neither do).

> I don't know why there is still a need to demultiplex GUE and IP-in-UDP.
The point of GUE is an IP encapsulation channel with in-band signalling.
That is a single service, IMO.

Note - AFAICT, GUE could work anywhere an IP packet works. IP packets
always start with a version number, and v0 isn't really defined.
Defining v0 as the signal channel is the same thing as how GUE is
currently specified.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Sat, 20 May 2017 17:08:50 -0700

On Sat, May 20, 2017 at 4:16 PM, Joe Touch <[email-masked]> wrote:
> Since IANA strives to assign one port for a service, IP packet within the
> UDP tunnel should be assigned a dedicated port. In other words, GUE and
> IP-in-UDP are distinguished by the different port numbers.
>
> defined as the signalling channel (which is sufficient because IPv0 isn't
> defined).
>
> In that case, the first field after v0 needs to be a signal channel version
> number, to allow for future updates.
>
>
> Sure, the version field within the IPvx packet could be used for
> demultiplexing
>
> purpose.
>
> They don't and they shouldn't. That would complicate forwarding - a single
> service needs to use a single port. Using separate ports complicates
> configurations - this is a case where you want "fate sharing" (either both
> IP encapsulation and the signal channel work or neither do).
>
> Note - AFAICT, GUE could work anywhere an IP packet works. IP packets always
> start with a version number, and v0 isn't really defined. Defining v0 as the
> signal channel is the same thing as how GUE is currently specified.
>
Joe, I'm not sure I understand your point about IPv0. GUE v0
encapsulates packets of any IP prolocol number (IP, GRE, MPLS,
EtherIP. ...) and allows for data messages as well as control
messages. GUE v1 directly encapsulates IPv4 and IPv6 in a form of
header compression. Where would we use IPv0?

Tom

---

From: Joe Touch <[email-masked]>
Date: Sat, 20 May 2017 17:40:29 -0700

> header compression. Where would we use IPv0?
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

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 23 May 2017 02:49:47 +0000

> 发送时间: 2017年5月21日 0:01
> 抄送: Joe Touch; [email-masked]
> 主题: Re: 答复: 答复: [Int-area] 答复: Is the UDP destination port number
> resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
> 
> >> 主题: Re: 答复: [Int-area] 答复: Is the UDP destination port number
> >> resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
> >>
> >>
> >>
> >> >>> If the saving is beneficial, it'd better to assign a dedicated
> >> >>> port number for each UDP payload type( e.g., IP packet), rather
> >> >>> than combining the UDP port number dedicated for GUE and the
> >> >>> version field within the GUE header together to indicate whether
> >> >>> the UDP payload is GUE or IP (or even other payload type if the
> >> >>> GUE is devoted to help save the UDP port number resource for the
> >> >>> IETF
> >> >>> community:))
> >> > Great. Hence IPvx should be taken as a service rather than taking
> >> > IPvx and
> >> GUE as a service, IMO.
> >> GUE is supposed to be both signalling and content (data), where the
> >> data are IP packets.
> >
> > Since IANA strives to assign one port for a service, IP packet within the UDP
> tunnel should be assigned a dedicated port. In other words, GUE and IP-in-UDP
> are distinguished by the different port numbers.
> >
> >> >> demultiplexing indicators, to so that all message variants of
> >> >> current and future versions can use a single port number.
> > Since GUE and IP-in-UDP have different UDP port numbers, I don't know why
> there is still a need to demultiplex GUE and IP-in-UDP.
> >
> IPv6 and IPv4 and will do GUE fragmentation if necessary on tunnel ingress.
> So some packets will have a fragmentation option and some won't. For
> unfragmented packets with no GUE options, they can be sent in direct
> encapsulation of IP. This could be done as version 1 of GUE or in IP-in-UDP as
> you're suggesting. The problem with the latter is that it doubles the number of
> flows in the network. So instead of punching one hole for a tunnel in a firewall
> we need two (the fragment tunnel and non-fragment UDP ports). Packets in
> individual flows now can take different paths depending on whether they're
> fragmented so this introduces OOO.

Since GUE is intended to be a generic UDP encapsulation, now let's assume GUE is tunneling MPLS, NSH or BIER. Please continue your rationale once those encapsulations have the same requirement of saving the 4-byte GUE base header overhead as the encapsulation of IP in UDP.

Best regards,
Xiaohu

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 23 May 2017 03:22:33 +0000

Hi Tom, 

> 发送时间: 2017年5月20日 23:46
> 主题: Re: 答复: [Int-area] Is the UDP destination port number resource running
> >> I'm not sure everyone would agree with that. The case was made when
> >> we were discussing it that the savings would be beneficial for some
> deployments.
> >
> We have already implemented the facility to directly encapsulate an IP protocol
> directly in UDP. This is FOU-over-UDP (FOU) and in fact GRE-in-UDP is just one
> sub case of the implementation. I know people are using FOU for various
> protocols in their networks, however I doubt we get very far if we requested
> 256 ports to directly encapsulate each IP protocol! It might make sense to
> document FOU as informational.

There had been a Foo-over-UDP draft (see https://tools.ietf.org/html/draft-yong-tsvwg-udp-encap-4-ip-tunneling-01). However, the reality is that different Foo's are specified in dedicated drafts since many foo-specific considerations need to be specified.

> The only other candidate beyond IPv4 and IPv6 that has been suggested is
> Ethernet which would be EtherIP. That is pretty feasible to support if there is
> enough desire.

Could you explain how to support the encapsulation of Ethernet without the 4-octect overhead? By the way, why Ethernet is the only other candidate since GUE is claimed to be generic?

> >
> >> > However, the premise is that it's meaningful for the IETF to
> >> > develop such a GENERIC and COVERALL encapsulation method which is
> >> > still looking for nails:)
> >>
> > I know that you are trying to specify a generic UDP encapsulation. However,
> there has been a generic UDP encapsulation scheme that is GRE-in-UDP
> [RFC8086]. Furthermore, there is another generic UDP encapsulation scheme
> called GENEVE that the NVO3 group is working on. It's better for the IETF
> community to avoid specifying multiple similar encapsulation schemes and
> therefore the NVo3 WG co-chairs and the corresponding AD try their best to
> reach a consensus of working together on a single encapsulation on the basis of
> GENEVE among the WG members. Do you still believe it's helpful for the
> industry to specify one additional generic encapsulation scheme in another IETF
> WG?
> >
> protocol satisfies the requirements. GRE comes close, and in fact GUE is based
> on GRE. We love GRE for the datacenter. It's generic, extensible, simple,
> flag-fields are super efficient, and all hardware we tested works well with it. The
> downside of GRE is that it's extensibility is quite limited; we can only get 12
> bytes for fields.
> That's just not enough. The particular need we had was to add security to
> authenticate the header. We actually we're able to "find" 64 bits of in the fields
> by overloading checksum and sequence number, but that is really not enough
> for security. Besides that, there are other needs for extensibility like
> fragmentation, checksum, payload transform.
> We'll only ever need a handful of such extensions, but it's more than can be fit
> into GRE. So GUE is an answer. It has the same efficiency of GRE but is more
> extensible. Since it is a new protocol we are able to add a few other nice to have
> features like header length, encap by IP protocol, and private data block. Section
> 6 in the draft gives a motivation for GUE.

If GRE-in-UDP is not enough, what about GENEVE? (cced to NVO3)

Best regards,
Xiaohu

---

From: Tom Herbert <[email-masked]>
Date: Thu, 25 May 2017 09:00:17 -0700

> Since GUE is intended to be a generic UDP encapsulation, now let's assume GUE is tunneling MPLS, NSH or BIER. Please continue your rationale once those encapsulations have the same requirement of s…
Xiaohu,

GUE encapsulates by IP protocol, I don't believe there is a protocol
number for NSH or BIER so they should not be encapsulated in version
1. There is a protocol number for MPLS-IP, however there is no fixed
field in the MPLS header (like the IP version) so the overlay
technique can't work. Furthermore, these three protocols are already
encapsulations, the optimization makes the most sense for simple
network protocols that are not encapsulations.

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.

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.

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 May 2017 10:44:28 -0700

Hi, Tom,

> make it a valid EtherIP header and then the packet is resubmitted to
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.

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

Joe

---

From: Tom Herbert <[email-masked]>
Date: Thu, 25 May 2017 11:27:01 -0700

> MPLS, Ethernet, etc.), as long as you burn at least those 4 bits.

Right, although even with 00 for version zero there's still enough for
ten other codes which is a lot.

> That works the same way as EtherIP - burn at least 4 bits indicating the

EtherIP begins with a fixed version number, for the transport
protocols we would be overwriting the source port with no way to
recover the bits.

>     0101 (IPv5) = direct encapsulation of IPv5 (ST), with no interveni
> GUE header
Right, this scheme could work to generally encapsulate different IP
versions. There is a caveat though: AFAIK there is no IP protocol
number to encapsulate any IP protocols other then IPv4 (IPIP 94) and
IPv6 (IPv6 encapsulates 41). GUE encapsulates IP protocols which means
they need a protocol number. Version 1 is header compression for
version 0 so the there must be a way to encapsulate the protocol using
version 0. What would resolve that is a new IP protocol number for
encapsulating a packet of any IP version and use the IP version itself
to differentiate.

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 May 2017 11:33:49 -0700

> ten other codes which is a lot.

Yes, but there's very little benefit in looking at 2 bits vs 4. That
would matter only for serial processing and saves far too little to be
worthwhile IMO. It also complicates the way the protocol is described (I
personally find it confusing; it's a lot more obvious to just say that
you use IPv0 for control, IPv1 for encapsulation, and other IP versions
are included without overriding headers).

> protocols we would be overwriting the source port with no way to
You can't put bare Ethernet inside GUE. You need to use EtherIP -
exactly because it has a 16-bit field, of which only the first 4 bits
are (already) defined.

My point is that EtherIP burns 16 bits vs bare Ethernet, but those 16
bits allow it to be mapped to one of the IP versions (you picked IPv5).
The same trick works for UDP and TCP - just pick a different 16 bit
pattern for each one.

The catch is that EtherIP and these corresponding tricks for UDP and TCP
end up burning 16 bits more than the bare packet would, but that's still
less than the GUE encapsulation header burns.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Thu, 25 May 2017 11:47:54 -0700

> The same trick works for UDP and TCP - just pick a different 16 bit
Inserting two bytes before the TCP header breaks four byte alignment
of the header which is a bigger hit than the benefit of saving two
bytes. A nice side effect of the two byte header in EtherIP is that it
aligns the Ethernet payload (e.g. an IP header) to four bytes.
Maintaining this four byte alignment is still important to some CPU
architectures most notably Sparc, but can even be problematic to x86
under certain circumstances.

Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 May 2017 12:07:43 -0700

> under certain circumstances.
Sure - I'm not sure the 4-byte penalty is worth avoiding any nearly any
case, frankly -- even for IP.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 May 2017 12:13:54 -0700

FWIW, my general concern with this service is that lacks a version
identifier, and cannot be extended to support such an identifier for
bare IP packets as payloads, as encouraged by RFC7605 Section 7.5

At a minimum, one of the first fields after the "Version 0" format
identifier (a name which is confusing, for this reason) needs to be a
version field, so that future variants of this service will not need a
new port assignment.

Joe

On 5/25/2017 12:07 PM, Joe Touch wrote:
> Sure - I'm not sure the 4-byte penalty is worth avoiding any nearly
> any case, frankly -- even for IP.
>
> Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 May 2017 19:44:17 +0000

If you are talking about the GUE direct encapsulation of IPv4 and IPv6, I agree
with the current spec and that direct encapsulation (i.e., with no additional
encapsulations between the IP/UDP and inner IP headers) is desirable and
should remain as part of the spec. I think we may be over-thinking this.

Fred

From: Int-area [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: Thursday, May 25, 2017 12:08 PM
To: Tom Herbert <[email-masked]>
Cc: [email-masked]
Subject: Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt

are (already) defined.

pattern for each one.

Tom
Sure - I'm not sure the 4-byte penalty is worth avoiding any nearly any case, frankly -- even for IP.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Thu, 25 May 2017 13:40:28 -0700

> should remain as part of the spec. I think we may be over-thinking this.
+1. I think a little too much has been inferred beyond the what is
actually in draft. Versions are straightforward:

- There is a two bit version number field that begins GUE header. The
format of the rest of the header depends on the version.
- Version 0 defines an encapsulation header that encapsulates by IP
protocol number.
- Version 1 defined a means for direct encapsulation of select
protocols as an optimization. Formats for IPv4 and IPv6 are defined.
- Version 2 and 3 are reserved

Rather Version 1 constitutes a new version or a different format seems
to be a matter of terminology, however semantically and implementation
wise the intent is clear. If it's necessary the field could be renamed
"version/format"

Tom

> Subject: Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destination port number

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 May 2017 15:14:25 -0700

> - Version 2 and 3 are reserved
I continue to be confused as to why it is more useful to try to make
decisions based on the first two bits rather than the first four.
There's near zero benefit, and the harm is that you end up with only two
reserved versions.

> wise the intent is clear. If it's necessary the field could be renamed
It is not a version; I think that's at least part of the problem. It's a
type or kind, but version implies that V0 is superceded by V1, which may
or may not be backward compatible with V0.

Joe

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 May 2017 22:21:48 +0000

Joe,

I am for whatever allows us to do direct encapsulation (i.e., IP/UDP/IP with NULL GUE header)
in the simplest way possible. I'm not too concerned with future-proofing it; is that what you
are worried about?

Thanks - Fred

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]]
> Sent: Thursday, May 25, 2017 3:14 PM
> To: Tom Herbert <[email-masked]>; Templin, Fred L <[email-masked]>
> Cc: [email-masked]

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 26 May 2017 01:36:33 +0000

Tom,

> 发送时间: 2017年5月26日 0:00
> 主题: Re: 答复: 答复: 答复: [Int-area] 答复: Is the UDP destination port
> number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
> 
> >> >> >> 主题: Re: [Int-area] 答复: Is the UDP destination port number
> >> >> >>> port number for each UDP payload type( e.g., IP packet),
> >> >> >>> rather than combining the UDP port number dedicated for GUE
> >> >> >>> and the version field within the GUE header together to
> >> >> >>> indicate whether the UDP payload is GUE or IP (or even other
> >> >> >>> payload type if the GUE is devoted to help save the UDP port
> >> >> >>> number resource for the IETF
> >> >> >>> community:))
> >> >> > Great. Hence IPvx should be taken as a service rather than
> >> >> > taking IPvx and
> >> >> GUE as a service, IMO.
> >> >> GUE is supposed to be both signalling and content (data), where
> >> >> the data are IP packets.
> >> >
> >> tunnel should be assigned a dedicated port. In other words, GUE and
> >> encapsulation of IP. This could be done as version 1 of GUE or in
> >> IP-in-UDP as you're suggesting. The problem with the latter is that
> >> it doubles the number of flows in the network. So instead of punching
> >> one hole for a tunnel in a firewall we need two (the fragment tunnel
> >> and non-fragment UDP ports). Packets in individual flows now can take
> >> different paths depending on whether they're fragmented so this introduces
> OOO.
> >
> > Since GUE is intended to be a generic UDP encapsulation, now let's assume
> GUE is tunneling MPLS, NSH or BIER. Please continue your rationale once those
> encapsulations have the same requirement of saving the 4-byte GUE base
> header overhead as the encapsulation of IP in UDP.
> >
> Xiaohu,
> 
> GUE encapsulates by IP protocol, I don't believe there is a protocol number for
> NSH or BIER so they should not be encapsulated in version 1. There is a protocol
> number for MPLS-IP, however there is no fixed field in the MPLS header (like the
> IP version) so the overlay technique can't work. Furthermore, these three
> protocols are already encapsulations, the optimization makes the most sense for
> simple network protocols that are not encapsulations.

If so, it seems a little bit confused to claim it as a generic udp encapsulation.

> IPv4 and IPv6 can be directly encapsulated since they have a protocol number
> (can be encapsulated by version 0).

If the possible payload types of GUE are limited to IPv4, IPv6 and MPLS, and these payloads need to be directly transported over UDP, the most simple way is to allocate a dedicated port number for IP since MPLS has already be assigned one (RFC7510), IMHO.

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

To save the 4-byte GUE base header overhead when encapsulating Ethernet over UDP, you propose to insert the additional 16-bit EtherIP header between the UDP header and MAC frame?

Xiaohu

> 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.
> 
> Tom
> 
> > Best regards,
> > Xiaohu
> >
> >> Tom
> >>
> >> > Xiaohu
> >> >
> >> >> Joe

---

From: Tom Herbert <[email-masked]>
Date: Thu, 25 May 2017 18:49:58 -0700

> There's near zero benefit, and the harm is that you end up with only two
If necessary, new version could be defined to be fours bits versions
like version 1 so that gives thirteen possible versions (00 01xx 10xx
11xx) of which three have been defined. v0 is already quite extensible
and generic so I don't see it will be obsoleted any time in the
foreseeable future. Personally, I don't think rearranging the GUE
header is needed at this point.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Thu, 25 May 2017 18:52:23 -0700

> To save the 4-byte GUE base header overhead when encapsulating Ethernet over UDP, you propose to insert the additional 16-bit EtherIP header between the UDP header and MAC frame?

That is already part of EtherIP (RFC3378).

Tom

---

From: Joe Touch <[email-masked]>
Date: Fri, 26 May 2017 07:57:59 -0700

> in the simplest way possible. I'm not too concerned with future-proofing it; is that what you
Yes, but I've made my position clear. If this is believed by others to
be sufficiently addressed, that's fine.
Joe