One document matched: draft-williams-overlaypath-ip-tcp-rfc-04.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc0791 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY rfc0793 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.0793.xml">
<!ENTITY rfc1918 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.1918.xml">
<!ENTITY rfc2119 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2460 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY rfc2663 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2663.xml">
<!ENTITY rfc4459 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.4459.xml">
<!ENTITY rfc5694 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.5694.xml">
<!ENTITY rfc6179 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6179.xml">
<!ENTITY rfc6269 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6269.xml">
<!ENTITY rfc6824 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6824.xml">
<!ENTITY rfc6967 SYSTEM
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.6967.xml">
<!ENTITY I-D.boucadair-intarea-host-identifier-scenarios SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.boucadair-intarea-host-identifier-scenarios">
<!ENTITY I-D.wing-nat-reveal-option SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wing-nat-reveal-option">
<!ENTITY I-D.abdo-hostid-tcpopt-implementation SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.abdo-hostid-tcpopt-implementation">
]>
<?rfc toc='yes'?>
<?rfc rfcprocack="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc ipr="trust200902" category="std">
<front>
<title>Overlay Path Option for IP and TCP</title>
<author initials="B." surname="Williams" fullname="Brandon Williams">
<organization>Akamai, Inc.</organization>
<address>
<postal>
<street></street>
<city>Cambridge</city>
<region>MA</region>
<code></code>
<country>USA</country>
</postal>
<email>brandon.williams@akamai.com</email>
</address>
</author>
<date year="2013" />
<abstract>
<t>Data transport through overlay networks often uses either connection
termination or network address translation (NAT) in such a way that
the public IP addresses of the true endpoint machines involved in the
data transport are invisible to each other. This document describes
IPv4, IPv6, and TCP options for communicating this information from
the overlay network to the endpoint machines.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>An overlay network is a network of machines distributed throughout
multiple autonomous systems within the public Internet (see
<xref target="intro_overlay" />). IP packets from the sender are
delivered first to one of the machines that make up the overlay
network. That machine will relay the IP packets via one or more other
machines in the overlay network to an overlay egress machine that will
deliver the packets to the real intended receiver.</t>
<figure anchor="intro_overlay">
<artwork>
+----------------------------------------+
| |
| INTERNET |
| |
+-----------+ | +--------------+ |
| HOST_1 |-----| OVERLAY_IN_1 |------------+ |
+-----------+ | +------------+ | |
| | |
+-----------+ | +--------------+ +-------------+ | +--------+
| HOST_2 |-----| OVERLAY_IN_2 |-----| OVERLAY_OUT |-----| SERVER |
+-----------+ | +--------------+ +-------------+ | +--------+
| | |
+-----------+ | +------------+ | |
| HOST_3 |-----| OVERLAY_IN_3 |------------+ |
+-----------+ | +------------+ |
| |
+----------------------------------------+
</artwork>
</figure>
<t>Such overlay networks are used to improve the performance of content
delivery <xref target="IEEE1344002" />. Overlay networks are also
used for peer-to-peer data transport <xref target="RFC5694" />, and
they have been suggested for use in both improved scalability for the
internet routing infrastructure <xref target="RFC6179" /> and
provisioning of security services (intrusion detection, anti-virus
software, etc.) over the public internet <xref target="IEEE101109" />.</t>
<t>In order for an overlay network to intercept IP packets transparently
via standard internet routing, the overlay ingress and egress hosts
(OVERLAY_IN and OVERLAY_OUT) must be reliably in-path in both
directions between the connection-initiating HOST and the SERVER. When
this is not the case, packets may be routed around the overlay and
sent directly to the receiving host.</t>
<t>For public overlay networks, where the ingress and/or egress hosts
are on the public internet, packet interception typically uses network
address translation for the source (SNAT) or destination (DNAT)
addresses <xref target="RFC2663" /> in such a way that the public IP
addresses of the true endpoint hosts involved in the data transport
are invisible to each other. For example, the actual sender and
receiver may use two completely different pairs of source and
destination addresses to identify the connection on the sending and
receiving networks in cases where both the ingress and egress hosts
are on the public internet.</t>
<figure anchor="intro_addressing">
<artwork>
---------------------------------------------------------------------
ip hdr contains: ip hdr contains:
SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER
dst = overlay1 dst = receiver
---------------------------------------------------------------------
</artwork>
</figure>
<t>In the above example, the sender transmits packets using its own IP
address as the source and the IP address of overlay1 as the
destination. This is required in order to ensure that the packets are
intercepted by overlay1. Next, overlay1 tunnels the packets over the
internet to overlay2 with possible transit via other hosts in the
overlay network. Finally, overlay2 applies both SNAT and DNAT,
transmitting the packets with the IP address of overlay2 as the source
and the IP address of the intended receiver as the destination. This
use of both SNAT and DNAT is required in order to ensure that return
traffic also uses the overlay network.</t>
<t>A broad range of issues associated with address sharing have been
well documented <xref target="RFC6269" />, and they are not unique to
public overlay networks
<xref target="I-D.boucadair-intarea-host-identifier-scenarios" />.
However, public overlay networks can pose a bigger traceability
problem than most other use cases, due to their combined use of SNAT
and DNAT.</t>
<section anchor="use_case" title="Detailed Use Case">
<t>The following list describes typical operation of a public overlay
network used for internet routing. Other types of overlay networks
operate somewhat differently with regard to packet handling within
the overlay (e.g. TCP connections may be terminated at the overlay
ingress and egress hosts), but the use of DNAT and SNAT to
facilitate packet interception by the overlay is similar. This
detailing of overlay operation is presented in order to provide
context for the solution-set analysis that follows.
<list style="symbols">
<t>The sending endpoint host performs a DNS lookup that returns the
IP address of a machine on the overlay network. The sending
endpoint addresses its packets with its own public IP address as
the source and the provided overlay IP address as the
destination.</t>
<t>The overlay ingress host receives the packet on its public IP
address, and forwards the packet through the overlay tunnel to
the egress host. The overlay egress host performs SNAT,
replacing the source IP address of the sending endpoint with its
own IP address in order to ensure that return traffic will also
use the overlay network. This use of SNAT hides the client's
public IP address for the receiving network.</t>
<t>The overlay egress host is located on the receiver's network,
which means there is a relatively small set of source addresses
used for connections between the overlay egress host and the
application server.</t>
<t>For load balancing and diagnostic purposes, it is important for
one or more machines on the receiver's network to be able to
determine the public IP address associated with the sending host
and the destination IP address used by the sending host (i.e. the
addresses that were hidden by the overlay due to the use of SNAT
and DNAT).</t>
<t>The data transferred via the overlay network is typically
encrypted (e.g. using SSL) such that the overlay network can
apply network and transport layer optimizations but cannot
access information provided at the application layer.</t>
<t>For diagnostic purposes, the overlay network must also support
traceroute using UDP probe packets.</t>
</list>
</t>
</section>
<section anchor="solution_analysis" title="Solution-set Analysis" >
<t>A detailed analysis of various solutions to the problem of
revealing the sending host's ID information to the receiver is
presented by <xref target="RFC6967"/>. A solution that is suitable
for overlay networks will have the following properties:
<list style="symbols">
<t>The method must support both TCP and UDP.</t>
<t>The method must work in the presence of encrypted traffic.</t>
<t>The method must have a high success ratio for existing servers
and networks.</t>
<t>The method must have a minimal impact on performance.</t>
<t>The method must support provision of multiple addresses.</t>
<t>The method must provide client identification at connection
initiation.</t>
</list>
</t>
<t>Based on the above referenced analysis and overlay network
suitability requirements, the best-fit solution for providing
address visibility for application data flows is to use a TCP
option. A feasibility assessment of two proposed TCP host ID
options is provided by
<xref target="I-D.abdo-hostid-tcpopt-implementation" />. Although
the options implemented for that assessment do not meet the
"multiple address" criteria highlighted above, the proof-of-concept
implementations and testing show that this category of solution is
workable.</t>
<t>Unfortunately, there is no solution for UDP traffic that meets all
of the above criteria. However, in the case where the full path from
the overlay egress machine to the application server is under common
administrative control, it is possible to mitigate the shortcomings
associated with IP options and generate both a high success ratio
and low-to-medium performance impact when using an IP option to
communicate the address information. For this reason, provision of
an IP option can be useful enough for overlay networks to be worth
consideration.</t>
<t>It should be noted that IPv4 and TCP protocol options can provide
only limited support for IPv6 addresses. Inclusion of even a single
IPv6 address would require the option to consume nearly half of the
total option space provided by TCP and IPv4, which means that the
entire TCP option space would be consumed for SYN packets that
include the most commonly used options (i.e. MSS, WSOPT, SACK
permitted, and TSOPT). This may prevent effective use of the IPv4
and TCP protocol options for communicating IPv6 addresses in some
circumstances.</t>
<t>This document describes <xref target="RFC0791">IPv4</xref>,
<xref target="RFC2460">IPv6</xref>, and
<xref target="RFC0793">TCP</xref> options for communicating
sender-side address information from the overlay to the destination
network/machine. The list of addresses specified in the option may
include any addresses that might be useful to the eventual receiver,
including but not limited to the source and destination addresses as
seen by the sender.</t>
</section>
</section>
<section title="Terminology">
<t>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
<xref target="RFC2119">RFC2119</xref>.</t>
</section>
<section anchor="format" title="Option Format">
<t>Some implementations already exist for version 1 of the overlay path
option. However, version 1 of the option does not provide support for
communicating IPv6 addresses in either the IPv4 or TCP option. Both
version 1 and version 2 of the option are described here in order to
reflect the requirements of current and future implementors.</t>
<t>It is up to the implementor whether version 1 is supported or both
versions are supported. A receiving implementation that supports
version 2 MUST also support version 1. The format changes defined for
version 2 directly support the required backward compatibility.</t>
<t>When a receiving implementation encounters the overlay path option
with an unsupported version number, the receiver MAY either ignore the
option or drop the packet. The appropriate response will be dependent
upon how the overlay path option's value is used by the receiver.</t>
<section anchor="format_v1" title="Version 1">
<t>Version 1 of the option supports only IPv4 addresses. The option
format for both IPv4 and TCP is identical.</t>
<figure anchor="layout_v1">
<artwork>
+---------+---------+---------+--------------------------------+
|Type/Kind| Length | Version | Addresses ...
+---------+---------+---------+--------------------------------+
1 1 1 4 x Address Count
----------------------------------------------------------------
</artwork>
</figure>
<t><list style="hanging">
<t hangText="IPv4 Type:">The type value for IPv4 is TBD-IP4-FULL
(see also <xref target="iana">IANA Considerations</xref>).
<list style="hanging">
<t hangText="Copied flag:"> 1 (All fragments must carry the
option.)</t>
<t hangText="Option class:"> 2 (debugging/measurement)</t>
<t hangText="Option number:">TBD-IP4 (decimal)</t>
</list>
</t>
<t hangText="TCP Kind:">The option kind value for TCP is TBD-TCP
(see also <xref target="iana">IANA Considerations</xref>).</t>
<t hangText="Length:">The length of the option is variable, based
on the number of addresses provided. The minimum value is 7 (3
1-octet fields plus one 4-octet address). The option MUST be
ignored if the length value cannot represent 3 octets plus a
list of 4-octet address value.</t>
<t hangText="Version:">The version number is 1.</t>
<t hangText="Addresses:">Version 1 of the option supports only IPv4
addresses. The remainder of the option space is filled with
standard 32-bit IPv4 addresses. In practice, the first address
will be the public source address used by the sender and the
second address (if present) will be the public destination
address used by the sender. However, the nature of the
addresses provided may vary depending on the nature of the
overlay network in question and is not required to include every
IP address used for the connection. The list of IP addresses
MUST be provided in order of traversal from sender to
receiver.</t>
</list></t>
</section>
<section anchor="format_v2" title="Version 2">
<t>Version 2 of the options supports either IPv4 addresses or IPv6
addresses, but it does not support a mix of IPv4 and IPv6 options
within the same option value. Version 2 provides not only IPv4 and
TCP options, but also an IPv6 option for inclusion in the IPv6
Hop-by-hop Options header. When IPv6 address support is required,
the implementation SHOULD use the IPv6 header option whenever
possible in order to avoid exhaustion of the TCP option space. The
option format for all three protocols is identical.</t>
<figure anchor="layout_v2_ipv6">
<artwork>
+---------------+---------------+---------------+-------------------\
| Type/Kind | Length |Fmly| Version | Addresses ...
+---------------+---------------+---------------+-------------------\
8b 8b | 3b 5b |
-----------------
1 1 1 Addr Size x Count
---------------------------------------------------------------------
</artwork>
</figure>
<t><list style="hanging">
<t hangText="IPv4 Type:">Identical to Version 1.</t>
<t hangText="TCP Kind:">Identical to Version 1.</t>
<t hangText="IPv6 Type:">The Type value for IPv6 is TBD-IP6
(see also <xref target="iana">IANA Considerations</xref>).
<list style="hanging">
<t hangText="act flag:">00 (skip over option)</t>
<t hangText="chg flag:"> 0 (option data does not change
en-route)</t>
<t hangText="rest:"> TBD-IP6 (decimal)</t>
</list>
</t>
<t hangText="Length:">The length of the option is variable, based
on the address family and the number of addresses provided. The
minimum value is 7 (3 1-octet fields plus one 4-octet IPv4
address). The option MUST be ignored if the length value cannot
represent 3 octets plus a list of addresses of the correct
address family.</t>
<t hangText="Family/Version:">The third octet is comprised of two
fields: family and version.Note that the possible family values
have been selected to support backward compatibility with the
8-bit version field in version 1 of the option format.</t>
<t hangText="Family:">The high order 3 bits of the third octet
indicate the address family for all IP addresses represented in
the variable-length Addresses field. The allowed values are:
<list style="hanging">
<t hangText="0:">Address family is IPv4.</t>
<t hangText="1:">Address family is IPv6.</t>
</list>
</t>
<t hangText="Version:">The low order 5 bits of the third octet
indicate the protocol version number. The version number is
2.</t>
<t hangText="Addresses:">The remainder of the option space is
filled with either 32-bit IPv4 or 128-bit IPv6 addresses, as
indicated by the Family field. In practice, the first address
will be the public source address used by the sender and the
second address (if present) will be the public destination
address used by the sender. However, the nature of the
addresses provided may vary depending on the nature of the
overlay network in question and is not required to include every
IP address used for the connection. The list of IP addresses
MUST be provided in order of traversal from sender to
receiver.</t>
</list></t>
</section>
</section>
<section anchor="net_traversal" title="Network Traversal">
<figure anchor="net_traversal_figure">
<preamble>
The following block diagram illustrates the use of addresses in the
IPv4 header and the overlay path option as a packet traverses the
network from sender to receiver. The diagram assumes that the
overlay network uses separate addresses (overlay1 and overlay2) for
ingress and egress, and that the receiver has a need to know both
addresses used by the sender.
</preamble>
<artwork>
-----------------------------------------------------------------
SENDER
|
V
+----------------+
| |
| src: sender |
| dst: overlay1 |
| opt: none |
| |
+----------------+
|
V
OVERLAY
NETWORK
|
V
+----------------+
| |
| src: overlay2 |
| dst: receiver |
| opt: sender |
| overlay1 |
| |
+----------------+
|
V
RECEIVER
-----------------------------------------------------------------
</artwork>
</figure>
</section>
<section anchor="option_use" title="Option Use">
<t>This section describes considerations for use of the option,
including interactions with other options and the impact on packet
sizes.</t>
<section anchor="tcp_option_use" title="TCP Option Use">
<t>Use of the TCP option allows an implementation to minimize the
impact of this option on bandwidth utilization. Due to the
connection-oriented nature of TCP, the addresses used by the overlay
network cannot not change throughout the life of the connection. For
this reason, it is not necessary for the overlay network to include
the overlay path option on every packet. On the other hand, it is
not enough for the option to be provided exclusively in the TCP SYN
packet because the use of SYN cookies, for example, would mean that
connection state is not stored until completion of the three-way
handshake. For this reason, the overlay network MUST include the TCP
overlay path option in every outgoing packet until the receiver has
either acknowledged or transmitted at least one byte of real data.
The overlay network SHOULD discontinue inclusion of the TCP overlay
path option after the first byte is either received or acknowledged.
The receiver MAY ignore the TCP overlay path option on subsequent
packets after successfully processing one instance of the option
attached to a single in-order TCP packet.</t>
</section>
<section anchor="option_interactions"
title="Interaction with Other TCP Options">
<t>The TCP option space is limited to a maximum of 40 bytes.
Inclusion of the TCP overlay path option depends upon the
availability of space after any other options have been added.</t>
<t>As explained in <xref target="RFC6824" />, typical SYN packets use
19 bytes of this space if the options are packed or 24 bytes if the
options are word aligned. In the optimistic case, 21 bytes are
available in the SYN's option space, which allows up to 4 IPv4
addresses or a single IPv6 address to be included in the overlay
path option. If any TCP options are included in the SYN outside of
those most commonly seen (MSS, window scale, SACK permitted, and
timestamp), or if the option space is word aligned, there is no
space available for even a single IPv6 address and there is limited
space (perhaps even no space) available for IPv4 addresses.</t>
<t>As <xref target="RFC6824" /> also explains, ACK packets and data
packets typically only carry the timestamp option, which requires 10
bytes (12 with padding). However, use of SACK and/or TCP options
outside of the set of typical options can consume all of the
remaining option space under some conditions. In other words, it is
usually possible to include the TCP overlay path option in an ACK
packet, but there is no guarantee that this will be true.</t>
<t>The TCP overlay path option MUST NOT be applied to packets when
there is not at least enough option space available to include one
address of the required family. When multiple addresses are expected
but there is not enough option space available to include all of the
expected addresses, the overlay path address list SHOULD be
shortened to include only the number of addresses that can fit
within the available option space, with preference given to
inclusion of the addresses that would naturally appear first in the
list. The receiver's handling of connections that do not include the
overlay path option will depend upon the local policy, but the
receiver SHOULD accept connections without the TCP overlay path
option if there is no mechanism in place to guarantee that space
will be available for the option when necessary.</t>
</section>
<section anchor="ip_option_use" title="IP Option Use">
<t>IP is not connection oriented, which means that the above described
optimization for TCP is not possible. In order to make effective use
of the TCP optimization, an overlay network SHOULD only send the IP
option on packets that do not use TCP as the transport layer
protocol. When the IP option is in use, the overlay network MUST
transmit the option with every packet. The receiver MUST NOT assume
that that addresses in the IP overlay path option will remain
consistent, but instead MUST be prepared to handle address changes
in an application appropriate way.</t>
<t>Use of the IP option is dependent upon support for IP options in
all routers between the overlay egress point and the packet
receiver. If any router along the path is configured to drop packets
with unknown IPv4 options (or any IP options, as is sometimes done
as part of a DoS protection scheme), then use of the IP option will
cause connections to simply fail. For this reason, the IP option
SHOULD only be used in environments where the full path between the
overlay egress machine and the packet receiver is under common
administrative control.</t>
</section>
<section anchor="packet_fragmentation"
title="Interaction with IP Packet Fragmentation">
<t>As noted above, overlay networks commonly use tunneling in order to
route packets across the overlay, which requires special handling in
order to avoid problems associated with packet fragmentation (see
<xref target="RFC4459" />). It is likely to be the case that the
overlay network's tunneling method adds at least as much overhead to
tunneled packets as the space required for the overlay path option.
When this is true, use of the overlay path option does not add new
packet fragmentation issues to be resolved.</t>
<t>The overlay path option SHOULD NOT be applied to packets if the
resulting packet size violates the path MTU between the egress host
and the receiver. If the resulting packet size would be too large,
the overlay path address list SHOULD be shortened to include only
the number of addresses that can fit without generating an oversized
packet, with preference given to the addresses that would naturally
appear first in the list. If even a single address cannot be
transmitted in the overlay path option without violating the MTU,
the overlay path option SHOULD NOT be added to the packet. The
receiver's handling of packets that do not include the overlay path
option will depend upon the local policy, but the receiver SHOULD
accept packets without the overlay path option if there is no
mechanism in place to guarantee that space will be available for the
option when necessary.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>This specification provides no authentication/validity verification
for the data contained in the addresses field. For this reason, the
data contained in the addresses field of the new option cannot itself
be considered inherently secure. In other words, confidence in the
validity of the source address of the IPv4/IPv6 packet does not
translate into confidence in the validity of the addresses in the
overlay path option. With this exception, this specification does not
alter the inherent security of IPv4, IPv6, or TCP.</t>
<t>The addresses provided in the option SHOULD NOT be used for purposes
that require a trust relationship between the overlay network and the
receiver (e.g. billing and/or intrusion prevention) unless a mechanism
outside the scope of this specification is used to ensure the
necessary level of trust. One possible example of such a mechanism
would be to place the overlay egress host on the receiver's own
network and to configure the receiver's firewall to drop any packets
from external hosts that provide the overlay path option. When the
receiving network uses the values provided by the option in a way that
does not require trust (e.g. maintaining session affinity in a
load-balancing system), then use of a mechanism to enforce the trust
relationship might not be required.</t>
<t>As explained above, the intention of both the TCP and IP options is
to provide the receiver with public IP addresses that it would
otherwise have seen if the overlay network were not in use. There are
security implications associated with exposing a network's use of the
private <xref target="RFC1918" /> address space to the public
internet, and for this reason, the overlay path option SHOULD NOT be
used to communicate RFC1918 addresses in packets that traverse the
public internet.</t>
</section>
<section anchor="fwd_compat" title="Forward Compatibility Support">
<t>The most common use of this option on the internet today will require
recording IP addresses for a single address family only. However, it
may be important in the future to be able to record a mix of IPv4 and
IPv6 addresses. Alternatively, future security requirements may demand
the use of, for example, a keyed hash for data integrity and
authentication purposes and/or inclusion of additional information
specific to the sender's connection.</t>
<t>To balance current-day performance and efficiency against the need
for future extensibility, the option includes a version field, so that
future requirements can be met without the need to consume a new
option number.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>[Paragraphs below in braces should be removed by the RFC Editor upon
publication]</t>
<t>[The TCP Overlay Path Option requires that IANA allocate a value from
the TCP option kind namespace, to be replaced for TBD-TCP throughout
this document.]</t>
<t>[The IPv4 Overlay Path Option requires that IANA allocate a value
from the IP option number namespace. The copy flag for this option is
1 and the class for this option is 2. The assigned number will replace
TBD-IP4 throughout this document, and the full type value
(representing copy, class, and number) will replace TBD-IP4-FULL
throughout the document.]</t>
<t>[The IPv6 Overlay Path Option requires that IANA allocate a value
from the IPv6 parameters: hop-by-hop options namespace. The action for
this option is 00 and the change flag for this option is 0. The
assigned number will replace TBD-IP6 throughout this document.]</t>
<t>This document defines the TCP Overlay Path option, described in <xref
target="format_v1" /> and <xref target="format_v2" />. This option
has been assigned the option number TBD-TCP by IANA action.</t>
<t>This document also defines the IPv4 Overlay Path option, described in
<xref target="format_v1" /> and <xref target="format_v2" />. This
option has been assigned the option number TBD-IP4-FULL by IANA
action.</t>
<t>This document also defines the IPv6 Overlay Path hop-by-hop option,
described in <xref target="format_v2" />. This option has been
assigned the option number TBD-IP6 by IANA action.</t>
<t>This document defines no new namespaces.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc0791;
&rfc0793;
&rfc1918;
&rfc2119;
&rfc2460;
</references>
<references title="Informative References">
&rfc2663;
&rfc4459;
&rfc5694;
&rfc6179;
&rfc6269;
&rfc6824;
&rfc6967;
<reference anchor="IEEE1344002">
<front>
<title abbrev="Informed content delivery">Informed content delivery
across adaptive overlay networks: IEEE/ACM Transactions on
Networking, Vol 12, Issue 5, ppg 767-780</title>
<author initials="J.W." surname="Byers" fullname="John Byers">
<organization abbrev="Boston University">
Boston University, Dept. of Computer Science
</organization>
</author>
<author initials="J." surname="Considine" fullname="Jeffrey Considine">
<organization abbrev="Boston University">
Boston University, Dept. of Computer Science
</organization>
</author>
<author initials="M." surname="Mitzenmacher" fullname="Michael Mitzenmacher">
<organization abbrev="Harvard University">
Harvard University, EECS
</organization>
</author>
<author initials="S." surname="Rost" fullname="Stanislav Rost">
<organization abbrev="MIT">
MIT Laboratory for Computer Science
</organization>
</author>
<date month="October" year="2004" />
</front>
</reference>
<reference anchor="IEEE101109">
<front>
<title abbrev="Security Overlay Network">Using Cloud Computing to
Implement a Security Overlay Network, IEEE Security & Privacy,
21 June 2012. IEEE Computer Society Digital Library.</title>
<author initials="K." surname="Salah" fullname="Khaled Salah">
<organization abbrev="Khalifa University">
Khalifa University of Science Technology and Research
</organization>
</author>
<author initials="J.M.A." surname="Calero" fullname="Jose Maria Alcaraz Calero">
<organization abbrev="Universidad de Murcia">
Universidad de Murcia
</organization>
</author>
<author initials="S." surname="Zeadally" fullname="Sherali Zeadally">
<organization abbrev="University of the District of Columbia">
University of the District of Columbia
</organization>
</author>
<author initials="S." surname="Almulla" fullname="Sameera Almulla">
<organization abbrev="Khalifa University">
Khalifa University of Science Technology and Research
</organization>
</author>
<author initials="M." surname="ZAaabi" fullname="Mohammed ZAaabi">
<organization abbrev="Khalifa University">
Khalifa University of Science Technology and Research
</organization>
</author>
<date month="June" year="2012" />
</front>
</reference>
&I-D.boucadair-intarea-host-identifier-scenarios;
<!-- &I-D.wing-nat-reveal-option; -->
&I-D.abdo-hostid-tcpopt-implementation;
</references>
<section anchor="change_history" title="Change History">
<t>[Note to RFC Editor: Please remove this section prior to
publication.]</t>
<section anchor="03-to-04" title="Changes from version 03 to 04">
<t>Clarify public overlay network use case regarding NAT.</t>
<t>Add some discussion regarding use of option space and packet
fragmentation.</t>
</section>
<section anchor="02-to-03" title="Changes from version 02 to 03">
<t>Clarifications to introduction and use case discussion.</t>
<t>Clarify security considerations.</t>
</section>
<section anchor="01-to-02" title="Changes from version 01 to 02">
<t>Improve IANA Considerations section.</t>
</section>
<section anchor="00-to-01" title="Changes from version 00 to 01">
<t>Fix inappropriate use of numeric option number placeholders.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:12:12 |