draft-ietf-intarea-gue-02.txt   draft-ietf-intarea-gue-03.txt 
Internet Area WG T. Herbert Internet Area WG T. Herbert
Internet-Draft Quantonium Internet-Draft Quantonium
Intended status: Standard track L. Yong Intended status: Standard track L. Yong
Expires October 28, 2017 Huawei USA Expires November 11, 2017 Huawei USA
O. Zia O. Zia
Microsoft Microsoft
April 26, 2017 May 10, 2017
Generic UDP Encapsulation Generic UDP Encapsulation
draft-ietf-intarea-gue-02 draft-ietf-intarea-gue-03
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 28, 2017. This Internet-Draft will expire on November 11, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 4, line 18 skipping to change at page 4, line 18
5.9. Congestion control . . . . . . . . . . . . . . . . . . . . 21 5.9. Congestion control . . . . . . . . . . . . . . . . . . . . 21
5.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 22 5.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 22
5.11. Flow entropy for ECMP . . . . . . . . . . . . . . . . . . 22 5.11. Flow entropy for ECMP . . . . . . . . . . . . . . . . . . 22
5.11.1. Flow classification . . . . . . . . . . . . . . . . . 22 5.11.1. Flow classification . . . . . . . . . . . . . . . . . 22
5.11.2. Flow entropy properties . . . . . . . . . . . . . . . 23 5.11.2. Flow entropy properties . . . . . . . . . . . . . . . 23
5.12 Negotiation of acceptable flags and extension fields . . . 24 5.12 Negotiation of acceptable flags and extension fields . . . 24
6. Motivation for GUE . . . . . . . . . . . . . . . . . . . . . . 24 6. Motivation for GUE . . . . . . . . . . . . . . . . . . . . . . 24
6.1. Benefits of GUE . . . . . . . . . . . . . . . . . . . . . . 24 6.1. Benefits of GUE . . . . . . . . . . . . . . . . . . . . . . 24
6.2 Comparison of GUE to other encapsulations . . . . . . . . . 25 6.2 Comparison of GUE to other encapsulations . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 26
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27
8.1. UDP source port . . . . . . . . . . . . . . . . . . . . . . 27 8.1. UDP source port . . . . . . . . . . . . . . . . . . . . . . 27
8.2. GUE version number . . . . . . . . . . . . . . . . . . . . 28 8.2. GUE version number . . . . . . . . . . . . . . . . . . . . 28
8.3. Control types . . . . . . . . . . . . . . . . . . . . . . . 28 8.3. Control types . . . . . . . . . . . . . . . . . . . . . . . 28
8.4. Flag-fields . . . . . . . . . . . . . . . . . . . . . . . . 28 8.4. Flag-fields . . . . . . . . . . . . . . . . . . . . . . . . 28
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
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
skipping to change at page 5, line 27 skipping to change at page 5, line 27
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 potentially covers 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. 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. This document does not define any specific GUE extensions.
[GUEEXTENS] specifies a set of core extensions and [GUE4NVO3] defines [GUEEXTENS] specifies a set of core extensions.
an extension for using GUE with network virtualization.
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
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
skipping to change at page 9, line 12 skipping to change at page 9, line 12
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 32-bit 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 the header. Computed as (header_len - 4) / 4 where header_len is the
total header length in bytes. All GUE headers are a multiple of total header length in bytes. All GUE headers are a multiple of
four bytes in length. Maximum header length is 128 bytes. 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 C-bit control message type for the payload (section 3.2.2). When the
is not set, the field holds the Internet protocol number for the C-bit is not set, the field holds the Internet protocol number
encapsulated packet in the payload (section 3.2.1). The control for the encapsulated packet in the payload (section 3.2.1). The
message or encapsulated packet begins at the offset provided by control message or encapsulated packet begins at the offset
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 that last
skipping to change at page 10, line 50 skipping to change at page 10, line 50
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 a basic set of GUE extensions. [GUEXTENS] defines a basic set of GUE extensions.
3.3.1. Requirements 3.3.1. Requirements
There are sixteen flag bits in the GUE header. Some flags 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 fixed.
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.
skipping to change at page 11, line 38 skipping to change at page 11, line 38
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.
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 VNID and Security extension fields (both defined and containing the Group Identifier and Security extension fields
in [GUEXTENS]) is shown below: (both defined in [GUEXTENS]) 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VNID | | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Security + + Security +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 VNID extension is present which is a 32 bit field. The second the Group Identifier extension is present which is a 32 bit field.
through fourth bits of the flags are paired flags that indicate the The second through fourth bits of the flags are paired flags that
presence of a security field with seven possible sizes. In this indicate the presence of a Security field with seven possible sizes.
example 001 indicates a sixty-four bit security field. In this example 001 indicates a sixty-four bit security field.
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. 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:
skipping to change at page 16, line 34 skipping to change at page 16, line 34
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.
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. 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 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].
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,
skipping to change at page 17, line 32 skipping to change at page 17, line 32
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. No error message is returned and rate limiting of logging messages. No error message is returned
back to the encapsulator. Note that set flags in a GUE header that back to the encapsulator. Note that set flags in a GUE header that
are unknown to a decapsulator MUST NOT be ignored. If a GUE packet is are unknown to a decapsulator MUST NOT be ignored. If a GUE packet is
received by a decapsulator with unknown flags, the packet MUST be received by a decapsulator with unknown flags, the packet MUST be
dropped. dropped.
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 headers are removed from If a valid data message is received, the UDP header and GUE header
the packet. The outer IP header remains intact and the next protocol are removed from the packet. The outer IP header remains intact and
in the IP header is set to the protocol from the proto field in the the next protocol in the IP header is set to the protocol from the
GUE header. The resulting packet is then resubmitted into the proto field in the GUE header. The resulting packet is then
protocol stack to process that packet as though it was received with resubmitted into the protocol stack to process that packet as though
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 IP packet. In this case proto field in the GUE header encapsulates an IP packet. In this case proto field in the GUE header
is set 94 for IPIP: is set 94 for IPIP:
+-------------------------------------+ +-------------------------------------+
| IP header (next proto = 17,UDP) | | IP header (next proto = 17,UDP) |
|-------------------------------------| |-------------------------------------|
| UDP | | UDP |
|-------------------------------------| |-------------------------------------|
skipping to change at page 20, line 36 skipping to change at page 20, line 36
described in [GUEEXTENS] assuming there are no other mechanisms used described in [GUEEXTENS] assuming there are no other mechanisms used
to protect the GUE packet. to protect the GUE packet.
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 sending over paths subject to packet corruption. If verification be traversing paths subject to packet corruption. If verification of
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 was verify a non-zero checksum, or a packet with a zero-checksum was
received and the decapsulator is configured to disallow, the packet received and the decapsulator is configured to disallow, the packet
MUST be dropped. MUST be dropped.
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
skipping to change at page 25, line 38 skipping to change at page 25, line 38
provides layer 2 tunneling of Ethernet frames over IP. GRE [RFC2784], provides layer 2 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 [7510], and Generic UDP Encapsulation for IP Tunneling (GRE MPLS/UDP [RFC7510], and Generic UDP Encapsulation for IP Tunneling
over UDP)[RFC8086]. Generic UDP tunneling [GUT] is a proposal similar (GRE over UDP)[RFC8086]. Generic UDP tunneling [GUT] is a proposal
to GUE in that it aims to tunnel packets of IP protocols over UDP. similar to GUE in that it aims to tunnel packets of IP protocols over
UDP.
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, which
includes layer 2 3, and 4 protocols. includes layer 2 3, and 4 protocols.
skipping to change at page 26, line 32 skipping to change at page 26, line 32
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. extensibility in hardware.
For instance a TCAM can be use to parse a known set of N flags For instance a TCAM can be use to parse a known set of N flags
where the number of entries in the TCAM is 2^N. where the number of entries in the TCAM is 2^N.
For comparison, the number of TCAM entries needed to parse a set By comparison, the number of TCAM entries needed to parse a set
of N arbitrarily ordered TLVS is approximately e*N!. of N arbitrarily ordered TLVS is approximately e*N!.
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
skipping to change at page 27, line 8 skipping to change at page 27, line 8
header and encrypt the GUE payload. header and encrypt the GUE payload.
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.
8. IANA Consideration 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>
Contact: Tom Herbert <tom@herbertland.com> Contact: Tom Herbert <tom@herbertland.com>
Description: Generic UDP Encapsulation Description: Generic UDP Encapsulation
skipping to change at page 29, line 8 skipping to change at page 29, line 8
IANA is requested to create a "GUE flag-fields" registry to allocate IANA is requested to create a "GUE flag-fields" registry to allocate
flags and extension fields used with GUE. This shall be a registry of flags and extension fields used with GUE. This shall be a registry of
bit assignments for flags, length of extension fields for bit assignments for flags, length of extension fields for
corresponding flags, and descriptive strings. There are sixteen bits corresponding flags, and descriptive strings. There are sixteen bits
for primary GUE header flags (bit number 0-15). New values are for primary GUE header flags (bit number 0-15). New values are
assigned in accordance with RFC Required policy [RFC5226]. assigned in accordance with RFC Required policy [RFC5226].
+-------------+--------------+-------------+--------------------+ +-------------+--------------+-------------+--------------------+
| Flags bits | Field size | Description | Reference | | Flags bits | Field size | Description | Reference |
+-------------+--------------+-------------+--------------------+ +-------------+--------------+-------------+--------------------+
| Bit 0 | 4 bytes | VNID | [GUE4NVO3] | | Bit 0 | 4 bytes | Group | [GUEEXTENS] |
| | | identifier | |
| | | | | | | | | |
| Bit 1..3 | 001->8 bytes | Security | [GUEEXTENS] | | Bit 1..3 | 001->8 bytes | Security | [GUEEXTENS] |
| | 010->16 bytes| | | | | 010->16 bytes| | |
| | 011->32 bytes| | | | | 011->32 bytes| | |
| | | | | | | | | |
| Bit 4 | 8 bytes | Fragmen- | [GUEEXTENS] | | Bit 4 | 8 bytes | Fragmen- | [GUEEXTENS] |
| | | tation | | | | | tation | |
| | | | | | | | | |
| Bit 5 | 4 bytes | Payload | [GUEEXTENS] | | Bit 5 | 4 bytes | Payload | [GUEEXTENS] |
| | | transform | | | | | transform | |
 End of changes. 18 change blocks. 
35 lines changed or deleted 36 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/