Internet DRAFT - draft-herbert-tsvwg-gte
draft-herbert-tsvwg-gte
Internet-Draft T. Herbert
Intended status: Standard track Quantonium
Expires March 31, 2019
September 27, 2018
Generic TCP Encapsulation
draft-herbert-tsvwg-gte-00
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 31, 2019.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Herbert Expires March, 2019 [Page 1]
Internet Draft Generic TCP Encapsulation September 27, 2018
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Herbert Expires March, 2019 [Page 2]
Internet Draft Generic TCP Encapsulation September 27, 2018
Abstract
This specification describes Generic TCP Encapsulation (GTE) which is
a method to encapsulate packets of different IP protocols within TCP
data streams. Encapsulating packets in TCP facilitates communications
across networks that block or sub-optimally handle non-TCP traffic.
GTE is an adaptation of Generic UDP Encapsulation (GUE) to work in
the context of TCP. GTE employs the GUE encapsulation format and
optional extensions.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Requirements Language . . . . . . . . . . . . . . . . . . . 5
2 Encapsulation format . . . . . . . . . . . . . . . . . . . . . 6
2.1 GTE messages in a TCP stream . . . . . . . . . . . . . . . . 6
2.2 TCP connections . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Encapsulation with GUE variant 0 . . . . . . . . . . . . . . 7
2.4 Encapsulation with GUE variant 1 . . . . . . . . . . . . . . 8
2.4.1 IPv4 direct encapsulation . . . . . . . . . . . . . . . 8
2.4.2 IPv6 direct encapsulation . . . . . . . . . . . . . . . 9
3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Encapsulation flavors . . . . . . . . . . . . . . . . . . . 9
3.1.1 Network layer encapsulation . . . . . . . . . . . . . . 9
3.1.2 Transport layer encapsulation . . . . . . . . . . . . . 10
3.2 Encapsulator operation . . . . . . . . . . . . . . . . . . . 11
3.3 Decapsulator operation . . . . . . . . . . . . . . . . . . . 11
3.3.1 Receiving network layer encapsulation . . . . . . . . . 11
3.3.2 Receiving transport layer encapsulation . . . . . . . . 12
3.3.3 Error handling . . . . . . . . . . . . . . . . . . . . . 13
3.4 Processing a received control message . . . . . . . . . . . 13
3.5 NAT interaction . . . . . . . . . . . . . . . . . . . . . . 13
3.6 Checksum offload of encapsulated transport checksum . . . . 13
3.6.1 Transmit checksum offload . . . . . . . . . . . . . . . 14
3.6.2 Receive checksum offload . . . . . . . . . . . . . . . . 14
3.7 GUE extensions . . . . . . . . . . . . . . . . . . . . . . . 14
3.8 Surplus area . . . . . . . . . . . . . . . . . . . . . . . . 14
4 GTE control messages . . . . . . . . . . . . . . . . . . . . . 15
4.1 Message length size . . . . . . . . . . . . . . . . . . . . 15
4.2 GUE header template . . . . . . . . . . . . . . . . . . . . 16
4.2.1 Header template validation . . . . . . . . . . . . . . . 17
4.2.2 Optional extensions in header templates . . . . . . . . 17
4.2.3 Processing received messages . . . . . . . . . . . . . . 18
4.3 Example of UDP over GTE . . . . . . . . . . . . . . . . . . 18
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 20
6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20
6.1 TCP port number . . . . . . . . . . . . . . . . . . . . . . 20
6.2 GUE control types . . . . . . . . . . . . . . . . . . . . . 20
Herbert Expires March, 2019 [Page 3]
Internet Draft Generic TCP Encapsulation September 27, 2018
6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Herbert Expires March, 2019 [Page 4]
Internet Draft Generic TCP Encapsulation September 27, 2018
1 Introduction
This specification describes Generic TCP Encapsulation (GTE) which is
a general method for encapsulating packets of arbitrary IP protocols
within Transport Control Protocol (TCP) [RFC0793] streams. The
motivation and basic requirements for encapsulating packets with TCP
are described in [TCPENCAP]. The primary motivation is to tunnel
packets over networks that either block or treat non-TCP traffic sub-
optimally. For instance, a real-time gaming application that uses UDP
may chose to encapsulate packets in TCP in order to traverse a
stateful firewall that only allows TCP.
GTE is an adaptation of Generic UDP Encapsulation [GUE] to
encapsulate packets in a TCP stream. Packets are encapsulated in GTE
messages. Each GTE message is composed of a message length, a GUE
header variant, and a GUE payload. The message length is needed to
demarcate messages in the TCP stream. The TCP data stream is then
composed of a sequence of GTE messages. The GUE header and protocol
in GTE messages are the same as that defined in GUE. Sender and
receiver processing is modified accordingly to take into account the
differences between TCP and UDP encapsulation. GTE defines an
optimization to compress out the GUE header in certain circumstances.
1.1 Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Herbert Expires March, 2019 [Page 5]
Internet Draft Generic TCP Encapsulation September 27, 2018
2 Encapsulation format
This section describes the encapsulation formats of Generic TCP
Encapsulation.
2.1 GTE messages in a TCP stream
A GTE message is encapsulated in a TCP stream. A message is comprised
of a message length field, a GUE header of one of the GUE variants,
and a payload which is either an encapsulated packet of some IP
protocol or a control message such as an OAM (Operations,
Administration, and Management) message. Encapsulation of GTE message
in TCP has the general format:
+-------------------------------+
| |
| TCP/IP header |
| |
|-------------------------------|
....
|-------------------------------|
| Message length |
|-------------------------------|
| |
| GUE Header |
| |
|-------------------------------|
| |
| Encapsulated packet |
| or control message |
| |
+-------------------------------+
....
A TCP stream is composed of a sequence of GUE messages. Each message
is prefixed by the length of the message for demarcation. Note that
there is no on-to-one correspondence between a GTE message and a TCP
segment. Multiple GTE messages may be in a single TCP segment, and a
single GTE message may span multiple TCP segments. Additionally,
there is no assumed alignment of GTE messages within a stream
The GUE header and encapsulation are defined in [GUE]. A GTE message
may carry variant 0 or variant 1 GUE packets. The formats are
detailed below.
Herbert Expires March, 2019 [Page 6]
Internet Draft Generic TCP Encapsulation September 27, 2018
2.2 TCP connections
A GTE stream is composed of GTE message. The message are sequential
and per the semantics of TCP they are processed in order.
+----------------+----------------+----------------|--------
| GTE message #1 | GTE message #2 | GTE message #3 | .... .
+----------------+----------------+----------------|--------
A default TCP port number (suggesting 6080) will be assigned to GTE.
A server may listen on this port number for incoming connections.
When a connection is established, the data stream is interpreted as a
sequence of GTE messages, so the first four bytes in the stream are
the length of the first GTE message.
GTE could also use an HTTP connection for the transport. This would
be done using the HTTP Upgrade header to specify use of GTE.
Specification of this is outside the scope of this document.
Transport Layer Security (TLS) can be used on the TCP stream. In this
case, the GTE messages are the plain text before TLS is applied. GTE
messages are processed on receive after TLS processing.
2.3 Encapsulation with GUE variant 0
Variant 0 of GUE defines a generic extensible format to encapsulate
packets by Internet protocol number. The format of a GTE message with
GUE variant 0 is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| 0 |C| Hlen | Proto/ctype | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G
| | U
~ Extensions Fields (optional) ~ E
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h
| | d
~ Private data (optional) ~ r
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
| |
~ GUE payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Herbert Expires March, 2019 [Page 7]
Internet Draft Generic TCP Encapsulation September 27, 2018
Fields:
o Message Length: Length of the GTE message not including the four
bytes of this field. The length is the sum of the GUE header
length and the length of the encapsulated GUE payload. The size
of the message length field may be changed using the Message
Length Size control message (section 4.1).
The GUE header fields are specified in [GUE] and GUE extensions are
describe in [GUEEXTEN].
2.4 Encapsulation with GUE variant 1
Variant 1 of GUE allows direct encapsulation of IPv4 and IPv6 packets
in GUE.
2.4.1 IPv4 direct encapsulation
A GTE message with direct encapsulation of an IPv4 packet has the
format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
|0|1|0|0| IHL |Type of Service| Total Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I
| Identification |Flags| Fragment Offset | P
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| Time to Live | Protocol | Header Checksum | 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Source IPv4 Address | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d
| Destination IPv4 Address | r
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
| |
~ IPv4 payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Herbert Expires March, 2019 [Page 8]
Internet Draft Generic TCP Encapsulation September 27, 2018
2.4.2 IPv6 direct encapsulation
A GTE message with direct encapsulation of an IPv6 packet has the
format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
|0|1|1|0| Traffic Class | Flow Label | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Payload Length | NextHdr | Hop Limit | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | I
+ + P
| | v
+ Source IPv6 Address + 6
| |
+ + h
| | d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r
| | |
+ + |
| | |
+ Destination IPv6 Address + |
| | |
+ + |
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
3 Operation
This section describes the operation of GTE.
3.1 Encapsulation flavors
GTE can do either network layer of transport layer encapsulation.
3.1.1 Network layer encapsulation
Network tunneling can be achieved by encapsulating layer 2 or layer 3
packets. In this case the encapsulator and decapsulator nodes are the
tunnel endpoints as well as the endpoints of the GTE TCP connection.
These could be routers providing tunnels on behalf of communicating
hosts.
Herbert Expires March, 2019 [Page 9]
Internet Draft Generic TCP Encapsulation September 27, 2018
The figure below illustrates the use of GTE network layer
encapsulation between two hosts.
+---------------+ +---------------+
| | | |
| Host 1 | | Host 2 |
| | | |
+---------------+ +---------------+
| ^
V |
+---------------+ +---------------+ +---------------+
| | | TCP | | |
| Encapsulator |-->| connection |-->| Decapsulator |
| | | | | |
+---------------+ +---------------+ +---------------+
Host 1 is sending packets to Host 2. An encapsulator performs
encapsulation of packets from Host 1. These encapsulated packets
traverse the network in a TCP stream. At the decapsulator, packets
are decapsulated and sent on to Host 2. GTE encapsulation is not
required the reverse direction.
3.1.2 Transport layer encapsulation
GTE can encapsulate transport layer packets such as UDP or TCP. The
encapsulated packets do not include their own IP header, instead the
IP header is inferred from the TCP connection.
The figure below illustrates the use of GTE transport layer
encapsulation between two hosts.
+---------------+ +---------------+ +---------------+
| | | TCP | | |
| Host 1 |-->| connection |-->| Host 2 |
| | | | | |
+---------------+ +---------------+ +---------------+
When encapsulating transport layer packets, the encapsulator and
decapsulator should be co-resident with the hosts. The encapsulated
transport layer packets are in a TCP stream. The corresponding IP
addresses of the endpoints of the TCP connection are taken to be the
endpoints of the encapsulated transport packet. Note that the
encapsulated transport layer packet is independent of the
encapsulating TCP headers, in particular, port numbers of the outer
TCP headers and encapsulated transport headers are independent.
Herbert Expires March, 2019 [Page 10]
Internet Draft Generic TCP Encapsulation September 27, 2018
3.2 Encapsulator operation
Encapsulators create GTE data messages, set flags and optional
extension fields in the GUE header, and forward packets to a
decapsulator by writing messages on a TCP data stream.
An encapsulator can be an end host originating the packets of a flow,
or can be a network device performing encapsulation on behalf of
hosts (routers implementing tunnels for instance). In either case,
the intended target (decapsulator) is the peer of the TCP connection.
If an encapsulator is tunneling packets -- that is encapsulating
packets of layer 2 or layer 3 protocols (e.g. EtherIP, IPIP, or ESP
tunnel mode) -- the propagation of network layer information, such as
ECN [RFC6040] and diff-serv [RFC2983] should be considered. Since
there is no one-to-one mapping between encapsulated packets and the
outer packet, the best way to map information may not be obvious. For
instance, two IP packets encapsulated in the same TCP segment may
have different diff-serv bits. An implementation MAY apply its own
configurable heuristics for tunneling of one protocol over another.
3.3 Decapsulator operation
If a complete GTE data message is received on a TCP stream, the
payload of the GTE message is logically extracted. An IP packet is
created with an IP header that is fabricated from the TCP connection
parameters. 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
resubmitted into the protocol stack to process as though it was
received with the protocol in the GUE header.
3.3.1 Receiving network layer encapsulation
Consider that a data message is received where GTE encapsulated an IP
packet. In this case, the proto field in the GUE header is set to 4.
+-------------------------------------+
| IP header (next proto = 6 TCP) |
|-------------------------------------|
| TCP header |
|-------------------------------------|
....
|-------------------------------------|
| GUE (proto = 4,IPv4 encapsulation) |
|-------------------------------------|
| IP header and packet |
+-------------------------------------+
....
Herbert Expires March, 2019 [Page 11]
Internet Draft Generic TCP Encapsulation September 27, 2018
The receiver extracts the IP header and payload, and encapsulates
that in an IP packet using IPIP encapsulation. The IP header is
derived from the TCP connection or IP header that was present in a
received TCP segment. The next protocol field is set to 4. The
resultant packet would have the format:
+-------------------------------------+
| IP header (next proto = 4,IPv4) |
|-------------------------------------|
| IP header and packet |
+-------------------------------------+
This packet is then resubmitted into the protocol stack to be
processed as an IPIP packet.
3.3.2 Receiving transport layer encapsulation
Consider that a data message is received where GTE encapsulates a UDP
packet. In this case, the proto field in the GUE header is set to 17
for UDP:
+-------------------------------------+
| IP header (next proto = 6 TCP) |
|-------------------------------------|
| TCP header |
|-------------------------------------|
....
|-------------------------------------|
| GUE (proto = 17, UDP) |
|-------------------------------------|
| UDP header and payload |
+-------------------------------------+
....
The receiver extracts the UDP header and payload, and formats those
in a corresponding UDP/IP packet. The IP header is derived from the
TCP connection or IP header that was present in a received TCP
segment. The next protocol field is set to 17. The resultant packet
would have the format:
+-------------------------------------+
| IP header (next proto = 17, UDP) |
|-------------------------------------|
| UDP header and payload |
+-------------------------------------+
This packet is then resubmitted into the protocol stack to be
processed as a UDP packet.
Herbert Expires March, 2019 [Page 12]
Internet Draft Generic TCP Encapsulation September 27, 2018
3.3.3 Error handling
If a receiver encounters an error in processing the GUE header it
SHOULD close the GTE connection and MAY log an error. The possible
errors in processing a GUE header are described in [GUE].
3.4 Processing a received control message
If a valid GUE control message is received, the packet MUST be
processed as a control message. The specific processing to be
performed depends on the ctype in the GUE header. See [GUE].
3.5 NAT interaction
Transport layer encapsulation (section 3.1.2) allows TCP and UDP
packets (without IP headers) to be directly encapsulated in GTE. The
IP headers for these are derived from those used in the TCP
connection. In particular, the pseudo header for an encapsulated
transport checksum might cover the IP addresses used in outer TCP
packets. When a packet traverses a NAT and the addresses of the TCP
packet changes, the checksum for an encapsulated TCP or UDP packet
becomes incorrect.
To resolve this problem, the NAT Address Checksum option can be used
[GUEEXEN]. A sender computes the one's complement checksum over the
IP addresses for the outer TCP connection and sets the value in the
Checksum field of the GUE NAT Address Checksum option. When a
receiver processes the GTE message, it can compute the required
checksum adjustment by taking the difference between checksum over
the IP addresses for the connection that it sees and the value it
received in the option. If the adjustment is non-zero then that can
be added to the computed packet checksum in verification. The exact
algorithm is described in [GUEEXTEN].
3.6 Checksum offload of encapsulated transport checksum
Checksum offload is a common technique in Network Interface Cards
(NICS) to improve performance [UDPENCAP]. Checksum offload is done on
a per packet basis and typically can offload only one checksum in a
packet. Several techniques have been implemented to make general use
of the capability to effectively offload checksum computation for any
number of encapsulated transport checksums in a packet. These
techniques include "checksum-unnecessary conversion", Local Checksum
Offload (LCO), and Remote Checksum Offload (RCO).
In the case of GTE, packets are encapsulated in a stream so the
aforementioned techniques for checksum offload don't directly apply
and must be adapted.
Herbert Expires March, 2019 [Page 13]
Internet Draft Generic TCP Encapsulation September 27, 2018
3.6.1 Transmit checksum offload
To offload an encapsulated transport layer checksum for transmission,
the Remote Checksum Offload (RCO) Option is used [GUEXTEN]. The
Checksum Start and Checksum Offset fields in the option are set to
point to the starting byte for checksum calculation and the offset
where the checksum is to be written. When a receiver processes this
field, it will write the derived checksum value at the indicated
offset (i.e. the checksum field of an encapsulated transport
protocol).
3.6.2 Receive checksum offload
To offload a transport checksum calculation in a received GTE packet,
the fact that TCP packets must always include a checksum can be
leveraged. Given the TCP payload (or payloads) containing a GTE
message, the checksum over the GTE message can be derived by
subtracting out the checksum for portions of the payload that aren't
part of the GTE message. Once the checksum over the GTE message is
determined, that can be used to verify any encapsulated transport
layer checksums in the message. Note that this is most efficient when
a TCP segment contains only one (or part of one) GTE message.
3.7 GUE extensions
There is no prohibition to using any of the GUE extensions
[GUEEXTENS] in GTE. Their usefulness in the context of a TCP stream
may vary. The use of NAT Address Checksum and Remote Checksum Offload
options are described above. The Fragmentation option is not very
useful since TCP provides segmentation and reassembly. Similarly, the
GUE checksum option is not useful since the whole message is already
covered by the TCP checksum. The Security, Payload Transform, and
Alternate Checksum options may be useful to provide security or
strong data integrity checks. The Group Identifier might be useful in
some cases.
3.8 Surplus area
A an encapsulated packet in GTE may have its own length field such
that the encapsulated packet does not take up all the space of the
GTE message as indicate by GTE message length. Any bytes beyond the
encapsulated packet to the end of message are called "surplus area".
Surplus area, for those protocols that have a separate length field,
is considered to be reserved. [UDPOPTIONS] is a specification for
placing UDP options in surplus area.
Herbert Expires March, 2019 [Page 14]
Internet Draft Generic TCP Encapsulation September 27, 2018
4 GTE control messages
Two GUE control messages are defined to set parameters on a GTE
connection. One control message sets the size of the message length
field, and the other sets a GUE header template for compressing out
the GUE header in GTE messages.
4.1 Message length size
The default message length field in GTE is four bytes. The GUE
"Message length size" control message allows the size to be changed
for a GTE connection.
The format of the message length size control message is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| 0 |1| Hlen | 0x10 | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G
| | U
~ Extensions Fields (optional) ~ E
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h
| | d
~ Private data (optional) ~ r
| |/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MsgLenSize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Pertinent fields are:
o GUE C bit: Set to 1 to indicate control message
o GUE Proto/ctype field: Set to 0x10 to indicate a message length
size control message
o Reserved: Set to zero on transmit, ignored on receive
o MsgLenSize: Number of byte for message length size. Valid values
are 1,2,3, or 4
Note that the Reserved and MsgLenSize fields are in the payload of
the GUE message. These fields are not included in the GUE header
length.
Herbert Expires March, 2019 [Page 15]
Internet Draft Generic TCP Encapsulation September 27, 2018
If a received message is too short to include the MsgLenSize field or
the MsgLenSize is zero or a value greater then 4, then the connection
MUST be closed and an error MAY be logged.
After a message length size control message is received, the size of
the message length field in subsequent messages is taken to be the
provided value. The message length size control message MAY be sent
multiple times to use different sizes for lifetime of the connection.
4.2 GUE header template
An application may use GTE to always tunnel one specific protocol
over GTE where the GUE header is identical in all GTE messages. The
"GUE header template" control message is defined to compress out the
GUE header in such a case. The payload of this control message
indicates the GUE header to be applied to all subsequent messages.
The format of the GUE header template control message is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| 0 |1| Hlen | 0x11 | Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ G
| | U
~ Extensions Fields (optional) ~ E
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ h
| | d
~ Private data (optional) ~ r
| |/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| 0 |0| Hlen | Proto/ctype | Flags | G
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ U
| | E
~ Extensions Fields (optional) ~
| | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e
| | m
~ Private data (optional) ~ p
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
Herbert Expires March, 2019 [Page 16]
Internet Draft Generic TCP Encapsulation September 27, 2018
Pertinent fields in the (outer) GUE header are:
o Variant: Set to 0
o C bit: Set to 1 to indicate control message
o Proto/ctype field: Set to 0x11 to indicate a header template
control message
Pertinent fields in the GUE header template GUE are:
o Variant: Must be set to 0
o C bit: Should be zero to indicate a data message
o Proto/ctype: Set to the common IP protocol number for all the
messages in the GTE stream
The GUE header template may have flags set, extension fields present,
as well as private data.
4.2.1 Header template validation
The format of received GUE template header should be validated like a
normal GUE header as described in [GUE]. If the header template is
determined to be malformed, then the connection SHOULD be dropped and
an error MAY be logged.
The GUE header template must be variant 0. If a GUE header template
is received with a variant that is another value the connection MUST
be closed and an error MAY be logged.
4.2.2 Optional extensions in header templates
Any GUE extension that may be set in a header template will need to
be applicable to all messages.
The Checksum and Alternate Checksum options are not useful in a GUE
header template since their input includes payload data. If a
proposed header template contains such options the connection SHOULD
be dropped and an error MAY be logged.
The Fragmentation option is nonsensical to be in a GUE header
template. If a proposed header template contains the Fragmentation
option then the connection SHOULD be dropped and an error MAY be
logged.
The Security option may be useful in a GUE header template if it does
Herbert Expires March, 2019 [Page 17]
Internet Draft Generic TCP Encapsulation September 27, 2018
not include any payload data as input. If the Security option in a
header template requires payload data as input, then the connection
SHOULD be dropped and an error MAY be logged. If the Security option
in a header template doesn't require payload data as input, then it
SHOULD be verified (in this case all the input should be contained
within the GUE header template). If the Security option fails
verification, then the connection SHOULD be dropped and an error MAY
be logged.
The Group Identifier, Remote Checksum Offload, NAT Address Checksum
and Payload Transform options are valid optional extensions to use in
a GUE header template.
4.2.3 Processing received messages
After a GUE header template control message is received, the header
template is applied to all subsequent GTE messages. GTE messages will
contain a message length followed by the GUE payload. For each
received message, the GUE header from the saved template for the
connection is logically inserted into the message, and the message is
processed as though the GUE header was received.
The GUE header template control message can only be sent once on a
connection. All messages following the control message are considered
to have the same GUE header and there is no way to send any more GUE
control messages on the stream. If both the message length size and
the GUE header template are to be set for a GTE connection, then the
message length size control message MUST be sent first.
4.3 Example of UDP over GTE
This section provides an example use of the GTE control message to
encapsulate a stream of UDP packets over a GTE connection. In this
example, the sender uses both the message length size and GUE header
template control messages. The message length size is set to two
bytes to accommodate the largest UDP packet (65535 bytes). The GUE
header template sets the protocol for all messages to be UDP, enables
Remote Checksum Offload, and enables the NAT Address Checksum option.
In this example, the checksum start and checksum offset field in the
Remote Checksum Offload option take values of 0 and 6. The addresses
of the connection in this example are 2001:DB8::c099:1:2:0 and
2001:DB8::a92a:7:8:1-- the one's complement sum over those addresses
is 0x49c5.
Herbert Expires March, 2019 [Page 18]
Internet Draft Generic TCP Encapsulation September 27, 2018
The message length size and the GUE header template control messages
would be as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |1| 0x1 | 0x10 | 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | 0x2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |1| 0x0 | 0x11 | 0x0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |0| 0x2 | 0x11 | 0x280 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | 0x6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0 | 0x49c5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
All the messages following these control messages are encapsulated
UDP packets in the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
| Source port | Destination port | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP
| Length | Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/
| |
~ UDP payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that for each message, a full UDP/IP packet can be created by
deriving an IP header from the TCP connection (the address endpoints
of the TCP connection are the same the addresses of the UDP packet).
The NAT Address Checksum option can be used to insure that the UDP
checksum remains correct if the TCP connection goes through a NAT.
Herbert Expires March, 2019 [Page 19]
Internet Draft Generic TCP Encapsulation September 27, 2018
5 Security Considerations
GUE security mechanisms are applicable in GTE. Security
considerations for TCP encapsulation are discussed in [TCPENCAP].
6 IANA Considerations
6.1 TCP port number
IANA is requested to assign one TCP port number for Generic TCP
Encapsulation. The suggested number is 6080 which is the same as the
UDP port number assigned for Generic UDP Encapsulation.
6.2 GUE control types
IANA is requested to assign two values in the registry for the GUE
control types:
+----------------+------------------+---------------+
| Control type | Description | Reference |
+----------------+------------------+---------------+
| 0x10 | GTE message | This document |
| | length size | |
| | | |
| 0x11 | GUE header | This document |
| | template | |
+----------------+------------------+---------------+
6 Acknowledgements
7 References
7.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI
10.17487/RFC2119, March 1997, <http://www.rfc-
editor.org/info/rfc2119>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[GUE] T. Herbert, L. Yong, and O. Zia, "Generic UDP
Encapsulation", draft-ietf-intarea-gue-06
Herbert Expires March, 2019 [Page 20]
Internet Draft Generic TCP Encapsulation September 27, 2018
7.2. Informative References
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, DOI 10.17487/RFC2983, October 2000, <http://www.rfc-
editor.org/info/rfc2983>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <http://www.rfc-editor.org/info/rfc6040>.
[TCPENCAP] T. Pauly and E. Kinnear, "TCP Encapsulation
Considerations", draft-pauly-tcp-encapsulation-00
[GUEEXTEN] Herbert, T., Yong, L., and Templin, F., "Extensions for
Generic UDP Encapsulation" draft-ietf-intarea-gue-
extensions-05
[UDPENCAP] T. Herbert, "UDP Encapsulation in Linux",
http://people.netfilter.org/pablo/netdev0.1/papers/UDP-
Encapsulation-in-Linux.pdf
[LCO] Cree, E., https://www.kernel.org/doc/Documentation/
networking/checksum-offloads.txt
Author's Address
Tom Herbert
Quantonium
4701 Patrick Henry
Santa Clara, CA 95054
US
Email: tom@herbertland.com
Herbert Expires March, 2019 [Page 21]
