[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Network Working Group                                        B. Williams
Internet-Draft                                              Akamai, Inc.
Intended status:  Standards Track                          June 19, 2013
Expires:  December 21, 2013


                   Overlay Path Option for IP and TCP
                draft-williams-overlaypath-ip-tcp-rfc-04

Abstract

   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.

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).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on December 21, 2013.

Copyright Notice

   Copyright (c) 2013 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.  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



Williams                Expires December 21, 2013               [Page 1]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Detailed Use Case  . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Solution-set Analysis  . . . . . . . . . . . . . . . . . .  5
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Option Format  . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Version 1  . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Version 2  . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Network Traversal  . . . . . . . . . . . . . . . . . . . . . . 10
   5.  Option Use . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  TCP Option Use . . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Interaction with Other TCP Options . . . . . . . . . . . . 11
     5.3.  IP Option Use  . . . . . . . . . . . . . . . . . . . . . . 12
     5.4.  Interaction with IP Packet Fragmentation . . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  Forward Compatibility Support  . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Change History  . . . . . . . . . . . . . . . . . . . 16
     A.1.  Changes from version 03 to 04  . . . . . . . . . . . . . . 16
     A.2.  Changes from version 02 to 03  . . . . . . . . . . . . . . 16
     A.3.  Changes from version 01 to 02  . . . . . . . . . . . . . . 17
     A.4.  Changes from version 00 to 01  . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17





















Williams                Expires December 21, 2013               [Page 2]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


1.  Introduction

   An overlay network is a network of machines distributed throughout
   multiple autonomous systems within the public Internet (see
   Figure 1).  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.

                  +----------------------------------------+
                  |                                        |
                  |                INTERNET                |
                  |                                        |
   +-----------+  |  +--------------+                      |
   |  HOST_1   |-----| OVERLAY_IN_1 |------------+         |
   +-----------+  |  +------------+              |         |
                  |                              |         |
   +-----------+  |  +--------------+     +-------------+  |  +--------+
   |  HOST_2   |-----| OVERLAY_IN_2 |-----| OVERLAY_OUT |-----| SERVER |
   +-----------+  |  +--------------+     +-------------+  |  +--------+
                  |                              |         |
   +-----------+  |  +------------+              |         |
   |  HOST_3   |-----| OVERLAY_IN_3 |------------+         |
   +-----------+  |  +------------+                        |
                  |                                        |
                  +----------------------------------------+

                                 Figure 1

   Such overlay networks are used to improve the performance of content
   delivery [IEEE1344002].  Overlay networks are also used for peer-to-
   peer data transport [RFC5694], and they have been suggested for use
   in both improved scalability for the internet routing infrastructure
   [RFC6179] and provisioning of security services (intrusion detection,
   anti-virus software, etc.) over the public internet [IEEE101109].

   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.

   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 [RFC2663] in such a way that the public IP addresses



Williams                Expires December 21, 2013               [Page 3]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


   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.

   ---------------------------------------------------------------------

             ip hdr contains:               ip hdr contains:
   SENDER -> src = sender   --> OVERLAY --> src = overlay2  --> RECEIVER
             dst = overlay1                 dst = receiver

   ---------------------------------------------------------------------

                                 Figure 2

   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.

   A broad range of issues associated with address sharing have been
   well documented [RFC6269], and they are not unique to public overlay
   networks [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.

1.1.  Detailed Use Case

   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.

   o  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



Williams                Expires December 21, 2013               [Page 4]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


      the source and the provided overlay IP address as the destination.

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

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

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

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

   o  For diagnostic purposes, the overlay network must also support
      traceroute using UDP probe packets.

1.2.  Solution-set Analysis

   A detailed analysis of various solutions to the problem of revealing
   the sending host's ID information to the receiver is presented by
   [RFC6967].  A solution that is suitable for overlay networks will
   have the following properties:

   o  The method must support both TCP and UDP.

   o  The method must work in the presence of encrypted traffic.

   o  The method must have a high success ratio for existing servers and
      networks.

   o  The method must have a minimal impact on performance.

   o  The method must support provision of multiple addresses.




Williams                Expires December 21, 2013               [Page 5]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


   o  The method must provide client identification at connection
      initiation.

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

   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.

   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.

   This document describes IPv4 [RFC0791], IPv6 [RFC2460], and TCP
   [RFC0793] 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.


2.  Terminology

   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 [RFC2119].





Williams                Expires December 21, 2013               [Page 6]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


3.  Option Format

   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.

   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.

   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.

3.1.  Version 1

   Version 1 of the option supports only IPv4 addresses.  The option
   format for both IPv4 and TCP is identical.

   +---------+---------+---------+--------------------------------+
   |Type/Kind| Length  | Version | Addresses ...
   +---------+---------+---------+--------------------------------+
        1         1         1            4 x Address Count
   ----------------------------------------------------------------

                                 Figure 3

   IPv4 Type:  The type value for IPv4 is TBD-IP4-FULL (see also IANA
      Considerations (Section 8)).

      Copied flag:  1 (All fragments must carry the option.)

      Option class:  2 (debugging/measurement)

      Option number:  TBD-IP4 (decimal)

   TCP Kind:  The option kind value for TCP is TBD-TCP (see also IANA
      Considerations (Section 8)).

   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



Williams                Expires December 21, 2013               [Page 7]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


      value.

   Version:  The version number is 1.

   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.

3.2.  Version 2

   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.

   +---------------+---------------+---------------+-------------------\
   |   Type/Kind   |    Length     |Fmly| Version  |  Addresses ...
   +---------------+---------------+---------------+-------------------\
          8b              8b       | 3b     5b     |
                                   -----------------
           1               1              1          Addr Size x Count
   ---------------------------------------------------------------------

                                 Figure 4

   IPv4 Type:  Identical to Version 1.

   TCP Kind:  Identical to Version 1.

   IPv6 Type:  The Type value for IPv6 is TBD-IP6 (see also IANA
      Considerations (Section 8)).

      act flag:  00 (skip over option)







Williams                Expires December 21, 2013               [Page 8]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


      chg flag:  0 (option data does not change en-route)

      rest:  TBD-IP6 (decimal)

   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.

   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.

   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:

      0: Address family is IPv4.

      1: Address family is IPv6.

   Version:  The low order 5 bits of the third octet indicate the
      protocol version number.  The version number is 2.

   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.















Williams                Expires December 21, 2013               [Page 9]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


4.  Network Traversal

   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.

   -----------------------------------------------------------------

                                SENDER
                                  |
                                  V
                          +----------------+
                          |                |
                          | src: sender    |
                          | dst: overlay1  |
                          | opt: none      |
                          |                |
                          +----------------+
                                  |
                                  V
                               OVERLAY
                               NETWORK
                                  |
                                  V
                          +----------------+
                          |                |
                          | src: overlay2  |
                          | dst: receiver  |
                          | opt: sender    |
                          |      overlay1  |
                          |                |
                          +----------------+
                                  |
                                  V
                               RECEIVER

   -----------------------------------------------------------------

                                 Figure 5


5.  Option Use

   This section describes considerations for use of the option,
   including interactions with other options and the impact on packet



Williams                Expires December 21, 2013              [Page 10]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


   sizes.

5.1.  TCP Option Use

   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.

5.2.  Interaction with Other TCP Options

   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.

   As explained in [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.

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

   The TCP overlay path option MUST NOT be applied to packets when there



Williams                Expires December 21, 2013              [Page 11]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


   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.

5.3.  IP Option Use

   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.

   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.

5.4.  Interaction with IP Packet Fragmentation

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

   The overlay path option SHOULD NOT be applied to packets if the
   resulting packet size violates the path MTU between the egress host



Williams                Expires December 21, 2013              [Page 12]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


   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.


6.  Security Considerations

   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.

   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.

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





Williams                Expires December 21, 2013              [Page 13]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


7.  Forward Compatibility Support

   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.

   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.


8.  IANA Considerations

   [Paragraphs below in braces should be removed by the RFC Editor upon
   publication]

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

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

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

   This document defines the TCP Overlay Path option, described in
   Section 3.1 and Section 3.2.  This option has been assigned the
   option number TBD-TCP by IANA action.

   This document also defines the IPv4 Overlay Path option, described in
   Section 3.1 and Section 3.2.  This option has been assigned the
   option number TBD-IP4-FULL by IANA action.

   This document also defines the IPv6 Overlay Path hop-by-hop option,
   described in Section 3.2.  This option has been assigned the option
   number TBD-IP6 by IANA action.



Williams                Expires December 21, 2013              [Page 14]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


   This document defines no new namespaces.


9.  References

9.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

9.2.  Informative References

   [I-D.abdo-hostid-tcpopt-implementation]
              Abdo, E., Boucadair, M., and J. Queiroz, "HOST_ID TCP
              Options: Implementation & Preliminary Test Results",
              draft-abdo-hostid-tcpopt-implementation-03 (work in
              progress), July 2012.

   [I-D.boucadair-intarea-host-identifier-scenarios]
              Boucadair, M., Binet, D., Durel, S., Chatras, B., Reddy,
              T., and B. Williams, "Host Identification: Use Cases",
              draft-boucadair-intarea-host-identifier-scenarios-03 (work
              in progress), March 2013.

   [IEEE101109]
              Salah, K., Calero, J., Zeadally, S., Almulla, S., and M.
              ZAaabi, "Using Cloud Computing to Implement a Security
              Overlay Network, IEEE Security & Privacy, 21 June 2012.
              IEEE Computer Society Digital Library.", June 2012.

   [IEEE1344002]
              Byers, J., Considine, J., Mitzenmacher, M., and S. Rost,
              "Informed content delivery across adaptive overlay
              networks: IEEE/ACM Transactions on Networking, Vol 12,
              Issue 5, ppg 767-780", October 2004.



Williams                Expires December 21, 2013              [Page 15]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC4459]  Savola, P., "MTU and Fragmentation Issues with In-the-
              Network Tunneling", RFC 4459, April 2006.

   [RFC5694]  Camarillo, G. and IAB, "Peer-to-Peer (P2P) Architecture:
              Definition, Taxonomies, Examples, and Applicability",
              RFC 5694, November 2009.

   [RFC6179]  Templin, F., "The Internet Routing Overlay Network
              (IRON)", RFC 6179, March 2011.

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269,
              June 2011.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, January 2013.

   [RFC6967]  Boucadair, M., Touch, J., Levis, P., and R. Penno,
              "Analysis of Potential Solutions for Revealing a Host
              Identifier (HOST_ID) in Shared Address Deployments",
              RFC 6967, June 2013.


Appendix A.  Change History

   [Note to RFC Editor:  Please remove this section prior to
   publication.]

A.1.  Changes from version 03 to 04

   Clarify public overlay network use case regarding NAT.

   Add some discussion regarding use of option space and packet
   fragmentation.

A.2.  Changes from version 02 to 03

   Clarifications to introduction and use case discussion.

   Clarify security considerations.






Williams                Expires December 21, 2013              [Page 16]


Internet-Draft     Overlay Path Option for IP and TCP          June 2013


A.3.  Changes from version 01 to 02

   Improve IANA Considerations section.

A.4.  Changes from version 00 to 01

   Fix inappropriate use of numeric option number placeholders.


Author's Address

   Brandon Williams
   Akamai, Inc.
   Cambridge, MA
   USA

   Email:  brandon.williams@akamai.com


































Williams                Expires December 21, 2013              [Page 17]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/