< draft-ietf-intarea-gue-06.txt | draft-ietf-intarea-gue-06cepC.txt > | |||
---|---|---|---|---|
skipping to change at page 1, line 48 ¶ | skipping to change at page 1, line 48 ¶ | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. | to this document. | |||
<!-- CEP: duplicate boilerplate!! --> | ||||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Abstract | Abstract | |||
This specification describes Generic UDP Encapsulation (GUE), which | This specification describes Generic UDP Encapsulation (GUE), which | |||
is a scheme for using UDP to encapsulate packets of different IP | uses UDP to encapsulate packets of various Internet | |||
protocols for transport across layer 3 networks. By encapsulating | protocols for transport across layer 3 networks. By encapsulating | |||
packets in UDP, specialized capabilities in networking hardware for | packets in UDP, specialized capabilities in networking hardware for | |||
efficient handling of UDP packets can be leveraged. GUE specifies | efficient handling of UDP packets can be used. GUE provides | |||
basic encapsulation methods upon which higher level constructs, such | basic encapsulation methods suitable for higher level constructs, such | |||
as tunnels and overlay networks for network virtualization, can be | as tunnels and overlay networks for network virtualization. | |||
constructed. GUE is extensible by allowing optional data fields as | GUE provides extensibility by allowing optional data fields within | |||
part of the encapsulation, and is generic in that it can encapsulate | the encapsulation, and is generic in that it can encapsulate | |||
packets of various IP protocols. | packets of various Internet protocols. | |||
<!-- CEP: This means GUE is "flexible", not "generic". Oh well. --> | ||||
<!-- CEP: "generic" would mean that GUE offers a vanilla solution | ||||
relevant to other encapsulation protocols. --> | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
1.1. Terminology and acronyms . . . . . . . . . . . . . . . . . 5 | 1.1. Terminology and acronyms . . . . . . . . . . . . . . . . . 5 | |||
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 | 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 | |||
2. Base packet format . . . . . . . . . . . . . . . . . . . . . . 7 | 2. Base packet format . . . . . . . . . . . . . . . . . . . . . . 7 | |||
2.1. GUE variant . . . . . . . . . . . . . . . . . . . . . . . . 7 | 2.1. GUE variant . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3. Variant 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 3. Variant 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.1. Header format . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.1. Header format . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
skipping to change at page 4, line 34 ¶ | skipping to change at page 4, line 34 ¶ | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 30 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 | |||
Appendix A: NIC processing for GUE . . . . . . . . . . . . . . . . 33 | Appendix A: NIC processing for GUE . . . . . . . . . . . . . . . . 33 | |||
A.1. Receive multi-queue . . . . . . . . . . . . . . . . . . . . 33 | A.1. Receive multi-queue . . . . . . . . . . . . . . . . . . . . 33 | |||
A.2. Checksum offload . . . . . . . . . . . . . . . . . . . . . 34 | A.2. Checksum offload . . . . . . . . . . . . . . . . . . . . . 34 | |||
A.2.1. Transmit checksum offload . . . . . . . . . . . . . . . 34 | A.2.1. Transmit checksum offload . . . . . . . . . . . . . . . 34 | |||
A.2.2. Receive checksum offload . . . . . . . . . . . . . . . 35 | A.2.2. Receive checksum offload . . . . . . . . . . . . . . . 35 | |||
A.3. Transmit Segmentation Offload . . . . . . . . . . . . . . . 35 | A.3. Transmit Segmentation Offload . . . . . . . . . . . . . . . 35 | |||
A.4. Large Receive Offload . . . . . . . . . . . . . . . . . . . 36 | A.4. Large Receive Offload . . . . . . . . . . . . . . . . . . . 36 | |||
Appendix B: Implementation considerations . . . . . . . . . . . . 36 | Appendix B: Implementation considerations . . . . . . . . . . . . 36 | |||
B.1. Priveleged ports . . . . . . . . . . . . . . . . . . . . . 37 | B.1. Privileged ports . . . . . . . . . . . . . . . . . . . . . 37 | |||
B.2. Setting flow entropy as a route selector . . . . . . . . . 37 | B.2. Setting flow entropy as a route selector . . . . . . . . . 37 | |||
B.3. Hardware protocol implementation considerations . . . . . . 37 | B.3. Hardware protocol implementation considerations . . . . . . 37 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
1. Introduction | 1. Introduction | |||
This specification describes Generic UDP Encapsulation (GUE) which is | This specification describes Generic UDP Encapsulation (GUE) which is | |||
a general method for encapsulating packets of arbitrary IP protocols | a general method for encapsulating packets of arbitrary IP protocols | |||
within User Datagram Protocol (UDP) [RFC0768] packets. Encapsulating | within User Datagram Protocol (UDP) [RFC0768] packets. Encapsulating | |||
packets in UDP facilitates efficient transport across networks. | packets in UDP facilitates efficient transport across networks. | |||
Networking devices widely provide protocol specific processing and | Networking devices often provide protocol specific processing and | |||
optimizations for UDP (as well as TCP) packets. Packets for atypical | optimizations for UDP packets. Packets for | |||
IP protocols (those not usually parsed by networking hardware) can be | IP protocols not typically parsed by networking hardware can be | |||
encapsulated in UDP packets to maximize deliverability and to | encapsulated in UDP packets to maximize deliverability and to | |||
leverage flow specific mechanisms for routing and packet steering. | engage flow specific mechanisms for routing and packet steering. | |||
GUE provides an extensible header format for including optional data | GUE provides an extensible header format for including optional data | |||
in the encapsulation header. This data potentially covers items such | in the encapsulation header. This data can cover items such | |||
as the virtual networking identifier, security data for validating or | as the virtual networking identifier, security data for validating or | |||
authenticating the GUE header, congestion control data, etc. GUE also | authenticating the GUE header, congestion control data, etc. | |||
<!-- CEP: citations needed. Plus I am surprised yet another | ||||
validation mechanism is needed! --> | ||||
GUE also | ||||
allows private optional data in the encapsulation header. This | allows private optional data in the encapsulation header. This | |||
feature can be used by a site or implementation to define local | feature can be used by a site or implementation to define local | |||
custom optional data, and allows experimentation of options that may | custom optional data, and allows experimentation of options that may | |||
eventually become standard. | eventually become standard. | |||
This document does not define any specific GUE extensions. [GUEEXTEN] | This document does not define any specific GUE extensions. [GUEEXTEN] | |||
specifies a set of initial extensions. | specifies a set of initial extensions. | |||
The motivation for the GUE protocol is described in section 6. | The motivation for the GUE protocol is described in section 6. | |||
1.1. Terminology and acronyms | 1.1. Terminology and acronyms | |||
<!-- CEP: Need terminology for "connection semantics". --> | ||||
<!-- CEP: Need terminology for "flow entropy". --> | ||||
<!-- CEP: Need terminology for "Canonical length". --> | ||||
GUE Generic UDP Encapsulation | GUE Generic UDP Encapsulation | |||
GUE Header A variable length protocol header that is composed | GUE Header A variable length protocol header that is composed | |||
of a primary four byte header and zero or more four | of a primary four byte header and zero or more four | |||
byte words for optional header data | byte words for optional header data | |||
GUE packet A UDP/IP packet that contains a GUE header and GUE | GUE packet A UDP/IP packet that contains a GUE header and GUE | |||
payload within the UDP payload | payload within the UDP payload | |||
GUE variant A version of the GUE protocol or an alternate form | GUE variant A version of the GUE protocol or an alternate form | |||
skipping to change at page 7, line 15 ¶ | skipping to change at page 7, line 15 ¶ | |||
2. Base packet format | 2. Base packet format | |||
A GUE packet is comprised of a UDP packet whose payload is a GUE | A GUE packet is comprised of a UDP packet whose payload is a GUE | |||
header followed by a payload which is either an encapsulated packet | header followed by a payload which is either an encapsulated packet | |||
of some IP protocol or a control message such as an OAM (Operations, | of some IP protocol or a control message such as an OAM (Operations, | |||
Administration, and Management) message. A GUE packet has the general | Administration, and Management) message. A GUE packet has the general | |||
format: | format: | |||
+-------------------------------+ | +-------------------------------+ | |||
| | | | | | |||
| UDP/IP header | | | UDP/IP headers | | |||
| | | | | | |||
|-------------------------------| | |-------------------------------| | |||
| | | | | | |||
| GUE Header | | | GUE Header | | |||
| | | | | | |||
|-------------------------------| | |-------------------------------| | |||
| | | | | | |||
| Encapsulated packet | | | Encapsulated packet | | |||
| or control message | | | or control message | | |||
| | | | | | |||
+-------------------------------+ | +-------------------------------+ | |||
<!-- CEP: This representation seems upside down compared to normal. | ||||
Maybe even horizontal would be better... --> | ||||
The GUE header is variable length as determined by the presence of | The GUE header has variable length, as determined by the presence of | |||
optional extension fields. | optional extension fields. | |||
2.1. GUE variant | 2.1. GUE variant | |||
The first two bits of the GUE header contain the GUE protocol variant | The first two bits of the GUE header contain the GUE protocol variant | |||
number. The variant number can indicate the version of the GUE | number. The variant number can indicate the version of the GUE | |||
protocol as well as alternate forms of a version. | protocol as well as alternate forms of a version. | |||
Variants 0 and 1 are described in this specification; variants 2 and | Variants 0 and 1 are described in this specification; variants 2 and | |||
3 are reserved. | 3 are reserved. | |||
3. Variant 0 | 3. Variant 0 | |||
Variant 0 indicates version 0 of GUE. This variant defines a generic | Variant 0 indicates version 0 of GUE, and defines a generic | |||
extensible format to encapsulate packets by Internet protocol number. | extensible format to encapsulate packets by Internet protocol number. | |||
3.1. Header format | 3.1. Header format | |||
The header format for variant 0 of GUE in UDP is: | The header format for variant 0 of GUE in UDP is: | |||
<!-- CEP: Is it possible to have a GUE *not* in UDP? | ||||
If not, then the wording above is curious... --> | ||||
0 1 2 3 | 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 | 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 | | | | Source port | Destination port | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP | |||
| Length | Checksum | | | | Length | Checksum | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | |||
| 0 |C| Hlen | Proto/ctype | Flags | | | 0 |C| Hlen | Proto/ctype | Flags | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
skipping to change at page 8, line 45 ¶ | skipping to change at page 8, line 47 ¶ | |||
to an encapsulation, this is set to the local source port for | to an encapsulation, this is set to the local source port for | |||
the connection. When connection semantics are not applied, the | the connection. When connection semantics are not applied, the | |||
source port is either set to a flow entropy value as described | source port is either set to a flow entropy value as described | |||
in section 5.11, or it should be set to the GUE assigned port | in section 5.11, or it should be set to the GUE assigned port | |||
number, 6080. | number, 6080. | |||
o Destination port: If connection semantics (section 5.6.1) are | o Destination port: If connection semantics (section 5.6.1) are | |||
applied to an encapsulation, this is set to the destination port | applied to an encapsulation, this is set to the destination port | |||
for the tuple. If connection semantics are not applied this is | for the tuple. If connection semantics are not applied this is | |||
set to the GUE assigned port number, 6080. | set to the GUE assigned port number, 6080. | |||
<!-- CEP: Why not always use the former? --> | ||||
o Length: Canonical length of the UDP packet (length of UDP header | o Length: Canonical length of the UDP packet (length of UDP header | |||
and payload). | and payload). | |||
o Checksum: Standard UDP checksum (handling is described in | o Checksum: Standard UDP checksum (handling is described in | |||
section 5.7). | section 5.7). | |||
The GUE header consists of: | The GUE header consists of: | |||
o Variant: 0 indicates GUE protocol version 0 with a header. | o Variant: 0 indicates GUE protocol version 0 with a header. | |||
o C: C-bit: When set indicates a control message, not set | o C: C-bit: When set indicates a control message, not set | |||
indicates a data message. | indicates a data message. | |||
o Hlen: Length in 32-bit words of the GUE header, including | o Hlen: Length in 4-byte words of the GUE header, including | |||
optional extension fields but not the first four bytes of the | optional extension fields but not the first four bytes of the | |||
header. Computed as (header_len - 4) / 4, where header_len is | header. Computed as (header_len - 4) / 4, where header_len is | |||
the total header length in bytes. All GUE headers are a multiple | the total header length in bytes. All GUE headers are a multiple | |||
of four bytes in length. Maximum header length is 128 bytes. | of four bytes in length. Maximum header length is 128 bytes. | |||
o Proto/ctype: When the C-bit is set, this field contains a | o Proto/ctype: When the C-bit is set, this field contains a | |||
control message type for the payload (section 3.2.2). When the | control message type for the payload (section 3.2.2). When the | |||
C-bit is not set, the field holds the Internet protocol number | C-bit is not set, the field holds the Internet protocol number | |||
for the encapsulated packet in the payload (section 3.2.1). The | for the encapsulated packet in the payload (section 3.2.1). The | |||
control message or encapsulated packet begins at the offset | control message or encapsulated packet begins at the offset | |||
provided by Hlen. | provided by Hlen. | |||
o Flags: Header flags that may be allocated for various purposes | o Flags: Header flags that may be allocated for various purposes | |||
and may indicate presence of extension fields. Undefined header | and may indicate presence of extension fields. Undefined header | |||
flag bits MUST be set to zero on transmission. | flag bits MUST be set to zero on transmission. | |||
o Extension Fields: Optional fields whose presence is indicated by | o Extension Fields: Optional fields whose presence is indicated by | |||
corresponding flags. | corresponding flags. | |||
o Private data: Optional private data block (see section 3.4). If | o Private data: Optional private data block (see section 3.4). If | |||
the private block is present, it immediately follows that last | the private block is present, it immediately follows the last | |||
extension field present in the header. The private block is | extension field present in the header. The private block is | |||
considered to be part of the GUE header. The length of this data | considered to be part of the GUE header. The length of this data | |||
is determined by subtracting the starting offset from the header | is determined by subtracting the starting offset from the header | |||
length. | length. | |||
<!-- CEP: not clear why it's better to be part of the GUE header, than | ||||
another kind of extension field. --> | ||||
3.2. Proto/ctype field | 3.2. Proto/ctype field | |||
The proto/ctype fields either contains an Internet protocol number | The proto/ctype fields either contains an Internet protocol number | |||
(when the C-bit is not set) or GUE control message type (when the C- | (when the C-bit is not set) or GUE control message type (when the C- | |||
bit is set). | bit is set). | |||
3.2.1 Proto field | 3.2.1 Proto field | |||
When the C-bit is not set, the proto/ctype field MUST contain an IANA | When the C-bit is not set, the proto/ctype field MUST contain an IANA | |||
Internet Protocol Number. The protocol number is interpreted relative | Internet Protocol Number. The protocol number is interpreted relative | |||
to the IP protocol that encapsulates the UDP packet (i.e. protocol of | to the IP protocol that encapsulates the UDP packet (i.e. protocol of | |||
the outer IP header). The protocol number serves as an indication of | the outer IP header). | |||
<!-- CEP: Presumably this means IPv4 or IPv6, but it's the same for | ||||
either of those. --> | ||||
The protocol number indicates | ||||
the type of the next protocol header which is contained in the GUE | the type of the next protocol header which is contained in the GUE | |||
payload at the offset indicated in Hlen. Intermediate devices MAY | payload at the offset indicated in Hlen. Intermediate devices MAY | |||
parse the GUE payload per the number in the proto/ctype field, and | parse the GUE payload per the number in the proto/ctype field, and | |||
header flags cannot affect the interpretation of the proto/ctype | header flags MUST NOT affect the interpretation of the proto/ctype | |||
field. | field. | |||
<!-- CEP: There are three possibilities below. They should be itemized. --> | ||||
When the outer IP protocol is IPv4, the proto field MUST be set to a | When the outer IP protocol is IPv4, the proto field MUST be set to a | |||
valid IP protocol number usable with IPv4; it MUST NOT be set to a | valid IP protocol number usable with IPv4. An | |||
number for IPv6 extension headers or ICMPv6 options (number 58). An | ||||
exception is that the destination options extension header using the | exception is that the destination options extension header using the | |||
PadN option MAY be used with IPv4 as described in section 3.6. The | PadN option MAY be used with IPv4 as described in section 3.6. The | |||
"no next header" protocol number (59) also MAY be used with IPv4 as | "no next header" protocol number (59) also MAY be used with IPv4 as | |||
described below. | described below. | |||
<!-- CEP: should cite the website for IP protocol numbers: | ||||
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml | ||||
--> | ||||
When the outer IP protocol is IPv6, the proto field can be set to any | When the outer IP protocol is IPv6, the proto field can be set to any | |||
defined protocol number except that it MUST NOT be set to Hop-by-hop | defined protocol number except that it MUST NOT be set to Hop-by-hop | |||
options (number 0). If a received GUE packet in IPv6 contains a | options (number 0). | |||
<!-- CEP: Please explain the rationale for this restriction. --> | ||||
If a received GUE packet in IPv6 contains a | ||||
protocol number that is an extension header (e.g. Destination | protocol number that is an extension header (e.g. Destination | |||
Options) then the extension header is processed after the GUE header | Options) then the extension header is processed after the GUE header | |||
is processed as though the GUE header is an extension header. | is processed as though the GUE header is an extension header. | |||
IP protocol number 59 ("No next header") can be set to indicate that | IP protocol number 59 ("No next header") can be set to indicate that | |||
the GUE payload does not begin with the header of an IP protocol. | the GUE payload does not begin with the header of an IP protocol. | |||
This would be the case, for instance, if the GUE payload were a | This would be the case, for instance, if the GUE payload were a | |||
fragment when performing GUE level fragmentation. The interpretation | fragment when performing GUE level fragmentation. The interpretation | |||
of the payload is performed through other means (such as flags and | of the payload is performed through other means (such as flags and | |||
extension fields), and intermediate devices MUST NOT parse packets | extension fields), and intermediate devices MUST NOT parse packets | |||
based on the IP protocol number in this case. | based on the IP protocol number in this case. | |||
<!-- CEP: This cannot be enforced. --> | ||||
3.2.2 Ctype field | 3.2.2 Ctype field | |||
When the C-bit is set, the proto/ctype field MUST be set to a valid | When the C-bit is set, the proto/ctype field MUST be set to a valid | |||
control message type. A value of zero indicates that the GUE payload | control message type. A value of zero indicates that the GUE payload | |||
requires further interpretation to deduce the control type. This | requires further interpretation to deduce the control type. This | |||
might be the case when the payload is a fragment of a control | might be the case when the payload is a fragment of a control | |||
message, where only the reassembled packet can be interpreted as a | message, where only the reassembled packet can be interpreted as a | |||
control message. | control message. | |||
Control messages will be defined in an IANA registry. Control message | Control messages are defined in an IANA registry. Control message | |||
types 1 through 127 may be defined in standards. Types 128 through | types 1 through 127 may be defined in standards. Types 128 through | |||
255 are reserved to be user defined for experimentation or private | 255 are reserved to be user defined for experimentation or private | |||
control messages. | control messages. | |||
<!-- CEP: For types 1 --> 127, need to specify how to allocate. | ||||
Why not mandate standards action? --> | ||||
This document does not specify any standard control message types | This document does not specify any standard control message types | |||
other than type 0. Type 0 does not define a format of the control | other than type 0. Type 0 does not define a format of the control | |||
message. Instead, it indicates that the GUE payload is a control | message. Instead, it indicates that the GUE payload is a control | |||
message, or part of a control message (as might be the case in GUE | message, or part of a control message (as might be the case in GUE | |||
fragmentation), that cannot be correctly parsed or interpreted | fragmentation), that cannot be correctly parsed or interpreted | |||
without additional context. | without additional context. | |||
<!-- CEP: The latter needs an example. The former seems to follow | ||||
from network mishandling of IPv6 fragmentation. --> | ||||
3.3. Flags and extension fields | 3.3. Flags and extension fields | |||
Flags and associated extension fields are the primary mechanism of | Flags and associated extension fields are the primary mechanism of | |||
extensibility in GUE. As mentioned in section 3.1, GUE header flags | extensibility in GUE. As mentioned in section 3.1, GUE header flags | |||
indicate the presence of optional extension fields in the GUE header. | indicate the presence of optional extension fields in the GUE header. | |||
[GUEXTENS] defines an initial set of GUE extensions. | [GUEEXTENS] defines an initial set of GUE extensions. | |||
3.3.1. Requirements | 3.3.1. Requirements | |||
There are sixteen flag bits in the GUE header. Flags may indicate | There are sixteen flag bits in the GUE header. Flags may indicate | |||
presence of an extension fields. The size of an extension field | presence of an extension fields. The size of an extension field | |||
indicated by a flag MUST be fixed. | indicated by a flag MUST be a fixed constant. | |||
<!-- CEP: "paired" means 2. Need another term. Perhaps "combined". --> | ||||
Flags can be paired together to allow different lengths for an | Flags can be paired together to allow different lengths for an | |||
extension field. For example, if two flag bits are paired, a field | extension field. For example, if two flag bits are paired, a field | |||
can possibly be three different lengths-- that is bit value of 00 | can possibly be three different lengths-- that is bit value of 00 | |||
indicates no field present; 01, 10, and 11 indicate three possible | indicates no field present; 01, 10, and 11 indicate three possible | |||
lengths for the field. Regardless of how flag bits are paired, the | lengths for the field. Regardless of how flag bits are paired, the | |||
lengths and offsets of optional fields corresponding to a set of | lengths and offsets of optional fields corresponding to a set of | |||
flags MUST be well defined. | flags MUST be well defined. | |||
Extension fields are placed in order of the flags. New flags are to | Extension fields are placed in order of the flags. New flags are to | |||
be allocated from high to low order bit contiguously without holes. | be allocated from high to low order bit contiguously without holes. | |||
Flags allow random access, for instance to inspect the field | Flags allow random access, for instance to inspect the field | |||
corresponding to the Nth flag bit, an implementation only considers | corresponding to the Nth flag bit, an implementation only considers | |||
the previous N-1 flags to determine the offset. Flags after the Nth | the previous N-1 flags to determine the offset. Flags after the Nth | |||
flag are not pertinent in calculating the offset of the field for the | flag are not pertinent in calculating the offset of the field for the | |||
Nth flag. Random access of flags and fields permits processing of | Nth flag. Random access of flags and fields permits processing of | |||
optional extensions in an order that is independent of their position | optional extensions in an order that does not depend on their position | |||
in the packet. | in the packet. | |||
Flags (or paired flags) are idempotent such that new flags MUST NOT | Flags (or paired flags) are idempotent such that new flags MUST NOT | |||
<!-- CEP: This is not what "idempotent" means. --> | ||||
cause reinterpretation of old flags. Also, new flags MUST NOT alter | cause reinterpretation of old flags. Also, new flags MUST NOT alter | |||
interpretation of other elements in the GUE header nor how the | interpretation of other elements in the GUE header nor how the | |||
message is parsed (for instance, in a data message the proto/ctype | message is parsed (for instance, in a data message the proto/ctype | |||
field always holds an IP protocol number as an invariant). | field always holds an IP protocol number as an invariant). | |||
The set of available flags can be extended in the future by defining | The set of available flags can be extended in the future by defining | |||
a "flag extensions bit" that refers to a field containing a new set | a "flag extensions bit" that refers to a field containing a new set | |||
of flags. | of flags. | |||
<!-- CEP: The extension bit should be specified in this document. --> | ||||
3.3.2. Example GUE header with extension fields | 3.3.2. Example GUE header with extension fields | |||
An example GUE header for a data message encapsulating an IPv4 packet | An example GUE header for a data message encapsulating an IPv4 packet | |||
and containing the Group Identifier and Security extension fields | and containing the Group Identifier and Security extension fields | |||
(both defined in [GUEXTENS]) is shown below: | (both defined in [GUEEXTENS]) is shown below: | |||
0 1 2 3 | 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 | 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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| 0 |0| 3 | 94 |1|0 0 1| 0 | | | 0 |0| 3 | 94 |1|0 0 1| 0 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Group Identifier | | | Group Identifier | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | | | | | |||
+ Security + | + Security + | |||
| | | | | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
<!-- CEP: The 'C' bit should be a 1, right? Otherwise the 94 | ||||
has to be an IPv6 protocol number. --> | ||||
In the above example, the first flag bit is set which indicates that | In the above example, the first flag bit is set which indicates that | |||
the Group Identifier extension is present which is a 32 bit field. | the Group Identifier extension is present which is a 32 bit field. | |||
The second through fourth bits of the flags are paired flags that | The second through fourth bits of the flags are combined flags that | |||
indicate the presence of a Security field with seven possible sizes. | indicate the presence of a Security field with seven possible sizes. | |||
In this example 001 indicates a sixty-four bit security field. | In this example 001 indicates a sixty-four bit security field. | |||
<!-- CEP: This seems to make the GUEEXTENS document normative. --> | ||||
3.4. Private data | 3.4. Private data | |||
An implementation MAY use private data for its own use. The private | An implementation MAY use private data for its own use. | |||
<!-- CEP: This sentence does not seem helpful. --> | ||||
The private | ||||
data immediately follows the last field in the GUE header and is not | data immediately follows the last field in the GUE header and is not | |||
a fixed length. This data is considered part of the GUE header and | a fixed length. This data is considered part of the GUE header and | |||
MUST be accounted for in header length (Hlen). The length of the | MUST be accounted for in header length (Hlen). The length of the | |||
private data MUST be a multiple of four and is determined by | private data MUST be a multiple of four and is determined by | |||
subtracting the offset of private data in the GUE header from the | subtracting the offset of private data in the GUE header from the | |||
header length. Specifically: | header length. Specifically: | |||
Private_length = (Hlen * 4) - Length(flags) | Private_length = (Hlen * 4) - Length(extensions) | |||
where "Length(flags)" returns the sum of lengths of all the extension | where "Length(extensions)" returns the sum of lengths of all the extension | |||
fields present in the GUE header. When there is no private data | fields following the GUE header. When there is no private data | |||
present, the length of the private data is zero. | present, the length of the private data is zero. | |||
The semantics and interpretation of private data are implementation | The semantics and interpretation of private data are implementation | |||
specific. The private data may be structured as necessary, for | specific. An encapsulator and decapsulator MUST agree on the meaning of | |||
instance it might contain its own set of flags and extension fields. | private data before using it. The mechanism to achieve this agreement is | |||
outside the scope of this document. | ||||
An encapsulator and decapsulator MUST agree on the meaning of private | ||||
data before using it. The mechanism to achieve this agreement is | ||||
outside the scope of this document but could include implementation- | ||||
defined behavior, coordinated configuration, in-band communication | ||||
using GUE control messages, or out-of-band messages. | ||||
If a decapsulator receives a GUE packet with private data, it MUST | If a decapsulator receives a GUE packet with private data, it MUST | |||
validate the private data appropriately. If a decapsulator does not | validate the private data. If a decapsulator does not | |||
expect private data from an encapsulator, the packet MUST be dropped. | expect private data from an encapsulator, the packet MUST be dropped. | |||
If a decapsulator cannot validate the contents of private data per | If a decapsulator cannot validate the contents of private data per | |||
the provided semantics, the packet MUST also be dropped. An | the provided semantics, the packet MUST also be dropped. | |||
<!-- CEP: since the structure of the private data is out of scope, | ||||
the following RFC 2119 language is used incorrectly. | ||||
An | ||||
implementation MAY place security data in GUE private data which if | implementation MAY place security data in GUE private data which if | |||
present MUST be verified for packet acceptance. | present MUST be verified for packet acceptance. --> | |||
3.5. Message types | 3.5. Message types | |||
3.5.1. Control messages | 3.5.1. Control messages | |||
Control messages carry formatted data that are implicitly addressed | Control messages carry formatted data that are implicitly addressed | |||
to the decapsulator to monitor or control the state or behavior of a | to the decapsulator to monitor or control the state or behavior of a | |||
tunnel (OAM). For instance, an echo request and corresponding echo | tunnel. For instance, an echo request and corresponding echo | |||
reply message can be defined to test for liveness. | reply message can be defined to test for liveness. | |||
Control messages are indicated in the GUE header when the C-bit is | Control messages are present in the GUE header when the C-bit is | |||
set. The payload is interpreted as a control message with type | set. The payload is interpreted as a control message with type | |||
specified in the proto/ctype field. The format and contents of the | specified in the proto/ctype field. The format and contents of the | |||
control message are indicated by the type and can be variable length. | control message are indicated by the type and can be variable length. | |||
Other than interpreting the proto/ctype field as a control message | Other than interpreting the proto/ctype field as a control message | |||
type, the meaning and semantics of the rest of the elements in the | type, the meaning and semantics of the rest of the elements in the | |||
GUE header are the same as that of data messages. Forwarding and | GUE header are the same as that of data messages. Forwarding and | |||
routing of control messages should be the same as that of a data | routing of control messages should be the same as that of a data | |||
message with the same outer IP and UDP header and GUE flags; this | message with the same outer IP and UDP header and GUE flags; this | |||
ensures that control messages can be created that follow the same | ensures that control messages can be created that follow the same | |||
skipping to change at page 13, line 49 ¶ | skipping to change at page 13, line 52 ¶ | |||
packet of an Internet protocol indicated in the proto/ctype field. | packet of an Internet protocol indicated in the proto/ctype field. | |||
The packet immediately follows the GUE header. | The packet immediately follows the GUE header. | |||
3.6. Hiding the transport layer protocol number | 3.6. Hiding the transport layer protocol number | |||
The GUE header indicates the Internet protocol of the encapsulated | The GUE header indicates the Internet protocol of the encapsulated | |||
packet. A protocol number is either contained in the Proto/ctype | packet. A protocol number is either contained in the Proto/ctype | |||
field of the primary GUE header or in the Payload Type field of a GUE | field of the primary GUE header or in the Payload Type field of a GUE | |||
Transform extension field (used to encrypt the payload with DTLS, | Transform extension field (used to encrypt the payload with DTLS, | |||
[GUEEXTEN]). If the transport protocol number needs to be hidden from | [GUEEXTEN]). If the transport protocol number needs to be hidden from | |||
the network, then a trivial destination options can be used. | the network, then a trivial destination options can be used, as | |||
specified below. | ||||
<!-- CEP: This destination option needs to be specified in this document.--> | ||||
The PadN destination option [RFC2460] can be used to encode the | The PadN destination option [RFC2460] can be used to encode the | |||
<!-- CEP: PadN is not a destination option. --> | ||||
transport protocol as a next header of an extension header (and | transport protocol as a next header of an extension header (and | |||
maintain alignment of encapsulated transport headers). The | maintain alignment of encapsulated transport header). The | |||
Proto/ctype field or Payload Type field of the GUE Transform field is | Proto/ctype field or Payload Type field of the GUE Transform field is | |||
set to 60 to indicate that the first encapsulated header is a | set to 60 to indicate that the first encapsulated header is a | |||
destination options extension header. | destination options extension header. | |||
The format of the extension header is below: | The format of the extension header is below: | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Next Header | 2 | 1 | 0 | | | Next Header | 2 | 1 | 0 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
For IPv4, it is permitted in GUE to used this precise destination | For IPv4, it is permitted in GUE to used this precise destination | |||
option to contain the obfuscated protocol number. In this case next | option to hide the protocol number. In this case next | |||
header MUST refer to a valid IP protocol for IPv4. No other extension | header MUST refer to a valid IP protocol for IPv4. No other extension | |||
headers or destination options are permitted with IPv4. | headers or destination options are permitted with IPv4. | |||
4. Variant 1 | 4. Variant 1 | |||
Variant 1 of GUE allows direct encapsulation of IPv4 and IPv6 in UDP. | Variant 1 of GUE allows direct encapsulation of IPv4 and IPv6 in UDP. | |||
In this variant there is no GUE header; a UDP packet carries an IP | In this variant there is no GUE header; a UDP packet carries an IP | |||
packet. The first two bits of the UDP payload for GUE are the GUE | packet. The first two bits of the UDP payload for GUE are the GUE | |||
variant and coincide with the first two bits of the version number in | variant and coincide with the first two bits of the version number in | |||
the IP header. The first two version bits of IPv4 and IPv6 are 01, so | the IP header. The first two version bits of IPv4 and IPv6 are 01, so | |||
skipping to change at page 17, line 27 ¶ | skipping to change at page 17, line 27 ¶ | |||
| Host 1 | | Host 2 | | | Host 1 | | Host 2 | | |||
| | | | | | | | | | |||
+---------------+ +---------------+ | +---------------+ +---------------+ | |||
| ^ | | ^ | |||
V | | V | | |||
+---------------+ +---------------+ +---------------+ | +---------------+ +---------------+ +---------------+ | |||
| | | | | | | | | | | | | | |||
| Encapsulator |-->| Layer 3 |-->| Decapsulator | | | Encapsulator |-->| Layer 3 |-->| Decapsulator | | |||
| | | Network | | | | | | | Network | | | | |||
+---------------+ +---------------+ +---------------+ | +---------------+ +---------------+ +---------------+ | |||
<!-- CEP: This is true for any L3 encapsulation --> | ||||
<!-- CEP: This figure illustrates something that is most likely | ||||
obvious to almost all readers. --> | ||||
The encapsulator and decapsulator may be co-resident with the | The encapsulator and decapsulator may be co-resident with the | |||
corresponding hosts, or may be on separate nodes in the network. | corresponding hosts, or may be on separate nodes in the network. | |||
5.1. Network tunnel encapsulation | 5.1. Network tunnel encapsulation | |||
Network tunneling can be achieved by encapsulating layer 2 or layer 3 | Network tunneling can be achieved by encapsulating layer 2 or layer 3 | |||
packets. In this case the encapsulator and decapsulator nodes are the | packets. In this case the encapsulator and decapsulator nodes are the | |||
tunnel endpoints. These could be routers that provide network tunnels | tunnel endpoints. These could be routers that provide network tunnels | |||
on behalf of communicating hosts. | on behalf of communicating hosts. | |||
<!-- CEP: Do you mean that GUE can encapsulate L2 frames? If so, this | ||||
contradicts earlier text in several places. ---> | ||||
5.2. Transport layer encapsulation | 5.2. Transport layer encapsulation | |||
When encapsulating layer 4 packets, the encapsulator and decapsulator | When encapsulating layer 4 packets, the encapsulator and decapsulator | |||
should be co-resident with the hosts. In this case, the encapsulation | should be co-resident with the hosts. | |||
<!-- CEP: This seems to try to distinguish between "layer 4" and | ||||
IP protocol number. If so, what is the distinction?? --> | ||||
In this case, the encapsulation | ||||
headers are inserted between the IP header and the transport packet. | headers are inserted between the IP header and the transport packet. | |||
The addresses in the IP header refer to both the endpoints of the | The addresses in the IP header refer to both the endpoints of the | |||
encapsulation and the endpoints for terminating the transport | encapsulation and the endpoints for terminating the transport | |||
protocol. Note that the transport layer ports in the encapsulated | protocol. Note that the transport layer ports in the encapsulated | |||
packet are independent of the UDP ports in the outer packet. | packet are independent of the UDP ports in the outer packet. | |||
Details about performing transport layer encapsulation are discussed | Details about performing transport layer encapsulation are discussed | |||
in [TOU]. | in [TOU]. | |||
<!-- CEP: I think those details belong here. If not, this is a normative | ||||
dependency on a non-WG document that is not yet mature. --> | ||||
5.3. Encapsulator operation | 5.3. Encapsulator operation | |||
Encapsulators create GUE data messages, set the fields of the UDP | Encapsulators create GUE data messages, set the fields of the UDP | |||
header, set flags and optional extension fields in the GUE header, | header, set flags and optional extension fields in the GUE header, | |||
and forward packets to a decapsulator. | and forward packets to a decapsulator. | |||
<!-- CEP: According to the figure, encapsulators don't have to | ||||
create data. Moreover, the whole point of "generic" | ||||
encapsulation seems to be independence from content. --> | ||||
An encapsulator can be an end host originating the packets of a flow, | An encapsulator can be an end host originating the packets of a flow, | |||
or can be a network device performing encapsulation on behalf of | or can be a network device performing encapsulation on behalf of | |||
hosts (routers implementing tunnels for instance). In either case, | hosts (routers implementing tunnels for instance). In either case, | |||
the intended target (decapsulator) is indicated by the outer | the intended target (decapsulator) is indicated by the outer | |||
destination IP address and destination port in the UDP header. | destination IP address and destination port in the UDP header. | |||
If an encapsulator is tunneling packets -- that is encapsulating | If an encapsulator is tunneling packets -- that is encapsulating | |||
packets of layer 2 or layer 3 protocols (e.g. EtherIP, IPIP, ESP | packets of layer 3 protocols (e.g. EtherIP, IPIP, ESP | |||
tunnel mode) -- it SHOULD follow standard conventions for tunneling | tunnel mode) -- it MUST follow standard conventions for tunneling | |||
of one protocol over another. For instance, if an IP packet is being | of one protocol over another. For instance, if an IP packet is being | |||
encapsualated in GUE then diffserv interaction [RFC2983] and ECN | encapsulated in GUE then diffserv interaction [RFC2983] and ECN | |||
propagation for tunnels [RFC6040] SHOULD be followed. | propagation for tunnels [RFC6040] MUST be followed. | |||
<!-- CEP: this violates "generic" unless all IP protocols are | ||||
respected in that way. --> | ||||
<!-- CEP: GUE states several times that implementations MUST follow | ||||
standards. Does that mean that sometimes implementations | ||||
MAY break standards if not explicitly required to follow | ||||
them? I hope not! I think it would be better to avoid | ||||
recommendations about following existing standards. --> | ||||
5.4. Decapsulator operation | 5.4. Decapsulator operation | |||
A decapsulator performs decapsulation of GUE packets. A decapsulator | A decapsulator performs decapsulation of GUE packets. A decapsulator | |||
is addressed by the outer destination IP address of a GUE packet. | is addressed by the outer destination IP address of a GUE packet. | |||
The decapsulator validates packets, including fields of the GUE | The decapsulator validates packets, including fields of the GUE | |||
header. | header. | |||
If a decapsulator receives a GUE packet with an unsupported variant, | If a decapsulator receives a GUE packet with an unsupported variant, | |||
unknown flag, bad header length (too small for included extension | unknown flag, bad header length (too small for included extension | |||
fields), unknown control message type, bad protocol number, an | fields), unknown control message type, bad protocol number, an | |||
unsupported payload type, or an otherwise malformed header, it MUST | unsupported payload type, or an otherwise malformed header, it MUST | |||
drop the packet. Such events MAY be logged subject to configuration | drop the packet. Such events MAY be logged subject to configuration | |||
and rate limiting of logging messages. Note that set flags in a GUE | and rate limiting of logging messages. Note that set flags in a GUE | |||
header that are unknown to a decapsulator MUST NOT be ignored. If a | header that are unknown to a decapsulator MUST NOT be ignored. If a | |||
GUE packet is received by a decapsulator with unknown flags, the | GUE packet is received by a decapsulator with unknown flags, the | |||
packet MUST be dropped. | packet MUST be dropped. | |||
<!-- CEP: An ICMP message seems appropriate here. --> | ||||
5.4.1. Processing a received data message | 5.4.1. Processing a received data message | |||
If a valid data message is received, the UDP header and GUE header | If a valid data message is received, the UDP header and GUE header | |||
<!-- CEP: Need to define "valid". --> | ||||
are removed from the packet. The outer IP header remains intact and | are removed from the packet. The outer IP header remains intact and | |||
the next protocol in the IP header is set to the protocol from the | the next protocol in the IP header is set to the protocol from the | |||
proto field in the GUE header. The resulting packet is then | proto field in the GUE header. The resulting packet is then | |||
resubmitted into the protocol stack to process that packet as though | resubmitted into the protocol stack to process that packet as though | |||
it was received with the protocol in the GUE header. | it was received with the protocol in the GUE header. | |||
As an example, consider that a data message is received where GUE | As an example, consider that a data message is received where GUE | |||
encapsulates an IPv4 packet using GUE variant 0. In this case proto | encapsulates an IPv4 packet using GUE variant 0. In this case proto | |||
field in the GUE header is set to 4 for IPv4 encapsulation: | field in the GUE header is set to 4 for IPv4 encapsulation: | |||
+-------------------------------------+ | +-------------------------------------+ | |||
| IP header (next proto = 17,UDP) | | | IP header (next proto = 17,UDP) | | |||
|-------------------------------------| | |-------------------------------------| | |||
| UDP | | | UDP | | |||
|-------------------------------------| | |-------------------------------------| | |||
| GUE (proto = 4,IPv4 encapsulation) | | | GUE (proto = 4,IPv4 encapsulation) | | |||
|-------------------------------------| | |-------------------------------------| | |||
| IPv4 header and packet | | | IPv4 header and packet | | |||
+-------------------------------------+ | +-------------------------------------+ | |||
<!-- CEP: All figures should have figure numbers, even if not | ||||
cross-referenced in this document. --> | ||||
The receiver removes the UDP and GUE headers and sets the next | The receiver removes the UDP and GUE headers and sets the next | |||
protocol field in the IP packet to 4, which is derived from the GUE | protocol field in the IP packet to 4, which is derived from the GUE | |||
proto field. The resultant packet would have the format: | proto field. The resultant packet would have the format: | |||
+-------------------------------------+ | +-------------------------------------+ | |||
| IP header (next proto = 4,IPv4) | | | IP header (next proto = 4,IPv4) | | |||
|-------------------------------------| | |-------------------------------------| | |||
| IP header and packet | | | IP header and packet | | |||
+-------------------------------------+ | +-------------------------------------+ | |||
This packet is then resubmitted into the protocol stack to be | This packet is then resubmitted into the protocol stack to be | |||
processed as an IPv4 encapsulated packet. | processed as an IPv4 encapsulated packet. | |||
5.4.2. Processing a received control message | 5.4.2. Processing a received control message | |||
If a valid control message is received, the packet MUST be processed | If a valid control message is received, the packet MUST be processed | |||
as a control message. The specific processing to be performed depends | as a control message. | |||
<!-- CEP: Need to define "valid". What exactly is meant by "processed | ||||
as a control message"? In each case, the processing is | ||||
determined by the GUE header fields. --> | ||||
The specific processing to be performed depends | ||||
on the value in the ctype field of the GUE header. | on the value in the ctype field of the GUE header. | |||
5.5. Router and switch operation | 5.5. Router and switch operation | |||
Routers and switches SHOULD forward GUE packets as standard UDP/IP | Routers and switches MUST forward GUE packets as standard UDP/IP | |||
packets. The outer five-tuple should contain sufficient information | packets. | |||
<!-- CEP: Another puzzling unenforceable mandate. Why would | ||||
inclusion of GUE suddenly invalidate previous standards? --> | ||||
The outer five-tuple should contain sufficient information | ||||
to perform flow classification corresponding to the flow of the inner | to perform flow classification corresponding to the flow of the inner | |||
packet. A router does not normally need to parse a GUE header, and | packet. A router does not normally need to parse a GUE header, and | |||
none of the flags or extension fields in the GUE header are expected | none of the flags or extension fields in the GUE header are expected | |||
to affect routing. In cases where the outer five-tuple does not | to affect routing. In cases where the outer five-tuple does not | |||
provide sufficient entropy for flow classification, for instance UDP | provide sufficient entropy for flow classification, for instance UDP | |||
ports are fixed to provide connection semantics (section 5.6.1), then | ports are fixed to provide connection semantics (section 5.6.1), then | |||
the encapsulated packet MAY be parsed to determine flow entropy. | the encapsulated packet MAY be parsed to determine flow entropy. | |||
A router MUST NOT modify a GUE header when forwarding a packet. It | A router MUST NOT modify a GUE header when forwarding a packet. It | |||
MAY encapsulate a GUE packet in another GUE packet, for instance to | MAY encapsulate a GUE packet in another GUE packet, for instance to | |||
implement a network tunnel (i.e. by encapsulating an IP packet with a | implement a network tunnel (i.e. by encapsulating an IP packet with a | |||
GUE payload in another IP packet as a GUE payload). In this case, the | GUE payload in another IP packet as a GUE payload). In this case, the | |||
router takes the role of an encapsulator, and the corresponding | router takes the role of an encapsulator, and the corresponding | |||
decapsulator is the logical endpoint of the tunnel. When | decapsulator is the logical endpoint of the tunnel. When | |||
encapsulating a GUE packet within another GUE packet, there are no | encapsulating a GUE packet within another GUE packet, there are no | |||
provisions to automatically copy flags or fields to the outer GUE | provisions to automatically copy flags or fields to the outer GUE | |||
header. Each layer of encapsulation is considered independent. | header. Each layer of encapsulation is considered independent. | |||
<!-- CEP: Does this document intend to update RFC 2983, 6040? --> | ||||
5.6. Middlebox interactions | 5.6. Middlebox interactions | |||
A middlebox MAY interpret some flags and extension fields of the GUE | A middlebox MAY interpret some flags and extension fields of the GUE | |||
header for classification purposes, but is not required to understand | header for classification purposes, but is not required to understand | |||
any of the flags or extension fields in GUE packets. A middlebox MUST | any of the flags or extension fields in GUE packets. A middlebox MUST | |||
NOT drop a GUE packet merely because there are flags unknown to it. | NOT drop a GUE packet merely because there are flags unknown to it. | |||
<!-- CEP: unenforceable. --> | ||||
The header length in the GUE header allows a middlebox to inspect the | The header length in the GUE header allows a middlebox to inspect the | |||
payload packet without needing to parse the flags or extension | payload packet without needing to parse the flags or extension | |||
fields. | fields. | |||
5.6.1. Inferring connection semantics | 5.6.1. Inferring connection semantics | |||
A middlebox might infer bidirectional connection semantics for a UDP | A middlebox might infer bidirectional connection semantics for a UDP | |||
flow. For instance, a stateful firewall might create a five-tuple | flow. For instance, a stateful firewall might create a five-tuple | |||
rule to match flows on egress, and a corresponding five-tuple rule | rule to match flows on egress, and a corresponding five-tuple rule | |||
for matching ingress packets where the roles of source and | for matching ingress packets where the roles of source and | |||
skipping to change at page 20, line 34 ¶ | skipping to change at page 20, line 36 ¶ | |||
To operate in this environment, a GUE tunnel should be configured to | To operate in this environment, a GUE tunnel should be configured to | |||
assume connected semantics defined by the UDP five tuple and the use | assume connected semantics defined by the UDP five tuple and the use | |||
of GUE encapsulation needs to be symmetric between both endpoints. | of GUE encapsulation needs to be symmetric between both endpoints. | |||
The source port set in the UDP header MUST be the destination port | The source port set in the UDP header MUST be the destination port | |||
the peer would set for replies. In this case, the UDP source port for | the peer would set for replies. In this case, the UDP source port for | |||
a tunnel would be a fixed value and not set to be flow entropy as | a tunnel would be a fixed value and not set to be flow entropy as | |||
described in section 5.11. | described in section 5.11. | |||
The selection of whether to make the UDP source port fixed or set to | The selection of whether to make the UDP source port fixed or set to | |||
a flow entropy value for each packet sent SHOULD be configurable for | a flow entropy value for each packet sent SHOULD be configurable for | |||
a tunnel. The default MUST be to set the flow entropy value in the | a tunnel. | |||
<!-- CEP: The SHOULD is a mandate on the configuration of GUE, not | ||||
on GUE protocol. --> | ||||
The default MUST be to set the flow entropy value in the | ||||
UDP source port. | UDP source port. | |||
5.6.2. NAT | 5.6.2. NAT | |||
IP address and port translation can be performed on the UDP/IP | IP address and port translation can be performed on the UDP/IP | |||
headers adhering to the requirements for NAT with UDP [RFC4787]. In | headers adhering to the requirements for NAT with UDP [RFC4787]. In | |||
the case of stateful NAT, connection semantics MUST be applied to a | the case of stateful NAT, connection semantics MUST be applied to a | |||
GUE tunnel as described in section 5.6.1. GUE endpoints MAY also | GUE tunnel as described in section 5.6.1. GUE endpoints MAY also | |||
invoke STUN [RFC5389] or ICE [RFC5245] to manage NAT port mappings | invoke STUN [RFC5389] or ICE [RFC5245] to manage NAT port mappings | |||
for encapsulations. | for encapsulations. | |||
5.7. Checksum Handling | 5.7. Checksum Handling | |||
The potential for mis-delivery of packets due to corruption of IP, | The potential for mis-delivery of packets due to corruption of IP, | |||
UDP, or GUE headers needs to be considered. Historically, the UDP | UDP, or GUE headers needs to be considered. Historically, the UDP | |||
checksum would be considered sufficient as a check against corruption | checksum would be considered sufficient as a check against corruption | |||
of either the UDP header and payload or the IP addresses. | of either the UDP header and payload or the IP addresses. | |||
Encapsulation protocols, such as GUE, can be originated or terminated | Encapsulation protocols, such as GUE, can be originated or terminated | |||
on devices incapable of computing the UDP checksum for packet. This | on devices incapable of computing the UDP checksum for packet. | |||
<!-- CEP: citation needed for such devices. --> | ||||
This | ||||
section discusses the requirements around checksum and alternatives | section discusses the requirements around checksum and alternatives | |||
that might be used when an endpoint does not support UDP checksum. | that might be used when an endpoint does not support UDP checksum. | |||
5.7.1. Requirements | 5.7.1. Requirements | |||
One of the following requirements MUST be met: | One of the following requirements MUST be met: | |||
<!-- CEP: This is a tautology. Either the checksum is zero, or not. --> | ||||
o UDP checksums are enabled (for IPv4 or IPv6). | o UDP checksums are enabled (for IPv4 or IPv6). | |||
<!-- CEP: Is GUE defined in this document for anything other | ||||
than IPv[4,6]? Is UDP defined for anything else?? --> | ||||
o The GUE header checksum is used (defined in [GUEEXTEN]). | o The GUE header checksum is used (defined in [GUEEXTEN]). | |||
o Use zero UDP checksums. This is always permissible with IPv4; in | o Use zero UDP checksums. This is always permissible with IPv4; in | |||
IPv6, they can only be used in accordance with applicable | IPv6, they can only be used in accordance with applicable | |||
requirements in [RFC8086], [RFC6935], and [RFC6936]. | requirements in [RFC8086], [RFC6935], and [RFC6936]. | |||
5.7.2. UDP Checksum with IPv4 | 5.7.2. UDP Checksum with IPv4 | |||
For UDP in IPv4, the UDP checksum MUST be processed as specified in | For UDP in IPv4, the UDP checksum MUST be processed as specified in | |||
[RFC768] and [RFC1122] for both transmit and receive. An | [RFC768] and [RFC1122] for both transmit and receive. An | |||
encapsulator MAY set the UDP checksum to zero for performance or | encapsulator MAY set the UDP checksum to zero for performance or | |||
implementation considerations. The IPv4 header includes a checksum | implementation considerations. The IPv4 header includes a checksum | |||
that protects against mis-delivery of the packet due to corruption | that protects against mis-delivery of the packet due to corruption | |||
of IP addresses. The UDP checksum potentially provides protection | of IP addresses. The UDP checksum potentially provides protection | |||
against corruption of the UDP header, GUE header, and GUE payload. | against corruption of the UDP header, GUE header, and GUE payload. | |||
Enabling or disabling the use of checksums is a deployment | Enabling or disabling the use of checksums is a deployment | |||
consideration that should take into account the risk and effects of | consideration that SHOULD take into account the risk and effects of | |||
packet corruption, and whether the packets in the network are | packet corruption, and whether the packets in the network are | |||
already adequately protected by other, possibly stronger mechanisms, | already adequately protected by other, possibly stronger mechanisms, | |||
such as the Ethernet CRC. If an encapsulator sets a zero UDP | such as the Ethernet CRC. If an encapsulator sets a zero UDP | |||
checksum for IPv4, it SHOULD use the GUE header checksum as | checksum for IPv4, it SHOULD use the GUE header checksum as | |||
described in [GUEEXTEN] assuming there are no other mechanisms used | described in [GUEEXTEN] assuming there are no other mechanisms used | |||
to protect the GUE packet. | to protect the GUE packet. | |||
<!-- CEP: This last sentence seems to disregard the previous sentence, | ||||
which would then obviate the need for a GUE checksum. --> | ||||
When a decapsulator receives a packet, the UDP checksum field MUST | When a decapsulator receives a packet, the UDP checksum field MUST | |||
be processed. If the UDP checksum is non-zero, the decapsulator MUST | be processed. If the UDP checksum is non-zero, the decapsulator MUST | |||
verify the checksum before accepting the packet. By default, a | verify the checksum before accepting the packet. By default, a | |||
decapsulator SHOULD accept UDP packets with a zero checksum. A node | decapsulator SHOULD accept UDP packets with a zero checksum. A node | |||
MAY be configured to disallow zero checksums per [RFC1122]. | MAY be configured to disallow zero checksums per [RFC1122]. | |||
Configuration of zero checksums can be selective. For instance, zero | Configuration of zero checksums can be selective. For instance, zero | |||
checksums might be disallowed from certain hosts that are known to | checksums might be disallowed from certain hosts that are known to | |||
be traversing paths subject to packet corruption. If verification of | be traversing paths subject to packet corruption. If verification of | |||
a non-zero checksum fails, a decapsulator lacks the capability to | a non-zero checksum fails, a decapsulator lacks the capability to | |||
skipping to change at page 22, line 14 ¶ | skipping to change at page 22, line 14 ¶ | |||
5.7.3. UDP Checksum with IPv6 | 5.7.3. UDP Checksum with IPv6 | |||
In IPv6, there is no checksum in the IPv6 header that protects | In IPv6, there is no checksum in the IPv6 header that protects | |||
against mis-delivery due to address corruption. Therefore, when GUE | against mis-delivery due to address corruption. Therefore, when GUE | |||
is used over IPv6, either the UDP checksum or the GUE header | is used over IPv6, either the UDP checksum or the GUE header | |||
checksum SHOULD be used unless there are alternative mechanisms in | checksum SHOULD be used unless there are alternative mechanisms in | |||
use that protect against misdelivery. The UDP checksum and GUE | use that protect against misdelivery. The UDP checksum and GUE | |||
header checksum SHOULD NOT be used at the same time since that would | header checksum SHOULD NOT be used at the same time since that would | |||
be mostly redundant. | be mostly redundant. | |||
<!-- CEP: Why not simply mandate the UDP checksum? --> | ||||
If neither the UDP checksum or the GUE header checksum is used, then | If neither the UDP checksum or the GUE header checksum is used, then | |||
the requirements for using zero IPv6 UDP checksums in [RFC6935] and | the requirements for using zero IPv6 UDP checksums in [RFC6935] and | |||
[RFC6936] MUST be met. | [RFC6936] MUST be met. | |||
When a decapsulator receives a packet, the UDP checksum field MUST | When a decapsulator receives a packet, the UDP checksum field MUST | |||
be processed. If the UDP checksum is non-zero, the decapsulator MUST | be processed. If the UDP checksum is non-zero, the decapsulator MUST | |||
verify the checksum before accepting the packet. By default a | verify the checksum before accepting the packet. By default a | |||
decapsulator MUST only accept UDP packets with a zero checksum if | decapsulator MUST only accept UDP packets with a zero checksum if | |||
the GUE header checksum is used and is verified. If verification of | the GUE header checksum is used and is verified. If verification of | |||
a non-zero checksum fails, a decapsulator lacks the capability to | a non-zero checksum fails, a decapsulator lacks the capability to | |||
verify a non-zero checksum, or a packet with a zero-checksum and no | verify a non-zero checksum, or a packet with a zero-checksum and no | |||
GUE header checksum was received, the packet MUST be dropped. | GUE header checksum was received, the packet MUST be dropped. | |||
5.8. MTU and fragmentation | 5.8. MTU and fragmentation | |||
Standard conventions for handling of MTU (Maximum Transmission Unit) | Standard conventions for handling of MTU (Maximum Transmission Unit) | |||
and fragmentation in conjunction with networking tunnels | and fragmentation in conjunction with networking tunnels | |||
(encapsulation of layer 2 or layer 3 packets) SHOULD be followed. | (encapsulation of layer 2 or layer 3 packets) MUST be followed. | |||
Details are described in MTU and Fragmentation Issues with In-the- | Details are described in MTU and Fragmentation Issues with In-the- | |||
Network Tunneling [RFC4459]. | Network Tunneling [RFC4459]. | |||
If a packet is fragmented before encapsulation in GUE, all the | If a packet is fragmented before encapsulation in GUE, all the | |||
related fragments MUST be encapsulated using the same UDP source | related fragments MUST be encapsulated using the same UDP source | |||
port. An operator SHOULD set MTU to account for encapsulation | port. An operator SHOULD set MTU to account for encapsulation | |||
overhead and reduce the likelihood of fragmentation. | overhead and reduce the likelihood of fragmentation. | |||
Alternative to IP fragmentation, the GUE fragmentation extension can | Alternative to IP fragmentation, the GUE fragmentation extension can | |||
be used. GUE fragmentation is described in [GUEEXTEN]. | be used. GUE fragmentation is described in [GUEEXTEN]. | |||
<!-- CEP: GUE fragmentation has to be specified in this document. --> | ||||
5.9. Congestion control | 5.9. Congestion control | |||
Per requirements of [RFC5405], if the IP traffic encapsulated with | Per requirements of [RFC5405], if the IP traffic encapsulated with | |||
GUE implements proper congestion control no additional mechanisms | GUE implements proper congestion control no additional mechanisms | |||
should be required. | are required. | |||
In the case that the encapsulated traffic does not implement any or | In the case that the encapsulated traffic does not implement any or | |||
sufficient control, or it is not known whether a transmitter will | sufficient control, or it is not known whether a transmitter will | |||
consistently implement proper congestion control, then congestion | consistently implement proper congestion control, then congestion | |||
control at the encapsulation layer MUST be provided per [RFC5405]. | control at the encapsulation layer MUST be provided per [RFC5405]. | |||
Note that this case applies to a significant use case in network | This applies to a significant use case in network | |||
virtualization in which guests run third party networking stacks | virtualization in which guests run third party networking stacks | |||
that cannot be implicitly trusted to implement conformant congestion | that cannot be implicitly trusted to implement conformant congestion | |||
control. | control. | |||
Out of band mechanisms such as rate limiting, Managed Circuit | Out of band mechanisms such as rate limiting, Managed Circuit | |||
Breaker [RFC8084], or traffic isolation MAY be used to provide | Breaker [RFC8084], or traffic isolation MAY be used to provide | |||
rudimentary congestion control. For finer-grained congestion control | rudimentary congestion control. For finer-grained congestion control | |||
that allows alternate congestion control algorithms, reaction time | that allows alternate congestion control algorithms, reaction time | |||
within an RTT, and interaction with ECN, in-band mechanisms might be | within an RTT, and interaction with ECN, in-band mechanisms might be | |||
warranted. | warranted. | |||
skipping to change at page 23, line 42 ¶ | skipping to change at page 23, line 42 ¶ | |||
independent of the encapsulation and is otherwise outside the scope | independent of the encapsulation and is otherwise outside the scope | |||
of this document. | of this document. | |||
5.11. Flow entropy for ECMP | 5.11. Flow entropy for ECMP | |||
5.11.1. Flow classification | 5.11.1. Flow classification | |||
A major objective of using GUE is that a network device can perform | A major objective of using GUE is that a network device can perform | |||
flow classification corresponding to the flow of the inner | flow classification corresponding to the flow of the inner | |||
encapsulated packet based on the contents in the outer headers. | encapsulated packet based on the contents in the outer headers. | |||
<!-- CEP: This sentence belongs in the Introduction. --> | ||||
Hardware devices commonly perform hash computations on packet | Hardware devices commonly perform hash computations on packet | |||
headers to classify packets into flows or flow buckets. Flow | headers to classify packets into flows or flow buckets. Flow | |||
classification is done to support load balancing of flows across a | classification is done to support load balancing of flows across a | |||
set of networking resources. Examples of such load balancing | set of networking resources. Examples of such load balancing | |||
techniques are Equal Cost Multipath routing (ECMP), port selection | techniques are Equal Cost Multipath routing (ECMP), port selection | |||
in Link Aggregation, and NIC device Receive Side Scaling (RSS). | in Link Aggregation, and NIC device Receive Side Scaling (RSS). | |||
<!-- CEP: citations needed. --> | ||||
Hashes are usually either a three-tuple hash of IP protocol, source | Hashes are usually either a three-tuple hash of IP protocol, source | |||
address, and destination address; or a five-tuple hash consisting of | address, and destination address; or a five-tuple hash consisting of | |||
IP protocol, source address, destination address, source port, and | IP protocol, source address, destination address, source port, and | |||
destination port. Typically, networking hardware will compute five- | destination port. Typically, networking hardware will compute five- | |||
tuple hashes for TCP and UDP, but only three-tuple hashes for other | tuple hashes for TCP and UDP, but only three-tuple hashes for other | |||
IP protocols. Since the five-tuple hash provides more granularity, | IP protocols. Since the five-tuple hash provides more granularity, | |||
load balancing can be finer-grained with better distribution. When a | load balancing can be finer-grained with better distribution. When a | |||
packet is encapsulated with GUE and connection semantics are not | packet is encapsulated with GUE and connection semantics are not | |||
applied, the source port in the outer UDP packet is set to a flow | applied, the source port in the outer UDP packet is set to a flow | |||
entropy value that corresponds to the flow of the inner packet. When | entropy value that corresponds to the flow of the inner packet. When | |||
a device computes a five-tuple hash on the outer UDP/IP header of a | a device computes a five-tuple hash on the outer UDP/IP header of a | |||
GUE packet, the resultant value classifies the packet per its inner | GUE packet, the resultant value classifies the packet per its inner | |||
flow. | flow. | |||
Examples of deriving flow entropy for encapsulation are: | Examples of deriving flow entropy for encapsulation are: | |||
o If the encapsulated packet is a layer 4 packet, TCP/IPv4 for | o If the encapsulated packet is a layer 4 packet, TCPv4 for | |||
instance, the flow entropy could be based on the canonical five- | instance, the flow entropy could be based on the canonical five- | |||
tuple hash of the inner packet. | tuple hash of the inner packet. | |||
o If the encapsulated packet is an AH transport mode packet with | o If the encapsulated packet is an AH transport mode packet with | |||
TCP as next header, the flow entropy could be a hash over a | TCP as next header, the flow entropy could be a hash over a | |||
three-tuple: TCP protocol and TCP ports of the encapsulated | three-tuple: TCP protocol and TCP ports of the encapsulated | |||
packet. | packet. | |||
o If a node is encrypting a packet using ESP tunnel mode and GUE | o If a node is encrypting a packet using ESP tunnel mode and GUE | |||
encapsulation, the flow entropy could be based on the contents | encapsulation, the flow entropy could be based on the contents | |||
of the clear-text packet. For instance, a canonical five-tuple | of the clear-text packet. For instance, a canonical five-tuple | |||
hash for a TCP/IP packet could be used. | hash for a TCP/IP packet could be used. | |||
[RFC6438] discusses methods to compute and set flow entropy value for | [RFC6438] discusses methods to compute and set flow entropy value for | |||
IPv6 flow labels. Such methods can also be used to create flow | IPv6 flow labels. Such methods can also be used to create flow | |||
entropy values for GUE. | entropy values for GUE. | |||
<!-- CEP: for interoperability, maybe more specifics are needed. --> | ||||
5.11.2. Flow entropy properties | 5.11.2. Flow entropy properties | |||
The flow entropy is the value set in the UDP source port of a GUE | The flow entropy is the value set in the UDP source port of a GUE | |||
packet. Flow entropy in the UDP source port SHOULD adhere to the | packet. Flow entropy in the UDP source port SHOULD adhere to the | |||
following properties: | following properties: | |||
o The value set in the source port is within the ephemeral port | o The value set in the source port is within the ephemeral port | |||
range (49152 to 65535 [RFC6335]). Since the high order two bits | range (49152 to 65535 [RFC6335]). Since the high order two bits | |||
of the port are set to one, this provides fourteen bits of | of the port are set to one, this provides fourteen bits of | |||
entropy for the value. | entropy for the value. | |||
o The flow entropy has a uniform distribution across encapsulated | o The flow entropy has a uniform distribution across encapsulated | |||
flows. | flows. | |||
o An encapsulator MAY occasionally change the flow entropy used | o An encapsulator MAY occasionally change the flow entropy used | |||
for an inner flow per its discretion (for security, route | for an inner flow (for security, route | |||
selection, etc). To avoid thrashing or flapping the value, the | selection, etc). To avoid thrashing or flapping the value, the | |||
flow entropy used for a flow SHOULD NOT change more than once | flow entropy used for a flow SHOULD NOT change more than once | |||
every thirty seconds (or a configurable value). | every thirty seconds (or a configurable value). | |||
<!-- CEP: This configurable value needs a name. --> | ||||
o Decapsulators, or any networking devices, SHOULD NOT attempt to | o Decapsulators, or any networking devices, SHOULD NOT attempt to | |||
interpret flow entropy as anything more than an opaque value. | interpret flow entropy as anything more than an opaque value. | |||
Neither should they attempt to reproduce the hash calculation | Neither should they attempt to reproduce the hash calculation | |||
used by an encapasulator in creating a flow entropy value. They | used by an encapasulator in creating a flow entropy value. They | |||
MAY use the value to match further receive packets for steering | MAY use the value to match further receive packets for steering | |||
decisions, but MUST NOT assume that the hash uniquely or | decisions, but MUST NOT assume that the hash uniquely or | |||
permanently identifies a flow. | permanently identifies a flow. | |||
o Input to the flow entropy calculation is not restricted to ports | o Input to the flow entropy calculation is not restricted to ports | |||
and addresses; input could include flow label from an IPv6 | and addresses; input could include flow label from an IPv6 | |||
packet, SPI from an ESP packet, or other flow related state in | packet, SPI from an ESP packet, or other flow related state in | |||
the encapsulator that is not necessarily conveyed in the packet. | the encapsulator that is not necessarily conveyed in the packet. | |||
o The assignment function for flow entropy SHOULD be randomly | o The assignment function for flow entropy SHOULD be randomly | |||
seeded to mitigate denial of service attacks. The seed SHOULD be | seeded to mitigate denial of service attacks. The seed SHOULD be | |||
changed periodically. | changed periodically. | |||
<!-- CEP: This needs to be specified. --> | ||||
5.12 Negotiation of acceptable flags and extension fields | 5.12 Negotiation of acceptable flags and extension fields | |||
An encapsulator and decapsulator need to achieve agreement about GUE | An encapsulator and decapsulator need to achieve agreement about GUE | |||
parameters that will be used in communications. Parameters include | parameters that will be used in communications. Parameters include | |||
supported GUE variants, flags and extension fields that can be used, | supported GUE variants, flags and extension fields that can be used, | |||
security algorithms and keys, supported protocols and control | security algorithms and keys, supported protocols and control | |||
messages, etc. This document proposes different general methods to | messages, etc. This document proposes different general methods to | |||
accomplish this, however the details of implementing these are | accomplish this, however the details of implementing these are | |||
considered out of scope. | considered out of scope. | |||
skipping to change at page 26, line 9 ¶ | skipping to change at page 26, line 9 ¶ | |||
needed for network virtualization). | needed for network virtualization). | |||
o Via security negotiation. Use of security typically implies a | o Via security negotiation. Use of security typically implies a | |||
key exchange between endpoints. Other GUE parameters may be | key exchange between endpoints. Other GUE parameters may be | |||
conveyed as part of that process. | conveyed as part of that process. | |||
6. Motivation for GUE | 6. Motivation for GUE | |||
This section presents the motivation for GUE with respect to other | This section presents the motivation for GUE with respect to other | |||
encapsulation methods. | encapsulation methods. | |||
<!-- CEP: This section needs to be moved much closer to the beginning | ||||
of the document, perhaps just before Terminology. --> | ||||
6.1. Benefits of GUE | 6.1. Benefits of GUE | |||
* GUE is a generic encapsulation protocol. GUE can encapsulate | * GUE is a generic encapsulation protocol. GUE can encapsulate | |||
protocols that are represented by an IP protocol number. This | protocols that are represented by an IP protocol number. | |||
includes layer 2, layer 3, and layer 4 protocols. | ||||
* GUE is an extensible encapsulation protocol. Standardized | * GUE is an extensible encapsulation protocol. Standardized | |||
optional data such as security, virtual networking identifiers, | optional data such as security, virtual networking identifiers, | |||
fragmentation are being defined. | fragmentation are being defined. | |||
<!-- CEP: citations requested. --> | ||||
* For extensilbity, GUE uses flag fields as opposed to TLVs as | * For extensibility, GUE uses flag fields as opposed to TLVs as | |||
some other encapsulation protocols do. Flag fields are strictly | some other encapsulation protocols do. Flag fields are strictly | |||
ordered, allow random access, and are efficient in use of header | ordered, allow random access, and are efficient in use of header | |||
space. | space. | |||
* GUE allows private data to be sent as part of the encapsulation. | * GUE allows private data to be sent as part of the encapsulation. | |||
This permits experimentation or customization in deployment. | This permits experimentation or customization in deployment. | |||
* GUE allows sending of control messages such as OAM using the | * GUE allows sending of control messages such as OAM using the | |||
same GUE header format (for routing purposes) as normal data | same GUE header format (for routing purposes) as normal data | |||
messages. | messages. | |||
* GUE maximizes deliverability of non-UDP and non-TCP protocols. | * GUE maximizes deliverability of non-UDP and non-TCP protocols. | |||
<!-- CEP: This claim relies on the assumption the intermediate | ||||
routing points are happy with random UDP payloads. --> | ||||
* GUE provides a means for exposing per flow entropy for ECMP for | * GUE provides a means for exposing per flow entropy for ECMP for | |||
atypical protocols such as SCTP, DCCP, ESP, etc. | atypical protocols such as SCTP, DCCP, ESP, etc. | |||
6.2 Comparison of GUE to other encapsulations | 6.2 Comparison of GUE to other encapsulations | |||
<!-- CEP: This section also belongs much earlier in the document. --> | ||||
A number of different encapsulation techniques have been proposed for | A number of different encapsulation techniques have been proposed for | |||
the encapsulation of one protocol over another. EtherIP [RFC3378] | the encapsulation of one protocol over another. EtherIP [RFC3378] | |||
provides layer 2 tunneling of Ethernet frames over IP. GRE [RFC2784], | provides tunneling of Ethernet frames over IP. GRE [RFC2784], | |||
MPLS [RFC4023], and L2TP [RFC2661] provide methods for tunneling | MPLS [RFC4023], and L2TP [RFC2661] provide methods for tunneling | |||
layer 2 and layer 3 packets over IP. NVGRE [RFC7637] and VXLAN | layer 2 and layer 3 packets over IP. NVGRE [RFC7637] and VXLAN | |||
[RFC7348] are proposals for encapsulation of layer 2 packets for | [RFC7348] are proposals for encapsulation of layer 2 packets for | |||
network virtualization. IPIP [RFC2003] and Generic packet tunneling | network virtualization. IPIP [RFC2003] and Generic packet tunneling | |||
in IPv6 [RFC2473] provide methods for tunneling IP packets over IP. | in IPv6 [RFC2473] provide methods for tunneling IP packets over IP. | |||
Several proposals exist for encapsulating packets over UDP including | Several proposals exist for encapsulating packets over UDP including | |||
ESP over UDP [RFC3948], TCP directly over UDP [TCPUDP], VXLAN | ESP over UDP [RFC3948], TCP directly over UDP [TCPUDP], VXLAN | |||
[RFC7348], LISP [RFC6830] which encapsulates layer 3 packets, | [RFC7348], LISP [RFC6830] which encapsulates layer 3 packets, | |||
MPLS/UDP [RFC7510], GENEVE [GENEVE], and GRE-in-UDP Encapsulation | MPLS/UDP [RFC7510], GENEVE [GENEVE], and GRE-in-UDP Encapsulation | |||
[RFC8086]. | [RFC8086]. | |||
GUE has the following discriminating features: | GUE has the following discriminating features: | |||
o UDP encapsulation leverages specialized network device | o UDP encapsulation leverages specialized network device | |||
processing for efficient transport. The semantics for using the | processing for efficient transport. The semantics for using the | |||
UDP source port for flow entropy as input to ECMP are defined in | UDP source port for flow entropy as input to ECMP are defined in | |||
section 5.11. | section 5.11. | |||
o GUE permits encapsulation of arbitrary IP protocols, which | o GUE permits encapsulation of arbitrary IP protocols. | |||
includes layer 2 3, and 4 protocols. | ||||
o Multiple protocols can be multiplexed over a single UDP port | o Multiple protocols can be multiplexed over a single UDP port | |||
number. This is in contrast to techniques to encapsulate | number. This is in contrast to techniques to encapsulate | |||
protocols over UDP using a protocol specific port number (such | protocols over UDP using a protocol specific port number (such | |||
as ESP/UDP, GRE/UDP, SCTP/UDP). GUE provides a uniform and | as ESP/UDP, GRE/UDP, SCTP/UDP). GUE provides a uniform and | |||
extensible mechanism for encapsulating all IP protocols in UDP | extensible mechanism for encapsulating all IP protocols in UDP | |||
with minimal overhead (four bytes of additional header). | with minimal overhead (as few as four bytes of additional header). | |||
o GUE is extensible. New flags and extension fields can be | o GUE is extensible. New flags and extension fields can be | |||
defined. | defined. | |||
o The GUE header includes a header length field. This allows a | o The GUE header includes a header length field. This allows a | |||
network node to inspect an encapsulated packet without needing | network node to inspect an encapsulated packet without needing | |||
to parse the full encapsulation header. | to parse the full encapsulation header. | |||
o Private data in the encapsulation header allows local | o Private data in the encapsulation header allows local | |||
customization and experimentation while being compatible with | customization and experimentation while being compatible with | |||
processing in network nodes (routers and middleboxes). | processing in network nodes (routers and middleboxes). | |||
o GUE includes both data messages (encapsulation of packets) and | o GUE includes both data messages (encapsulation of packets) and | |||
control messages (such as OAM). | control messages (such as OAM). | |||
o The flags-field model facilitates efficient implementation of | o The flags-field model facilitates efficient implementation of | |||
extensibility in hardware. For instance, a TCAM can be use to | extensibility in hardware. For instance, a TCAM can be used to | |||
parse a known set of N flags where the number of entries in the | parse a known set of N flags where the number of entries in the | |||
TCAM is 2^N. By comparison, the number of TCAM entries needed to | TCAM is 2^N. By comparison, the number of TCAM entries needed to | |||
parse a set of N arbitrarily ordered TLVS is approximately e*N!. | parse a set of N arbitrarily ordered TLVS is approximately e*N!. | |||
o GUE includes a variant that encapsulates IPv4 and IPv6 packets | o GUE includes a variant that encapsulates IPv4 and IPv6 packets | |||
directly within UDP. | directly within UDP. | |||
7. Security Considerations | 7. Security Considerations | |||
There are two important considerations of security with respect to | There are two important considerations of security with respect to | |||
GUE. | GUE. | |||
o Authentication and integrity of the GUE header. | o Authentication and integrity of the GUE header. | |||
o Authentication, integrity, and confidentiality of the GUE | o Authentication, integrity, and confidentiality of the GUE | |||
payload. | payload. | |||
GUE security is provided by extensions for security defined in | GUE security is provided by extensions for security defined in | |||
[GUEEXTEN]. These extensions include methods to authenticate the GUE | [GUEEXTEN]. These extensions include methods to authenticate the GUE | |||
header and encrypt the GUE payload. | header and encrypt the GUE payload. | |||
<!-- CEP: Please explain why GUE requires yet another mechanism. --> | ||||
The GUE header can be authenticated using a security extension for an | The GUE header can be authenticated using a security extension for an | |||
HMAC. Securing the GUE payload can be accomplished use of the GUE | HMAC. Securing the GUE payload can be accomplished use of the GUE | |||
Payload Transform. This extension can be used to perform DTLS in the | Payload Transform. This extension can be used to perform DTLS in the | |||
payload of a GUE packet to encrypt the payload. | payload of a GUE packet to encrypt the payload. | |||
A hash function for computing flow entropy (section 5.11) SHOULD be | A hash function for computing flow entropy (section 5.11) SHOULD be | |||
randomly seeded to mitigate some possible denial service attacks. | randomly seeded to mitigate some possible denial service attacks. | |||
<!-- CEP: Citation needed for "possible" and for how a random seed | ||||
deters them. --> | ||||
8. IANA Considerations | 8. IANA Considerations | |||
8.1. UDP source port | 8.1. UDP source port | |||
A user UDP port number assignment for GUE has been assigned: | A user UDP port number assignment for GUE has been assigned: | |||
Service Name: gue | Service Name: gue | |||
Transport Protocol(s): UDP | Transport Protocol(s): UDP | |||
Assignee: Tom Herbert <tom@herbertland.com> | Assignee: Tom Herbert <tom@herbertland.com> | |||
skipping to change at page 33, line 30 ¶ | skipping to change at page 33, line 30 ¶ | |||
Generic Network Virtualization Encapsulation", draft-ietf- | Generic Network Virtualization Encapsulation", draft-ietf- | |||
nvo3-geneve-05 | nvo3-geneve-05 | |||
[LCO] Cree, E., https://www.kernel.org/doc/Documentation/ | [LCO] Cree, E., https://www.kernel.org/doc/Documentation/ | |||
networking/checksum-offloads.txt | networking/checksum-offloads.txt | |||
Appendix A: NIC processing for GUE | Appendix A: NIC processing for GUE | |||
This appendix provides some guidelines for Network Interface Cards | This appendix provides some guidelines for Network Interface Cards | |||
(NICs) to implement common offloads and accelerations to support GUE. | (NICs) to implement common offloads and accelerations to support GUE. | |||
Note that most of this discussion is generally applicable to other | Most of this discussion is generally applicable to other | |||
methods of UDP based encapsulation. | methods of UDP based encapsulation. | |||
<!-- CEP: The last sentence means these discussions do not belong here.--> | ||||
A.1. Receive multi-queue | A.1. Receive multi-queue | |||
Contemporary NICs support multiple receive descriptor queues (multi- | Contemporary NICs support multiple receive descriptor queues (multi- | |||
queue). Multi-queue enables load balancing of network processing for | queue). Multi-queue enables load balancing of network processing for | |||
a NIC across multiple CPUs. On packet reception, a NIC selects the | a NIC across multiple CPUs. On packet reception, a NIC selects the | |||
appropriate queue for host processing. Receive Side Scaling is a | appropriate queue for host processing. Receive Side Scaling is a | |||
common method which uses the flow hash for a packet to index an | common method which uses the flow hash for a packet to index an | |||
indirection table where each entry stores a queue number. Flow | indirection table where each entry stores a queue number. Flow | |||
Director and Accelerated Receive Flow Steering (aRFS) allow a host to | Director and Accelerated Receive Flow Steering (aRFS) allow a host to | |||
program the queue that is used for a given flow which is identified | program the queue that is used for a given flow which is identified | |||
either by an explicit five-tuple or by the flow's hash. | either by an explicit five-tuple or by the flow's hash. | |||
<!-- CEP: citations needed for RSS, aRFS, etc. --> | ||||
GUE encapsulation is compatible with multi-queue NICs that support | GUE encapsulation is compatible with multi-queue NICs that support | |||
five-tuple hash calculation for UDP/IP packets as input to RSS. The | five-tuple hash calculation for UDP/IP packets as input to RSS. The | |||
flow entropy in the UDP source port ensures classification of the | flow entropy in the UDP source port ensures classification of the | |||
encapsulated flow even in the case that the outer source and | encapsulated flow even in the case that the outer source and | |||
destination addresses are the same for all flows (e.g. all flows are | destination addresses are the same for all flows (e.g. all flows are | |||
going over a single tunnel). | going over a single tunnel). | |||
By default, UDP RSS support is often disabled in NICs to avoid out- | By default, UDP RSS support is often disabled in NICs to avoid out- | |||
of-order reception that can occur when UDP packets are fragmented. As | of-order reception that can occur when UDP packets are fragmented. As | |||
<!-- CEP: citation needed for this claim. --> | ||||
<!-- CEP: should explain why fragmented packets cause reordering. --> | ||||
discussed above, fragmentation of GUE packets is mostly avoided by | discussed above, fragmentation of GUE packets is mostly avoided by | |||
fragmenting packets before entering a tunnel, GUE fragmentation, path | fragmenting packets before entering a tunnel, GUE fragmentation, path | |||
<!-- CEP: This makes the case for specifying GUE fragmentation as part | ||||
of this document. --> | ||||
MTU discovery in higher layer protocols, or operator adjusting MTUs. | MTU discovery in higher layer protocols, or operator adjusting MTUs. | |||
Other UDP traffic might not implement such procedures to avoid | Other UDP traffic might not implement such procedures to avoid | |||
fragmentation, so enabling UDP RSS support in the NIC might be a | fragmentation, so enabling UDP RSS support in the NIC might be a | |||
considered tradeoff during configuration. | considered tradeoff during configuration. | |||
A.2. Checksum offload | A.2. Checksum offload | |||
Many NICs provide capabilities to calculate standard ones complement | Many NICs provide capabilities to calculate standard ones complement | |||
payload checksum for packets in transmit or receive. When using GUE | payload checksum for packets in transmit or receive. When using GUE | |||
encapsulation, there are at least two checksums that are of interest: | encapsulation, there are at least two checksums that are of interest: | |||
skipping to change at page 34, line 28 ¶ | skipping to change at page 34, line 32 ¶ | |||
the outer header. | the outer header. | |||
A.2.1. Transmit checksum offload | A.2.1. Transmit checksum offload | |||
NICs can provide a protocol agnostic method to offload transmit | NICs can provide a protocol agnostic method to offload transmit | |||
checksum (NETIF_F_HW_CSUM in Linux parlance) that can be used with | checksum (NETIF_F_HW_CSUM in Linux parlance) that can be used with | |||
GUE. In this method, the host provides checksum related parameters in | GUE. In this method, the host provides checksum related parameters in | |||
a transmit descriptor for a packet. These parameters include the | a transmit descriptor for a packet. These parameters include the | |||
starting offset of data to checksum, the length of data to checksum, | starting offset of data to checksum, the length of data to checksum, | |||
and the offset in the packet where the computed checksum is to be | and the offset in the packet where the computed checksum is to be | |||
written. The host initializes the checksum field to pseudo header | written. The host initializes the checksum field to a pseudo header | |||
checksum. | checksum. | |||
In the case of GUE, the checksum for an encapsulated transport layer | In the case of GUE, the checksum for an encapsulated transport layer | |||
packet, a TCP packet for instance, can be offloaded by setting the | packet, a TCP packet for instance, can be offloaded by setting the | |||
appropriate checksum parameters. | appropriate checksum parameters. | |||
NICs typically can offload only one transmit checksum per packet, so | NICs typically can offload only one transmit checksum per packet, so | |||
simultaneously offloading both an inner transport packet's checksum | simultaneously offloading both an inner transport packet's checksum | |||
and the outer UDP checksum is likely not possible. | and the outer UDP checksum is likely not possible. | |||
skipping to change at page 35, line 40 ¶ | skipping to change at page 35, line 40 ¶ | |||
for the outer UDP header in an encapsulation, checksum conversion can | for the outer UDP header in an encapsulation, checksum conversion can | |||
be done so that the checksum-complete value is derived and can be | be done so that the checksum-complete value is derived and can be | |||
used by the stack to validate checksums in the encapsulated packet. | used by the stack to validate checksums in the encapsulated packet. | |||
A.3. Transmit Segmentation Offload | A.3. Transmit Segmentation Offload | |||
Transmit Segmentation Offload (TSO) is a NIC feature where a host | Transmit Segmentation Offload (TSO) is a NIC feature where a host | |||
provides a large (>MTU size) TCP packet to the NIC, which in turn | provides a large (>MTU size) TCP packet to the NIC, which in turn | |||
splits the packet into separate segments and transmits each one. This | splits the packet into separate segments and transmits each one. This | |||
is useful to reduce CPU load on the host. | is useful to reduce CPU load on the host. | |||
<!-- CEP: Citations needed! --> | ||||
The process of TSO can be generalized as: | The process of TSO can be generalized as: | |||
- Split the TCP payload into segments which allow packets with | - Split the TCP payload into segments which allow packets with | |||
size less than or equal to MTU. | size less than or equal to MTU. | |||
- For each created segment: | - For each created segment: | |||
1. Replicate the TCP header and all preceding headers of the | 1. Replicate the TCP header and all preceding headers of the | |||
original packet. | original packet. | |||
2. Set payload length fields in any headers to reflect the | 2. Set payload length fields in any headers to reflect the | |||
length of the segment. | length of the segment. | |||
3. Set TCP sequence number to correctly reflect the offset of | 3. Set TCP sequence number to correctly reflect the offset of | |||
the TCP data in the stream. | the TCP data in the stream. | |||
<!-- CEP: This might conflict with the TCP sequence number chosen by | ||||
the TCP layer actually creating the segments. --> | ||||
4. Recompute and set any checksums that either cover the payload | 4. Recompute and set any checksums that either cover the payload | |||
of the packet or cover header which was changed by setting a | of the packet or cover header which was changed by setting a | |||
payload length. | payload length. | |||
Following this general process, TSO can be extended to support TCP | Following this general process, TSO can be extended to support TCP | |||
encapsulation in GUE. For each segment the Ethernet, outer IP, UDP | encapsulation in GUE. For each segment the Ethernet, outer IP, UDP | |||
header, GUE header, inner IP header (if tunneling), and TCP headers | header, GUE header, inner IP header (if tunneling), and TCP headers | |||
are replicated. Any packet length header fields need to be set | are replicated. Any packet length header fields need to be set | |||
properly (including the length in the outer UDP header), and | properly (including the length in the outer UDP header), and | |||
checksums need to be set correctly (including the outer UDP checksum | checksums need to be set correctly (including the outer UDP checksum | |||
if being used). | if being used). | |||
To facilitate TSO with GUE, it is recommended that extension fields | To facilitate TSO with GUE, it is recommended that extension fields | |||
do not contain values that need to be updated on a per segment basis. | do not contain values that need to be updated on a per segment basis. | |||
For example, extension fields should not include checksums, lengths, | For example, extension fields should not include checksums, lengths, | |||
or sequence numbers that refer to the payload. If the GUE header does | or sequence numbers that refer to the payload. If the GUE header does | |||
not contain such fields then the TSO engine only needs to copy the | not contain such fields then the TSO engine only needs to copy the | |||
bits in the GUE header when creating each segment and does not need | bits in the GUE header when creating each segment and does not need | |||
to parse the GUE header. | to parse the GUE header. | |||
<!-- CEP: This makes appendix A.4 normative. And if it's normative, it | ||||
really needs to be in the main body of the text. --> | ||||
A.4. Large Receive Offload | A.4. Large Receive Offload | |||
Large Receive Offload (LRO) is a NIC feature where packets of a TCP | Large Receive Offload (LRO) is a NIC feature where packets of a TCP | |||
connection are reassembled, or coalesced, in the NIC and delivered to | connection are reassembled, or coalesced, in the NIC and delivered to | |||
the host as one large packet. This feature can reduce CPU utilization | the host as one large packet. This feature can reduce CPU utilization | |||
in the host. | in the host. | |||
<!-- CEP: Citations needed! --> | ||||
LRO requires significant protocol awareness to be implemented | LRO requires significant protocol awareness to be implemented | |||
correctly and is difficult to generalize. Packets in the same flow | correctly and is difficult to generalize. Packets in the same flow | |||
need to be unambiguously identified. In the presence of tunnels or | need to be unambiguously identified. In the presence of tunnels or | |||
network virtualization, this may require more than a five-tuple match | network virtualization, this may require more than a five-tuple match | |||
(for instance packets for flows in two different virtual networks may | (for instance packets for flows in two different virtual networks may | |||
have identical five-tuples). Additionally, a NIC needs to perform | have identical five-tuples). Additionally, a NIC needs to perform | |||
validation over packets that are being coalesced, and needs to | validation over packets that are being coalesced, and needs to | |||
fabricate a single meaningful header from all the coalesced packets. | fabricate a single meaningful header from all the coalesced packets. | |||
The conservative approach to supporting LRO for GUE would be to | The conservative approach to supporting LRO for GUE would be to | |||
assign packets to the same flow only if they have identical five- | assign packets to the same flow only if they have identical five- | |||
tuple and were encapsulated the same way. That is the outer IP | tuple and were encapsulated the same way. That is the outer IP | |||
addresses, the outer UDP ports, GUE protocol, GUE flags and fields, | addresses, the outer UDP ports, GUE protocol, GUE flags and fields, | |||
and inner five tuple are all identical. | and inner five tuple are all identical. | |||
<!-- CEP: sounds like this ought to be deleted. --> | ||||
Appendix B: Implementation considerations | Appendix B: Implementation considerations | |||
This appendix is informational and does not constitute a normative | This appendix is informational and does not constitute a normative | |||
part of this document. | part of this document. | |||
B.1. Priveleged ports | B.1. Privileged ports | |||
Using the source port to contain a flow entropy value disallows the | Using the source port to contain a flow entropy value disallows the | |||
security method of a receiver enforcing that the source port be a | security method of a receiver enforcing that the source port be a | |||
privileged port. Privileged ports are defined by some operating | privileged port. Privileged ports are defined by some operating | |||
systems to restrict source port binding. Unix, for instance, | systems to restrict source port binding. Unix, for instance, | |||
considered port number less than 1024 to be privileged. | considered port number less than 1024 to be privileged. | |||
Enforcing that packets are sent from a privileged port is widely | Enforcing that packets are sent from a privileged port is widely | |||
considered an inadequate security mechanism and has been mostly | considered an inadequate security mechanism and has been mostly | |||
deprecated. To approximate this behavior, an implementation could | deprecated. | |||
<!-- CEP: citation needed. --> | ||||
To approximate this behavior, an implementation could | ||||
restrict a user from sending a packet destined to the GUE port | restrict a user from sending a packet destined to the GUE port | |||
without proper credentials. | without proper credentials. | |||
<!-- CEP: this is not at all specific to GUE. --> | ||||
B.2. Setting flow entropy as a route selector | B.2. Setting flow entropy as a route selector | |||
An encapsulator generating flow entropy in the UDP source port could | An encapsulator generating flow entropy in the outer UDP source port could | |||
modulate the value to perform a type of multipath source routing. | modulate the value to perform a type of multipath source routing. | |||
Assuming that networking switches perform ECMP based on the flow | Assuming that networking switches perform ECMP based on the flow | |||
hash, a sender can affect the path by altering the flow entropy. For | hash, a sender can affect the path by altering the flow entropy. For | |||
instance, a host can store a flow hash in its protocol control block | instance, a host can store a flow hash in its protocol control block | |||
(PCB) for an inner flow, and might alter the value upon detecting | (PCB) for an inner flow, and might alter the value upon detecting | |||
that packets are traversing a lossy path. Changing the flow entropy | that packets are traversing a lossy path. Changing the flow entropy | |||
for a flow SHOULD be subject to hysteresis (at most once every thirty | for a flow SHOULD be subject to hysteresis (at most once every thirty | |||
seconds) to limit the number of out of order packets. | seconds) to limit the number of out of order packets. | |||
<!-- CEP: If the appendix is not normative, it cannot place mandates.--> | ||||
B.3. Hardware protocol implementation considerations | B.3. Hardware protocol implementation considerations | |||
Low level data path protocols, such is GUE, are often supported in | Low level data path protocols, such as GUE, are often supported in | |||
high speed network device hardware. Variable length header (VLH) | high speed network device hardware. Variable length header (VLH) | |||
protocols like GUE are often considered difficult to efficiently | protocols like GUE are often considered difficult to efficiently | |||
implement in hardware. In order to retain the important | implement in hardware. In order to retain the important | |||
characteristics of an extensible and robust protocol, hardware | characteristics of an extensible and robust protocol, hardware | |||
vendors may practice "constrained flexibility". In this model, only | vendors may practice "constrained flexibility". In this model, only | |||
certain combinations or protocol header parameterizations are | certain combinations or protocol header parameterizations are | |||
implemented in hardware fast path. Each such parameterization is | implemented in hardware fast path. Each such parameterization is | |||
fixed length so that the particular instance can be optimized as a | fixed length so that the particular instance can be optimized as a | |||
fixed length protocol. In the case of GUE this constitutes specific | fixed length protocol. In the case of GUE this constitutes specific | |||
combinations of GUE flags, fields, and next protocol. The selected | combinations of GUE flags, fields, and next protocol. The selected | |||
combinations would naturally be the most common cases which form the | combinations would naturally be the most common cases which form the | |||
"fast path", and other combinations are assumed to take the "slow | "fast path", and other combinations are assumed to take the "slow | |||
path". | path". | |||
In time, needs and requirements of the protocol may change which may | In time, needs and requirements of the protocol may change which may | |||
manifest themselves as new parameterizations to be supported in the | manifest themselves as new parameterizations to be supported in the | |||
fast path. To allow this extensibility, a device practicing | fast path. To allow this extensibility, a device practicing | |||
constrained flexibility should allow the fast path parameterizations | constrained flexibility should allow the fast path parameterizations | |||
to be programmable. | to be programmable. | |||
<!-- CEP: This appendix is very generic and could be deleted without | ||||
harm. --> | ||||
Authors' Addresses | Authors' Addresses | |||
Tom Herbert | Tom Herbert | |||
Quantonium | Quantonium | |||
4701 Patrick Henry | 4701 Patrick Henry | |||
Santa Clara, CA 95054 | Santa Clara, CA 95054 | |||
US | US | |||
Email: tom@herbertland.com | Email: tom@herbertland.com | |||
Lucy Yong | Lucy Yong | |||
Huawei USA | Huawei USA | |||
<!-- CEP: Lucy Yong is no longer a Huawei employee. I suggest | ||||
moving her name to a Contributors section. --> | ||||
5340 Legacy Dr. | 5340 Legacy Dr. | |||
Plano, TX 75024 | Plano, TX 75024 | |||
US | US | |||
Email: lucy.yong@huawei.com | Email: lucy.yong@huawei.com | |||
Osama Zia | Osama Zia | |||
Microsoft | Microsoft | |||
1 Microsoft Way | 1 Microsoft Way | |||
Redmond, WA 98029 | Redmond, WA 98029 | |||
End of changes. 114 change blocks. | ||||
81 lines changed or deleted | 199 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |