idnits 2.17.1 draft-williams-overlaypath-ip-tcp-rfc-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 19, 2013) is 3964 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-11) exists of draft-boucadair-intarea-host-identifier-scenarios-03 -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Williams 3 Internet-Draft Akamai, Inc. 4 Intended status: Standards Track June 19, 2013 5 Expires: December 21, 2013 7 Overlay Path Option for IP and TCP 8 draft-williams-overlaypath-ip-tcp-rfc-04 10 Abstract 12 Data transport through overlay networks often uses either connection 13 termination or network address translation (NAT) in such a way that 14 the public IP addresses of the true endpoint machines involved in the 15 data transport are invisible to each other. This document describes 16 IPv4, IPv6, and TCP options for communicating this information from 17 the overlay network to the endpoint machines. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 21, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Detailed Use Case . . . . . . . . . . . . . . . . . . . . 4 55 1.2. Solution-set Analysis . . . . . . . . . . . . . . . . . . 5 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3. Option Format . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.1. Version 1 . . . . . . . . . . . . . . . . . . . . . . . . 7 59 3.2. Version 2 . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4. Network Traversal . . . . . . . . . . . . . . . . . . . . . . 10 61 5. Option Use . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5.1. TCP Option Use . . . . . . . . . . . . . . . . . . . . . . 11 63 5.2. Interaction with Other TCP Options . . . . . . . . . . . . 11 64 5.3. IP Option Use . . . . . . . . . . . . . . . . . . . . . . 12 65 5.4. Interaction with IP Packet Fragmentation . . . . . . . . . 12 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 7. Forward Compatibility Support . . . . . . . . . . . . . . . . 14 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 72 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 16 73 A.1. Changes from version 03 to 04 . . . . . . . . . . . . . . 16 74 A.2. Changes from version 02 to 03 . . . . . . . . . . . . . . 16 75 A.3. Changes from version 01 to 02 . . . . . . . . . . . . . . 17 76 A.4. Changes from version 00 to 01 . . . . . . . . . . . . . . 17 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 1. Introduction 81 An overlay network is a network of machines distributed throughout 82 multiple autonomous systems within the public Internet (see 83 Figure 1). IP packets from the sender are delivered first to one of 84 the machines that make up the overlay network. That machine will 85 relay the IP packets via one or more other machines in the overlay 86 network to an overlay egress machine that will deliver the packets to 87 the real intended receiver. 89 +----------------------------------------+ 90 | | 91 | INTERNET | 92 | | 93 +-----------+ | +--------------+ | 94 | HOST_1 |-----| OVERLAY_IN_1 |------------+ | 95 +-----------+ | +------------+ | | 96 | | | 97 +-----------+ | +--------------+ +-------------+ | +--------+ 98 | HOST_2 |-----| OVERLAY_IN_2 |-----| OVERLAY_OUT |-----| SERVER | 99 +-----------+ | +--------------+ +-------------+ | +--------+ 100 | | | 101 +-----------+ | +------------+ | | 102 | HOST_3 |-----| OVERLAY_IN_3 |------------+ | 103 +-----------+ | +------------+ | 104 | | 105 +----------------------------------------+ 107 Figure 1 109 Such overlay networks are used to improve the performance of content 110 delivery [IEEE1344002]. Overlay networks are also used for peer-to- 111 peer data transport [RFC5694], and they have been suggested for use 112 in both improved scalability for the internet routing infrastructure 113 [RFC6179] and provisioning of security services (intrusion detection, 114 anti-virus software, etc.) over the public internet [IEEE101109]. 116 In order for an overlay network to intercept IP packets transparently 117 via standard internet routing, the overlay ingress and egress hosts 118 (OVERLAY_IN and OVERLAY_OUT) must be reliably in-path in both 119 directions between the connection-initiating HOST and the SERVER. 120 When this is not the case, packets may be routed around the overlay 121 and sent directly to the receiving host. 123 For public overlay networks, where the ingress and/or egress hosts 124 are on the public internet, packet interception typically uses 125 network address translation for the source (SNAT) or destination 126 (DNAT) addresses [RFC2663] in such a way that the public IP addresses 127 of the true endpoint hosts involved in the data transport are 128 invisible to each other. For example, the actual sender and receiver 129 may use two completely different pairs of source and destination 130 addresses to identify the connection on the sending and receiving 131 networks in cases where both the ingress and egress hosts are on the 132 public internet. 134 --------------------------------------------------------------------- 136 ip hdr contains: ip hdr contains: 137 SENDER -> src = sender --> OVERLAY --> src = overlay2 --> RECEIVER 138 dst = overlay1 dst = receiver 140 --------------------------------------------------------------------- 142 Figure 2 144 In the above example, the sender transmits packets using its own IP 145 address as the source and the IP address of overlay1 as the 146 destination. This is required in order to ensure that the packets 147 are intercepted by overlay1. Next, overlay1 tunnels the packets over 148 the internet to overlay2 with possible transit via other hosts in the 149 overlay network. Finally, overlay2 applies both SNAT and DNAT, 150 transmitting the packets with the IP address of overlay2 as the 151 source and the IP address of the intended receiver as the 152 destination. This use of both SNAT and DNAT is required in order to 153 ensure that return traffic also uses the overlay network. 155 A broad range of issues associated with address sharing have been 156 well documented [RFC6269], and they are not unique to public overlay 157 networks [I-D.boucadair-intarea-host-identifier-scenarios]. However, 158 public overlay networks can pose a bigger traceability problem than 159 most other use cases, due to their combined use of SNAT and DNAT. 161 1.1. Detailed Use Case 163 The following list describes typical operation of a public overlay 164 network used for internet routing. Other types of overlay networks 165 operate somewhat differently with regard to packet handling within 166 the overlay (e.g. TCP connections may be terminated at the overlay 167 ingress and egress hosts), but the use of DNAT and SNAT to facilitate 168 packet interception by the overlay is similar. This detailing of 169 overlay operation is presented in order to provide context for the 170 solution-set analysis that follows. 172 o The sending endpoint host performs a DNS lookup that returns the 173 IP address of a machine on the overlay network. The sending 174 endpoint addresses its packets with its own public IP address as 175 the source and the provided overlay IP address as the destination. 177 o The overlay ingress host receives the packet on its public IP 178 address, and forwards the packet through the overlay tunnel to the 179 egress host. The overlay egress host performs SNAT, replacing the 180 source IP address of the sending endpoint with its own IP address 181 in order to ensure that return traffic will also use the overlay 182 network. This use of SNAT hides the client's public IP address 183 for the receiving network. 185 o The overlay egress host is located on the receiver's network, 186 which means there is a relatively small set of source addresses 187 used for connections between the overlay egress host and the 188 application server. 190 o For load balancing and diagnostic purposes, it is important for 191 one or more machines on the receiver's network to be able to 192 determine the public IP address associated with the sending host 193 and the destination IP address used by the sending host (i.e. the 194 addresses that were hidden by the overlay due to the use of SNAT 195 and DNAT). 197 o The data transferred via the overlay network is typically 198 encrypted (e.g. using SSL) such that the overlay network can apply 199 network and transport layer optimizations but cannot access 200 information provided at the application layer. 202 o For diagnostic purposes, the overlay network must also support 203 traceroute using UDP probe packets. 205 1.2. Solution-set Analysis 207 A detailed analysis of various solutions to the problem of revealing 208 the sending host's ID information to the receiver is presented by 209 [RFC6967]. A solution that is suitable for overlay networks will 210 have the following properties: 212 o The method must support both TCP and UDP. 214 o The method must work in the presence of encrypted traffic. 216 o The method must have a high success ratio for existing servers and 217 networks. 219 o The method must have a minimal impact on performance. 221 o The method must support provision of multiple addresses. 223 o The method must provide client identification at connection 224 initiation. 226 Based on the above referenced analysis and overlay network 227 suitability requirements, the best-fit solution for providing address 228 visibility for application data flows is to use a TCP option. A 229 feasibility assessment of two proposed TCP host ID options is 230 provided by [I-D.abdo-hostid-tcpopt-implementation]. Although the 231 options implemented for that assessment do not meet the "multiple 232 address" criteria highlighted above, the proof-of-concept 233 implementations and testing show that this category of solution is 234 workable. 236 Unfortunately, there is no solution for UDP traffic that meets all of 237 the above criteria. However, in the case where the full path from 238 the overlay egress machine to the application server is under common 239 administrative control, it is possible to mitigate the shortcomings 240 associated with IP options and generate both a high success ratio and 241 low-to-medium performance impact when using an IP option to 242 communicate the address information. For this reason, provision of 243 an IP option can be useful enough for overlay networks to be worth 244 consideration. 246 It should be noted that IPv4 and TCP protocol options can provide 247 only limited support for IPv6 addresses. Inclusion of even a single 248 IPv6 address would require the option to consume nearly half of the 249 total option space provided by TCP and IPv4, which means that the 250 entire TCP option space would be consumed for SYN packets that 251 include the most commonly used options (i.e. MSS, WSOPT, SACK 252 permitted, and TSOPT). This may prevent effective use of the IPv4 253 and TCP protocol options for communicating IPv6 addresses in some 254 circumstances. 256 This document describes IPv4 [RFC0791], IPv6 [RFC2460], and TCP 257 [RFC0793] options for communicating sender-side address information 258 from the overlay to the destination network/machine. The list of 259 addresses specified in the option may include any addresses that 260 might be useful to the eventual receiver, including but not limited 261 to the source and destination addresses as seen by the sender. 263 2. Terminology 265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 266 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 267 document are to be interpreted as described in RFC2119 [RFC2119]. 269 3. Option Format 271 Some implementations already exist for version 1 of the overlay path 272 option. However, version 1 of the option does not provide support 273 for communicating IPv6 addresses in either the IPv4 or TCP option. 274 Both version 1 and version 2 of the option are described here in 275 order to reflect the requirements of current and future implementors. 277 It is up to the implementor whether version 1 is supported or both 278 versions are supported. A receiving implementation that supports 279 version 2 MUST also support version 1. The format changes defined 280 for version 2 directly support the required backward compatibility. 282 When a receiving implementation encounters the overlay path option 283 with an unsupported version number, the receiver MAY either ignore 284 the option or drop the packet. The appropriate response will be 285 dependent upon how the overlay path option's value is used by the 286 receiver. 288 3.1. Version 1 290 Version 1 of the option supports only IPv4 addresses. The option 291 format for both IPv4 and TCP is identical. 293 +---------+---------+---------+--------------------------------+ 294 |Type/Kind| Length | Version | Addresses ... 295 +---------+---------+---------+--------------------------------+ 296 1 1 1 4 x Address Count 297 ---------------------------------------------------------------- 299 Figure 3 301 IPv4 Type: The type value for IPv4 is TBD-IP4-FULL (see also IANA 302 Considerations (Section 8)). 304 Copied flag: 1 (All fragments must carry the option.) 306 Option class: 2 (debugging/measurement) 308 Option number: TBD-IP4 (decimal) 310 TCP Kind: The option kind value for TCP is TBD-TCP (see also IANA 311 Considerations (Section 8)). 313 Length: The length of the option is variable, based on the number of 314 addresses provided. The minimum value is 7 (3 1-octet fields plus 315 one 4-octet address). The option MUST be ignored if the length 316 value cannot represent 3 octets plus a list of 4-octet address 317 value. 319 Version: The version number is 1. 321 Addresses: Version 1 of the option supports only IPv4 addresses. 322 The remainder of the option space is filled with standard 32-bit 323 IPv4 addresses. In practice, the first address will be the public 324 source address used by the sender and the second address (if 325 present) will be the public destination address used by the 326 sender. However, the nature of the addresses provided may vary 327 depending on the nature of the overlay network in question and is 328 not required to include every IP address used for the connection. 329 The list of IP addresses MUST be provided in order of traversal 330 from sender to receiver. 332 3.2. Version 2 334 Version 2 of the options supports either IPv4 addresses or IPv6 335 addresses, but it does not support a mix of IPv4 and IPv6 options 336 within the same option value. Version 2 provides not only IPv4 and 337 TCP options, but also an IPv6 option for inclusion in the IPv6 Hop- 338 by-hop Options header. When IPv6 address support is required, the 339 implementation SHOULD use the IPv6 header option whenever possible in 340 order to avoid exhaustion of the TCP option space. The option format 341 for all three protocols is identical. 343 +---------------+---------------+---------------+-------------------\ 344 | Type/Kind | Length |Fmly| Version | Addresses ... 345 +---------------+---------------+---------------+-------------------\ 346 8b 8b | 3b 5b | 347 ----------------- 348 1 1 1 Addr Size x Count 349 --------------------------------------------------------------------- 351 Figure 4 353 IPv4 Type: Identical to Version 1. 355 TCP Kind: Identical to Version 1. 357 IPv6 Type: The Type value for IPv6 is TBD-IP6 (see also IANA 358 Considerations (Section 8)). 360 act flag: 00 (skip over option) 361 chg flag: 0 (option data does not change en-route) 363 rest: TBD-IP6 (decimal) 365 Length: The length of the option is variable, based on the address 366 family and the number of addresses provided. The minimum value is 367 7 (3 1-octet fields plus one 4-octet IPv4 address). The option 368 MUST be ignored if the length value cannot represent 3 octets plus 369 a list of addresses of the correct address family. 371 Family/Version: The third octet is comprised of two fields: family 372 and version.Note that the possible family values have been 373 selected to support backward compatibility with the 8-bit version 374 field in version 1 of the option format. 376 Family: The high order 3 bits of the third octet indicate the 377 address family for all IP addresses represented in the variable- 378 length Addresses field. The allowed values are: 380 0: Address family is IPv4. 382 1: Address family is IPv6. 384 Version: The low order 5 bits of the third octet indicate the 385 protocol version number. The version number is 2. 387 Addresses: The remainder of the option space is filled with either 388 32-bit IPv4 or 128-bit IPv6 addresses, as indicated by the Family 389 field. In practice, the first address will be the public source 390 address used by the sender and the second address (if present) 391 will be the public destination address used by the sender. 392 However, the nature of the addresses provided may vary depending 393 on the nature of the overlay network in question and is not 394 required to include every IP address used for the connection. The 395 list of IP addresses MUST be provided in order of traversal from 396 sender to receiver. 398 4. Network Traversal 400 The following block diagram illustrates the use of addresses in the 401 IPv4 header and the overlay path option as a packet traverses the 402 network from sender to receiver. The diagram assumes that the 403 overlay network uses separate addresses (overlay1 and overlay2) for 404 ingress and egress, and that the receiver has a need to know both 405 addresses used by the sender. 407 ----------------------------------------------------------------- 409 SENDER 410 | 411 V 412 +----------------+ 413 | | 414 | src: sender | 415 | dst: overlay1 | 416 | opt: none | 417 | | 418 +----------------+ 419 | 420 V 421 OVERLAY 422 NETWORK 423 | 424 V 425 +----------------+ 426 | | 427 | src: overlay2 | 428 | dst: receiver | 429 | opt: sender | 430 | overlay1 | 431 | | 432 +----------------+ 433 | 434 V 435 RECEIVER 437 ----------------------------------------------------------------- 439 Figure 5 441 5. Option Use 443 This section describes considerations for use of the option, 444 including interactions with other options and the impact on packet 445 sizes. 447 5.1. TCP Option Use 449 Use of the TCP option allows an implementation to minimize the impact 450 of this option on bandwidth utilization. Due to the connection- 451 oriented nature of TCP, the addresses used by the overlay network 452 cannot not change throughout the life of the connection. For this 453 reason, it is not necessary for the overlay network to include the 454 overlay path option on every packet. On the other hand, it is not 455 enough for the option to be provided exclusively in the TCP SYN 456 packet because the use of SYN cookies, for example, would mean that 457 connection state is not stored until completion of the three-way 458 handshake. For this reason, the overlay network MUST include the TCP 459 overlay path option in every outgoing packet until the receiver has 460 either acknowledged or transmitted at least one byte of real data. 461 The overlay network SHOULD discontinue inclusion of the TCP overlay 462 path option after the first byte is either received or acknowledged. 463 The receiver MAY ignore the TCP overlay path option on subsequent 464 packets after successfully processing one instance of the option 465 attached to a single in-order TCP packet. 467 5.2. Interaction with Other TCP Options 469 The TCP option space is limited to a maximum of 40 bytes. Inclusion 470 of the TCP overlay path option depends upon the availability of space 471 after any other options have been added. 473 As explained in [RFC6824], typical SYN packets use 19 bytes of this 474 space if the options are packed or 24 bytes if the options are word 475 aligned. In the optimistic case, 21 bytes are available in the SYN's 476 option space, which allows up to 4 IPv4 addresses or a single IPv6 477 address to be included in the overlay path option. If any TCP 478 options are included in the SYN outside of those most commonly seen 479 (MSS, window scale, SACK permitted, and timestamp), or if the option 480 space is word aligned, there is no space available for even a single 481 IPv6 address and there is limited space (perhaps even no space) 482 available for IPv4 addresses. 484 As [RFC6824] also explains, ACK packets and data packets typically 485 only carry the timestamp option, which requires 10 bytes (12 with 486 padding). However, use of SACK and/or TCP options outside of the set 487 of typical options can consume all of the remaining option space 488 under some conditions. In other words, it is usually possible to 489 include the TCP overlay path option in an ACK packet, but there is no 490 guarantee that this will be true. 492 The TCP overlay path option MUST NOT be applied to packets when there 493 is not at least enough option space available to include one address 494 of the required family. When multiple addresses are expected but 495 there is not enough option space available to include all of the 496 expected addresses, the overlay path address list SHOULD be shortened 497 to include only the number of addresses that can fit within the 498 available option space, with preference given to inclusion of the 499 addresses that would naturally appear first in the list. The 500 receiver's handling of connections that do not include the overlay 501 path option will depend upon the local policy, but the receiver 502 SHOULD accept connections without the TCP overlay path option if 503 there is no mechanism in place to guarantee that space will be 504 available for the option when necessary. 506 5.3. IP Option Use 508 IP is not connection oriented, which means that the above described 509 optimization for TCP is not possible. In order to make effective use 510 of the TCP optimization, an overlay network SHOULD only send the IP 511 option on packets that do not use TCP as the transport layer 512 protocol. When the IP option is in use, the overlay network MUST 513 transmit the option with every packet. The receiver MUST NOT assume 514 that that addresses in the IP overlay path option will remain 515 consistent, but instead MUST be prepared to handle address changes in 516 an application appropriate way. 518 Use of the IP option is dependent upon support for IP options in all 519 routers between the overlay egress point and the packet receiver. If 520 any router along the path is configured to drop packets with unknown 521 IPv4 options (or any IP options, as is sometimes done as part of a 522 DoS protection scheme), then use of the IP option will cause 523 connections to simply fail. For this reason, the IP option SHOULD 524 only be used in environments where the full path between the overlay 525 egress machine and the packet receiver is under common administrative 526 control. 528 5.4. Interaction with IP Packet Fragmentation 530 As noted above, overlay networks commonly use tunneling in order to 531 route packets across the overlay, which requires special handling in 532 order to avoid problems associated with packet fragmentation (see 533 [RFC4459]). It is likely to be the case that the overlay network's 534 tunneling method adds at least as much overhead to tunneled packets 535 as the space required for the overlay path option. When this is 536 true, use of the overlay path option does not add new packet 537 fragmentation issues to be resolved. 539 The overlay path option SHOULD NOT be applied to packets if the 540 resulting packet size violates the path MTU between the egress host 541 and the receiver. If the resulting packet size would be too large, 542 the overlay path address list SHOULD be shortened to include only the 543 number of addresses that can fit without generating an oversized 544 packet, with preference given to the addresses that would naturally 545 appear first in the list. If even a single address cannot be 546 transmitted in the overlay path option without violating the MTU, the 547 overlay path option SHOULD NOT be added to the packet. The 548 receiver's handling of packets that do not include the overlay path 549 option will depend upon the local policy, but the receiver SHOULD 550 accept packets without the overlay path option if there is no 551 mechanism in place to guarantee that space will be available for the 552 option when necessary. 554 6. Security Considerations 556 This specification provides no authentication/validity verification 557 for the data contained in the addresses field. For this reason, the 558 data contained in the addresses field of the new option cannot itself 559 be considered inherently secure. In other words, confidence in the 560 validity of the source address of the IPv4/IPv6 packet does not 561 translate into confidence in the validity of the addresses in the 562 overlay path option. With this exception, this specification does 563 not alter the inherent security of IPv4, IPv6, or TCP. 565 The addresses provided in the option SHOULD NOT be used for purposes 566 that require a trust relationship between the overlay network and the 567 receiver (e.g. billing and/or intrusion prevention) unless a 568 mechanism outside the scope of this specification is used to ensure 569 the necessary level of trust. One possible example of such a 570 mechanism would be to place the overlay egress host on the receiver's 571 own network and to configure the receiver's firewall to drop any 572 packets from external hosts that provide the overlay path option. 573 When the receiving network uses the values provided by the option in 574 a way that does not require trust (e.g. maintaining session affinity 575 in a load-balancing system), then use of a mechanism to enforce the 576 trust relationship might not be required. 578 As explained above, the intention of both the TCP and IP options is 579 to provide the receiver with public IP addresses that it would 580 otherwise have seen if the overlay network were not in use. There 581 are security implications associated with exposing a network's use of 582 the private [RFC1918] address space to the public internet, and for 583 this reason, the overlay path option SHOULD NOT be used to 584 communicate RFC1918 addresses in packets that traverse the public 585 internet. 587 7. Forward Compatibility Support 589 The most common use of this option on the internet today will require 590 recording IP addresses for a single address family only. However, it 591 may be important in the future to be able to record a mix of IPv4 and 592 IPv6 addresses. Alternatively, future security requirements may 593 demand the use of, for example, a keyed hash for data integrity and 594 authentication purposes and/or inclusion of additional information 595 specific to the sender's connection. 597 To balance current-day performance and efficiency against the need 598 for future extensibility, the option includes a version field, so 599 that future requirements can be met without the need to consume a new 600 option number. 602 8. IANA Considerations 604 [Paragraphs below in braces should be removed by the RFC Editor upon 605 publication] 607 [The TCP Overlay Path Option requires that IANA allocate a value from 608 the TCP option kind namespace, to be replaced for TBD-TCP throughout 609 this document.] 611 [The IPv4 Overlay Path Option requires that IANA allocate a value 612 from the IP option number namespace. The copy flag for this option 613 is 1 and the class for this option is 2. The assigned number will 614 replace TBD-IP4 throughout this document, and the full type value 615 (representing copy, class, and number) will replace TBD-IP4-FULL 616 throughout the document.] 618 [The IPv6 Overlay Path Option requires that IANA allocate a value 619 from the IPv6 parameters: hop-by-hop options namespace. The action 620 for this option is 00 and the change flag for this option is 0. The 621 assigned number will replace TBD-IP6 throughout this document.] 623 This document defines the TCP Overlay Path option, described in 624 Section 3.1 and Section 3.2. This option has been assigned the 625 option number TBD-TCP by IANA action. 627 This document also defines the IPv4 Overlay Path option, described in 628 Section 3.1 and Section 3.2. This option has been assigned the 629 option number TBD-IP4-FULL by IANA action. 631 This document also defines the IPv6 Overlay Path hop-by-hop option, 632 described in Section 3.2. This option has been assigned the option 633 number TBD-IP6 by IANA action. 635 This document defines no new namespaces. 637 9. References 639 9.1. Normative References 641 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 642 September 1981. 644 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 645 RFC 793, September 1981. 647 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 648 E. Lear, "Address Allocation for Private Internets", 649 BCP 5, RFC 1918, February 1996. 651 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 652 Requirement Levels", BCP 14, RFC 2119, March 1997. 654 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 655 (IPv6) Specification", RFC 2460, December 1998. 657 9.2. Informative References 659 [I-D.abdo-hostid-tcpopt-implementation] 660 Abdo, E., Boucadair, M., and J. Queiroz, "HOST_ID TCP 661 Options: Implementation & Preliminary Test Results", 662 draft-abdo-hostid-tcpopt-implementation-03 (work in 663 progress), July 2012. 665 [I-D.boucadair-intarea-host-identifier-scenarios] 666 Boucadair, M., Binet, D., Durel, S., Chatras, B., Reddy, 667 T., and B. Williams, "Host Identification: Use Cases", 668 draft-boucadair-intarea-host-identifier-scenarios-03 (work 669 in progress), March 2013. 671 [IEEE101109] 672 Salah, K., Calero, J., Zeadally, S., Almulla, S., and M. 673 ZAaabi, "Using Cloud Computing to Implement a Security 674 Overlay Network, IEEE Security & Privacy, 21 June 2012. 675 IEEE Computer Society Digital Library.", June 2012. 677 [IEEE1344002] 678 Byers, J., Considine, J., Mitzenmacher, M., and S. Rost, 679 "Informed content delivery across adaptive overlay 680 networks: IEEE/ACM Transactions on Networking, Vol 12, 681 Issue 5, ppg 767-780", October 2004. 683 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 684 Translator (NAT) Terminology and Considerations", 685 RFC 2663, August 1999. 687 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 688 Network Tunneling", RFC 4459, April 2006. 690 [RFC5694] Camarillo, G. and IAB, "Peer-to-Peer (P2P) Architecture: 691 Definition, Taxonomies, Examples, and Applicability", 692 RFC 5694, November 2009. 694 [RFC6179] Templin, F., "The Internet Routing Overlay Network 695 (IRON)", RFC 6179, March 2011. 697 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 698 Roberts, "Issues with IP Address Sharing", RFC 6269, 699 June 2011. 701 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 702 "TCP Extensions for Multipath Operation with Multiple 703 Addresses", RFC 6824, January 2013. 705 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 706 "Analysis of Potential Solutions for Revealing a Host 707 Identifier (HOST_ID) in Shared Address Deployments", 708 RFC 6967, June 2013. 710 Appendix A. Change History 712 [Note to RFC Editor: Please remove this section prior to 713 publication.] 715 A.1. Changes from version 03 to 04 717 Clarify public overlay network use case regarding NAT. 719 Add some discussion regarding use of option space and packet 720 fragmentation. 722 A.2. Changes from version 02 to 03 724 Clarifications to introduction and use case discussion. 726 Clarify security considerations. 728 A.3. Changes from version 01 to 02 730 Improve IANA Considerations section. 732 A.4. Changes from version 00 to 01 734 Fix inappropriate use of numeric option number placeholders. 736 Author's Address 738 Brandon Williams 739 Akamai, Inc. 740 Cambridge, MA 741 USA 743 Email: brandon.williams@akamai.com