idnits 2.17.1 draft-rosenau-request-v6-option-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 14 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 10, 2018) is 2238 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC0792' is defined on line 590, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 594, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Rosenau 3 Internet-Draft February 10, 2018 4 Intended status: Experimental 5 Expires: August 14, 2018 7 TCP option "request IPv6 connection" 8 draft-rosenau-request-v6-option-00 10 Abstract 12 This document describes an idea for a header "option" for the 13 Transmission Control Protocol (TCP). 15 The extension is used by dual-stack nodes to force the use of the 16 IPv6 protocol instead of the IPv4 protocol when exchanging data over 17 TCP. 19 Especially if one of the two nodes is a NAT64 or NAT46 router it 20 makes sense not to use IPv4 but IPv6 if both nodes are dual-stack 21 nodes. 23 This document also suggests to declare the usage of such a method 24 mandatory for all nodes that use IPv4 addresses that will be assigned 25 by RIRs in the future. 27 Doing so will make it impossible to (mis-) use IPv4 addresses 28 assigned by RIRs to ISPs for IPv4-only nodes that do not support 29 IPv6. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 14, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 1. Introduction 65 Because of the IPv4 address shortage the IPv6 protocol has been 66 developed. Unfortunately many nodes in the internet are still 67 IPv4-only and many ISPs use NATs to establish connections to servers. 69 Some ISPs use NAT46 to allow IPv4-only clients to connect to an 70 IPv6-only server. In many cases both nodes would be able to 71 establish an IPv6 connection instead of an IPv4 connection because 72 the use of the NAT can be avoided in this case. 74 This document describes a TCP [RFC0793] header "option" which allows 75 both nodes to negotiate the use of the IPv6 protocol instead of the 76 IPv4 protocol. 78 2. Terminology 80 2.1. Keywords in capital letters 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 84 "OPTIONAL" in this document are to be interpreted as described in BCP 85 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant 86 implementations. 88 2.2. client 90 In the context of this document a "client" is a node which is 91 establishing a TCP connection to another node by sending the first 92 TCP packet. 94 2.3. server 96 In the context of this document a "server" is a node which is waiting 97 for a client to establish a TCP connection with that node. 99 2.4. NAT64, NAT46 101 A NAT64 is a node which allows an IPv6-only client to connect to an 102 IPv4-only server by translating IPv4 to IPv6 packets and vice versa 103 or by acting as IPv6 server and IPv4 client the same time forwarding 104 the data from one TCP connection to the other one. 106 A NAT46 is a node allowing an IPv4-only client to connect to an 107 IPv6-only server. 109 Note that according to the definitions above NAT64 and NAT46 nodes 110 are both "clients" and "servers" the same time. 112 3. Theory of operation 114 3.1. Connection to an IPv4-only server 116 A connection to a server not supporting this extension looks the 117 following way: 119 client server 120 | | 121 | TCP/IPv4, SYN, V6REQ(00) | 122 +-------------------------------------->| 123 | | 124 | TCP/IPv4, SYN, ACK | 125 |<--------------------------------------+ 126 | | 127 | ... | 129 Figure 1: Request not understood by server 131 The client adds an option described in this document to the "options" 132 field of the TCP header. 134 The server does not understand the option described in this document 135 and it will probably ignore it. The TCP connection will be 136 established "normally"; the option described in this document is not 137 used. 139 3.2. IPv4 negotiated 141 If both the client and the server support this extension but both 142 nodes decide to use IPv4 for the connection the connection looks the 143 following way: 145 client server 146 | | 147 | TCP/IPv4, SYN, V6REQ(00) | 148 +-------------------------------------->| 149 | | 150 | TCP/IPv4, SYN, ACK, V6REQ(10) | 151 |<--------------------------------------+ 152 | | 153 | ... | 155 Figure 2: IPv4 negotiated 157 The server will send the "normal" (SYN/ACK) packet back to the client 158 - as it is done for a normal TCP connection. It will add a certain 159 option to the "options" field of the TCP header indicating that the 160 option in the first packet is understood and supported by the server 161 but it is not used for the current connection. 163 3.3. IPv6 negotiated 165 If the client and the server decide to use IPv6 for the connection 166 the connection looks like this: 168 client server 169 | | 170 | TCP/IPv4, SYN, V6REQ(00) | 171 +-------------------------------------->| 172 | | 173 | TCP/IPv4, RST, V6REQ(11) | 174 |<--------------------------------------+ 175 | | 176 | TCP/IPv6, SYN | 177 +-------------------------------------->| 178 | | 179 | ... | 181 Figure 3: IPv6 negotiated 183 The server sends back a TCP packet containing the IPv6 address of the 184 server and indicating that the IPv4 TCP connection is rejected. 186 The client will re-send an initial TCP packet (SYN) to the server 187 using IPv6. 189 3.4. NAT scenario 191 There is even a situation where using this option in an IPv6 packet 192 makes sense: When using with NAT64. Such a connection looks like 193 this: 195 client NAT server 196 | | | 197 | TCP/IPv6, SYN, V6REQ(00) | | 198 +----------------------------------->| TCP/IP(v4 or v6), SYN, V6REQ(00) | 199 | +------------------------------------>| 200 | | | 201 | | TCP/IP, RST, V6REQ(11) | 202 | TCP/IPv6, RST, V6REQ(11) |<------------------------------------+ 203 |<-----------------------------------+ | 204 | | | 205 | TCP/IPv6, SYN | 206 +------------------------------------------------------------------------->| 207 | | 208 | ... | 210 Figure 4: Using with NATs 212 The NAT64 sends back a TCP packet containing the IPv6 address of the 213 server and indicating that the TCP connection to the NAT's address is 214 rejected. 216 The client will re-send an initial TCP packet (SYN) directly to the 217 server using IPv6 not using the NAT64. 219 4. Option formats 221 4.1. Request packet 223 In the initial TCP packet (the packet sent by the client to the 224 server that has the SYN field set and the ACK field clear) the 225 following TCP header option will be added by the client: 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | TYPE=V6REQ | LENGTH=3 |0 0| CODE | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Figure 5: Request option format 233 The first octet of the option is the code "V6REQ" to be assigned by 234 the IANA 236 The second octet of the option is the length of the option (as 237 described in RFC 793 [RFC0793]). All codes described in this 238 document use a length of 3 octets. 240 The high two bits of the third octet are zero and the low six bits 241 are the code described below. 243 A TCP implementation MUST ignore this option (with the two upper bits 244 in the third octet being zero) when it is found in any other packet 245 but the initial TCP packet (SYN) sent from the client to the server. 247 If a TCP implementation does not understand the "CODE" (or the 248 "LENGTH" field does not match the "CODE" field) it MUST ignore the 249 option but it SHOULD add a "request not understood" option to the 250 packet sent back to the client. 252 4.2. Informational response 254 If client and server decide to use IPv4 for the TCP connection the 255 server answers as if the option was not present (SYN, ACK) but it 256 adds the following option to the "options" field of the TCP header: 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--//---+ 259 | TYPE=V6REQ | LENGTH |1 0| CODE | DATA | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--//---+ 262 Figure 6: Informational response option format 264 The highest bit of the third octet is one and the bit below is set to 265 zero. The low six bits are the code described below. 267 A TCP implementation MUST ignore this option (with the two upper bits 268 in the third octet being one and zero) when it is found in any other 269 packet but the TCP packet (SYN, ACK) sent as response to the first 270 packet. 272 DATA is additional data depending on the "CODE" field. 274 If a TCP implementation does not understand the "CODE" (or the 275 "LENGTH" field does not match the "CODE" field) it MUST ignore the 276 option. 278 4.3. Force restart response 280 If client and server decide to use IPv6 for the TCP connection the 281 server denies the IPv4-based connection and the client shall re- 282 establish a connection via IPv6. 284 The server sends a packet with a special form that any TCP 285 implementation that supports this option MUST understand: 287 The "source port" field contains the "destination port" of the 288 initial packet and vice versa (just like in the case of a "normal" 289 TCP response). 291 The "acknowledgement number" field contains the value of the 292 "sequence number" field in the initial packet and vice versa. (Note 293 that none of the two numbers is incremented.) 295 The "RST" bit MUST be set and "ACK" and "SYN" MUST be zero. The 296 other control bits SHALL be zero. 298 The "options" field in the TCP header contains the following option: 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--//---+ 301 | TYPE=V6REQ | LENGTH |1 1| CODE | DATA | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--//---+ 304 Figure 7: Force restart response option format 306 The highest two bits of the third octet are one. The low six bits 307 are the code described below. 309 A TCP implementation MUST ignore this option (with the two upper bits 310 in the third octet being one) when it is found in any other packet 311 but the TCP packet sent as response to the first packet. 313 No TCP connection has been established between client and server when 314 the server answered with this packet. 316 Typically the "V6REQ" option will be the only option in the TCP 317 header in this case because more options make no sense in this case. 319 4.4. Reserved combination 321 The combination "zero-one" for the highest two bits in the third 322 octet is reserved for future use: 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--//---+ 325 | TYPE=V6REQ | LENGTH |0 1| | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--//---+ 328 Figure 8: Reserved option format 330 A TCP implementation MUST ignore this option (with the two upper bits 331 in the third octet being zero and one) when it is found in any TCP 332 packet. 334 5. Option codes 336 5.1. List of option codes 338 The following option codes are defined: 340 Type* Code Length Code 341 00 1 3 Strong IPv6 request 342 00 2 3 Weak IPv6 request 343 10 3 3 Supported for this port 344 10 4 3 Not supported for this port 345 10 5 4 Request not supported 346 11 6 21 Address to be used 348 (*) 00 = valid in request 349 10 = valid in an informational response 350 11 = valid in a force restart response 352 Figure 9: List of option codes 354 5.2. Strong IPv6 request 356 A client sends this option in the initial TCP packet whenever it 357 desires to use IPv6 for the connection as far as it is possible. 359 If the server understands this option but there is no TCP/IPv6 port 360 which is equivalent to the TCP/IPv4 port the client wants to connect 361 to it MUST answer with "not supported for this port". 363 If the server understands this option AND there is a TCP/IPv6 port 364 which is equivalent to the TCP/IPv4 port the client wants to connect 365 to the server MUST answer with "address to be used". 367 5.3. Weak IPv6 request 369 This option is similar to the "strong IPv6 request" however it is 370 used if the client does not necessarily prefer IPv6 over IPv4. 372 If the server understands the option and there is a TCP/IPv6 373 equivalent for the TCP/IPv4 port but the server also does not prefer 374 using IPv6 over IPv4 the server MUST answer with "supported for this 375 port". 377 The client may later send a "strong IPv6 request" to get information 378 about the TCP/IPv6 port that can be used instead of the TCP/IPv4 379 port. 381 In all other cases the server MUST react on this option the same way 382 as it reacts on a "strong IPv6 request". Especially in the case that 383 the server wants to communicate with the client over IPv6 instead of 384 IPv4 it will answer with "address to be used". 386 5.4. Supported for this port 388 A server sends this option in its first packet (in the answer to the 389 first packet of the TCP connection) as a response to a "weak IPv6 390 request". 392 Using this option it indicates that it would support a "strong IPv6 393 request" for this TCP/IPv4 port. 395 5.5. Not supported for this port 397 A server sends this option in its first packet as a response to a 398 "strong" or "weak IPv6 request". 400 Using this option it indicates that the it is not possible to 401 establish the desired TCP connection via IPv6. 403 5.6. Request not supported 405 A server sends this option in its first packet as a response to any 406 "request" option that was not understood by the server. 408 This is the case when the initial packet from the client contained a 409 "V6REQ" option whose topmost two bits of the third octet were zero 410 but the server did not understand the meaning of that option. (For 411 example if the "CODE" field did not have a value understood by the 412 server.) 414 The server indicates that it ignored the option it did not 415 understand. 417 Note that the "request not supported" option is only of informational 418 kind; the client SHOULD NOT treat this as error message. 420 If the server did not understand the value of the "CODE" field the 421 "request not supported" option has the following form: 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | TYPE=V6REQ | LENGTH=4 |1 0| CODE=5 |L|0| ORG. CODE | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 Figure 10: Request not supported option format 429 "ORG. CODE" is the value of the "CODE" field in the request not 430 understood by the server. 432 "L" is zero if the code is not understood by the server at all. "L" 433 is one if the server understands the code but the length of the 434 option is not correct (currently: 3). 436 Note: If there will be "requests" (type="00") in the future being 437 longer than three octets a "response" indicating "invalid arguments" 438 should be defined. "Request not supported" should not be used in 439 this case. 441 5.7. Address to be used 443 A server sends this option in a "force restart response" 444 (Section 4.3) described above. 446 Doing so the server instructs the client to use IPv6 instead of IPv4 447 to connect to the server. 449 The option has the following form: 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | TYPE=V6REQ | LENGTH=21 |1 1| CODE=6 | | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 454 | | 455 | IPv6 ADDRESS | 456 | +-+-+-+-+-+-+-+-+ 457 | | TCP ... | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | ... PORT | 460 +-+-+-+-+-+-+-+-+ 462 Figure 11: Address to be used option format 464 The "IPv6 ADDRESS" and "TCP PORT" fields are the IPv6 address and the 465 TCP/IPv6 port number of a TCP port which is equivalent to the port 466 the client wanted to connect to using IPv4. 468 Note that especially in the case of NAT46 the IPv6 address may be 469 different for different TCP ports. The TCP port number to be used 470 with IPv6 may also differ from the TCP port number to be used with 471 IPv4 - especially in a NAT46 scenario. 473 The TCP/IPv6 port returned MUST be absolutely equivalent to the TCP/ 474 IPv4 port the client wanted to connect to. This means that when 475 establishing a connection from an IPv6 client to the server there 476 must be no difference in functionality when directly connecting to 477 the TCP/IPv6 port returned by the server compared to connecting to 478 the TCP/IPv4 port via a NAT64. 480 6. Using the option with IPv6 482 As described above the option may also used in TCP/IPv6 packets. 483 This typically only makes sense if the server is a NAT. 485 If the server understands this option, it is a NAT and the client can 486 connect to the actual server (behind the NAT) directly the NAT will 487 respond to a "strong IPv6 request" with an "address to be used" 488 answer. 490 If the server understands this option but it is not a NAT or the 491 client cannot connect to the actual server directly it will respond 492 with "not supported for this port". 494 A NAT may behave differently for different ports - e.g. if one port 495 is forwarded to a server which can be accessed directly and another 496 port is forwarded to a server which cannot be accessed directly. 498 The same is true when a "weak IPv6 request" is received; in this case 499 the NAT may decide if it answers with a "supported for this port" 500 option or with "address to be used". 502 7. Suggestion for IPv4 addresses assigned by the RIRs 504 IPv4 addresses are very rare. 506 Unfortunately there still seem to be ISPs who receive IPv4 addresses 507 from the RIRs using these addresses for IPv4-only nodes. 509 To force these ISPs to use the IPv4 addresses they receive from the 510 RIRs for dual-stack nodes and translation mechanisms only the author 511 of the document has the following suggestion: 513 - RIRs are only allowed to assign IPv4 addresses if the receiver 514 guarantees that the receiver will observe some rules for ALL IPv4 515 addresses used by the receiver. 517 - "ALL IPv4 addresses" means: 519 - An organisation already having IPv4 addresses may only 520 receive new IPv4 addresses from a RIR if it already observes 521 the rules for all IPv4 addresses in use by this organisation. 522 As soon as it receives the new IPv4 addresses observing the 523 rules will be mandatory for the "old" IPv4 addresses! 525 - In a situation where an organisation using IPv4 addresses 526 being subject to these rules and one organisation using IPv4 527 addresses not being subject to these rules merge (e.g. in a 528 company takeover) the merged organisation MUST decide if ALL 529 IPv4 used by the organisation will be subject to these rules or 530 if the IPv4 addresses being subject to these rules before the 531 merge are returned to the RIR. 533 - The RIR should revoke the IPv4 addresses when the rules are 534 violated. 536 Possible rules could be (note that most of these rules are already 537 mandatory for "new implementations" according to RFC 6540 [RFC6540]): 539 - All functionality a node supports via IPv4 MUST also be 540 supported via IPv6 - regardless if the functionality uses TCP, UDP 541 or other protocols. 543 - This also applies to the DNS entry: There MUST be an "AAAA" 544 record for each host name having an "A" record using such an 545 address. 547 - The only exception is the use of a secondary host name for 548 forcing an IPv4 connection like "www.ipv4.example.com" (force 549 IPv4) instead of "www.example.com" (use the default protocol); the 550 operator of the host MUST ensure that the secondary host name is 551 only used in case of problems with the IPv6 connection. 552 Especially it is not allowed to publish statements like: "The 553 address of our home page is www.ipv4.example.com". 555 - On the other hand such a node MAY support functionality which is 556 only accessible via IPv6 but not via IPv4. 558 - Nodes using these IPv4 addresses MUST prefer IPv6 over IPv4 559 (Example: If a node wants to establish a connection to a host 560 having both an "AAAA" and an "A" DNS record these nodes MUST first 561 try to use the "AAAA" record; only if this fails they MAY use the 562 "A" entry.) 563 - All clients using these IPv4 addresses MUST use the "strong IPv6 564 request" option in outgoing TCP connections over IPv4. This will 565 force the clients to use the direct IPv6 connection in the case of 566 a NAT46. It will also guarantee that it is verifiable if the 567 client using this IPv4 address supports IPv6. 569 - All servers using these IPv4 addresses MUST respond to a 570 "strong" and/or "weak IPv6 request" using "address to be used" 571 (and refuse a TCP connection via IPv4). This will reduce the load 572 of NAT64 servers. It will also guarantee that it is verifiable if 573 the server using this IPv4 address supports IPv6. 575 8. References 577 8.1. Normative References 579 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 580 RFC 793, DOI 10.17487/RFC0793, September 1981, 581 . 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, 585 DOI 10.17487/RFC2119, March 1997, 586 . 588 8.2. Informational References 590 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 591 RFC 792, DOI 10.17487/RFC0792, September 1981, 592 . 594 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 595 NAT64: Network Address and Protocol Translation from IPv6 596 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 597 April 2011, . 599 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 600 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 601 RFC 6540, DOI 10.17487/RFC6540, April 2012, 602 . 604 Author's Address 606 Martin D. J. Rosenau 608 Email: martin@rosenau-ka.de