idnits 2.17.1 draft-boucadair-tcpm-dhc-converter-03.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 357 has weird spacing: '...ngth is is t...' -- The document date (October 7, 2019) is 1634 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) == Unused Reference: 'RFC0793' is defined on line 429, but no explicit reference was found in the text == Unused Reference: 'RFC7844' is defined on line 438, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-tcpm-converters-12 ** Downref: Normative reference to an Experimental draft: draft-ietf-tcpm-converters (ref. 'I-D.ietf-tcpm-converters') ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Standards Track Orange 5 Expires: April 9, 2020 T. Reddy 6 McAfee 7 October 7, 2019 9 DHCP Options for 0-RTT TCP Converters 10 draft-boucadair-tcpm-dhc-converter-03 12 Abstract 14 Because of the lack of important TCP extensions, e.g., Multipath TCP 15 support at the server side, some service providers now consider a 16 network-assisted model that relies upon the activation of a dedicated 17 function called Transport Converters. For example, network-assisted 18 Multipath TCP deployment models are designed to facilitate the 19 adoption of Multipath TCP for the establishment of multi-path 20 communications without making any assumption about the support of 21 Multipath TCP by the remote servers. Transport Converters located in 22 the network are responsible for establishing multi-path 23 communications on behalf of endpoints, thereby taking advantage of 24 Multipath TCP capabilities to achieve different goals that include 25 (but are not limited to) optimization of resource usage (e.g., 26 bandwidth aggregation), of resiliency (e.g., primary/backup 27 communication paths), and traffic offload management. 29 This document focuses on the explicit deployment scheme where the 30 identity of the Transport Converters is explicitly configured on 31 connected hosts. This document specifies DHCP (IPv4 and IPv6) 32 options to configure hosts with Converters parameters. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 9, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. DHCPv6 Converter Option . . . . . . . . . . . . . . . . . . . 4 70 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 5 72 4. DHCPv4 Converter Option . . . . . . . . . . . . . . . . . . . 6 73 4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.2. DHCPv4 Client Behavior . . . . . . . . . . . . . . . . . 7 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 6.1. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 8 78 6.2. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . . 8 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 8.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Appendix A. DHCP Server Configuration Guidelines . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 One of the promising deployment scenarios for Multipath TCP (MPTCP, 89 [RFC6824]) is to enable a host or a Customer Premises Equipment (CPE) 90 connected to multiple networks (e.g., DSL, LTE, WLAN) to optimize the 91 usage of such resources. A deployment scenario relies on MPTCP 92 Conversion Points (called, Transport Converters 93 [I-D.ietf-tcpm-converters]). A Converter terminates the extended TCP 94 (e.g., MPTCP, TCPinc) sessions established from a host, before 95 redirecting traffic into a legacy TCP session. Further Network- 96 Assisted MPTCP deployment and operational considerations are 97 discussed in [I-D.nam-mptcp-deployment-considerations]. 99 Figure 1 shows a deployment example of the Converters to assist 100 establishing MPTCP connections. 102 +------------+ _--------_ +----------------+ 103 | | ( LTE ) | | 104 | Host +=======+ +===+ Backbone | 105 | | (_ _) | Network | 106 | | (_______) |+--------------+| 107 | | IP Network #1 || Converter ||------> Internet 108 | | || || 109 | | |+--------------+| 110 | | IP Network #2 | | 111 | | _--------_ | | 112 | | ( DSL ) | | 113 | +=======+ +==+ | 114 | | (_ _) | | 115 +------------+ (_______) +----------------+ 117 Figure 1: "Network-Assisted" MPTCP Design 119 [I-D.ietf-tcpm-converters] specifies the Converter as a function that 120 is installed by a network operator to aid the deployment of TCP 121 extensions and to provide the benefits of such extensions to clients. 122 A Transport Converter supports one or more TCP extensions. 124 [I-D.ietf-tcpm-converters] assumes the explicit mode that consists in 125 configuring explicitly the reachability information of the 126 Converter(s) on a host. 128 This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC8415] options 129 that can be used to configure hosts with Converter IP addresses. 131 This specification assumes a Converter is reachable through one or 132 multiple IP addresses. As such, a list of IP addresses can be 133 returned in the DHCP Converter option. Also, it assumes the various 134 network attachments provided to an MPTCP-enabled host are managed by 135 the same administrative entity. 137 2. Terminology 139 This document makes use of the following terms: 141 o Converter: a function that terminates a transport flow and relays 142 all data received over it over another transport flow. This 143 element is located upstream in the network. One or multiple 144 Converters can be deployed in the network side. The Converter 145 achieves the following: 147 * Listen for client sessions; 148 * Receive from a client the address of the final target server; 149 * Setup a session to the final server; 150 * Relay control messages and data between the client and the 151 server; 152 * Perform access controls according to local policies. 154 o DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC8415]. 155 o DHCP client denotes a node that initiates requests to obtain 156 configuration parameters from one or more DHCP servers. 157 o DHCP server refers to a node that responds to requests from DHCP 158 clients. 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in BCP 163 14 [RFC2119][RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 3. DHCPv6 Converter Option 168 3.1. Format 170 The DHCPv6 Converter option can be used to configure a list of IPv6 171 addresses of a Converter. 173 The format of this option is shown in Figure 2. As a reminder, this 174 format follows the guidelines for creating new DHCPv6 options 175 (Section 5.1 of [RFC7227]). 177 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | OPTION_V6_CONVERT | Option-length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | | 182 | ipv6-address | 183 | | 184 | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | | 187 | ipv6-address | 188 | | 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | ... | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 2: DHCPv6 Converter option 196 The fields of the option shown in Figure 2 are as follows: 198 o Option-code: OPTION_V6_CONVERT (TBA, see Section 6.1) 199 o Option-length: Length of the 'Converter IP Address(es)' field in 200 octets. MUST be a multiple of 16. 201 o Converter IPv6 Addresses: Includes one or more IPv6 addresses 202 [RFC4291] of the Converter to be used by the TCP client. 204 Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) 205 are allowed to be included in this option. 207 To return more than one Converter to the requesting DHCPv6 client, 208 the DHCPv6 server returns multiple instances of OPTION_V6_CONVERT. 209 Some guidelines for DHCP servers are elaborated in Appendix A. 211 3.2. DHCPv6 Client Behavior 213 Clients MAY request option OPTION_V6_CONVERT, as defined in 214 [RFC8415], Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7. 215 As a convenience to the reader, we mention here that the client 216 includes requested option codes in the Option Request Option. 218 The DHCPv6 client MUST be prepared to receive multiple instances of 219 OPTION_V6_CONVERT; each instance is to be treated separately as it 220 corresponds to a given Converter: there are as many Converters as 221 instances of the OPTION_V6_CONVERT option. 223 If an IPv4-mapped IPv6 address is received in OPTION_V6_CONVERT, it 224 indicates that the Converter has the corresponding IPv4 address. 226 The DHCPv6 client MUST silently discard multicast and host loopback 227 addresses [RFC6890] conveyed in OPTION_V6_CONVERT. 229 4. DHCPv4 Converter Option 231 4.1. Format 233 The DHCPv4 Converter option can be used to configure a list of IPv4 234 addresses of a Converter. The format of this option is illustrated 235 in Figure 3. 237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Code | Length | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | List-Length | List of | 242 +-+-+-+-+-+-+-+-+ | 243 / Converter IPv4 Addresses / 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 245 | List-Length | List of | | 246 +-+-+-+-+-+-+-+-+ | | 247 / Converter IPv4 Addresses / | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 249 . ... . Optional 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 251 | List-Length | List of | | 252 +-+-+-+-+-+-+-+-+ | | 253 / Converter IPv4 Addresses / | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 256 Figure 3: DHCPv4 Converter option 258 The fields of the option shown in Figure 3 are as follows: 260 o Code: OPTION_V4_CONVERT (TBA, see Section 6.2); 261 o Length: Length of all included data in octets. The minimum length 262 is 5. 263 o List-Length: Length of the "List of Converter IPv4 Addresses" 264 field in octets; MUST be a multiple of 4. 265 o List of Converter IPv4 Addresses: Contains one or more IPv4 266 addresses of the Converter to be used by the TCP client. The 267 format of this field is shown in Figure 4. 269 o OPTION_V4_CONVERT can include multiple lists of Converter IPv4 270 addresses; each list is treated separately as it corresponds to a 271 given Converter. 273 When several lists of Converter IPv4 addresses are to be included, 274 "List-Length" and "Converter IPv4 Addresses" fields are repeated. 276 0 8 16 24 32 40 48 277 +-----+-----+-----+-----+-----+-----+-- 278 | a1 | a2 | a3 | a4 | a1 | a2 | ... 279 +-----+-----+-----+-----+-----+-----+-- 280 IPv4 Address 1 IPv4 Address 2 ... 282 This format assumes that an IPv4 address is encoded as a1.a2.a3.a4. 284 Figure 4: Format of the List of Converter IPv4 Addresses 286 OPTION_V4_CONVERT is a concatenation-requiring option. As such, the 287 mechanism specified in [RFC3396] MUST be used if OPTION_V4_CONVERT 288 exceeds the maximum DHCPv4 option size of 255 octets. 290 Some guidelines for DHCP servers are elaborated in Appendix A. 292 4.2. DHCPv4 Client Behavior 294 To discover one or more Converters, the DHCPv4 client MUST include 295 OPTION_V4_CONVERT in a Parameter Request List Option [RFC2132]. 297 The DHCPv4 client MUST be prepared to receive multiple lists of 298 Converter IPv4 addresses in the same OPTION_V4_CONVERT; each list is 299 to be treated as a separate Converter instance. 301 The DHCPv4 client MUST silently discard multicast and host loopback 302 addresses [RFC6890] conveyed in OPTION_V4_CONVERT. 304 5. Security Considerations 306 The security considerations in [RFC2131] and [RFC8415] are to be 307 considered. 309 Generic Convert security considerations are discussed in 310 [I-D.ietf-tcpm-converters]. 312 MPTCP-related security considerations are discussed in [RFC6824]. 314 Means to protect the Converter against Denial-of-Service (DoS) 315 attacks must be enabled. Such means include the enforcement of 316 ingress filtering policies at the boundaries of the network. In 317 order to prevent exhausting the resources of the Converter by 318 creating an aggressive number of simultaneous subflows for each MPTCP 319 connection, the administrator should limit the number of allowed 320 subflows per host for a given connection. 322 Attacks outside the domain can be prevented if ingress filtering is 323 enforced. Nevertheless, attacks from within the network between a 324 host and a Converter instance are yet another actual threat. Means 325 to ensure that illegitimate nodes cannot connect to a network should 326 be implemented. 328 Traffic theft is also a risk if an illegitimate Converter is inserted 329 in the path. Indeed, inserting an illegitimate Converter in the 330 forwarding path allows to intercept traffic and can therefore provide 331 access to sensitive data issued by or destined to a host. To 332 mitigate this threat, secure means to discover a Converter should be 333 enabled. 335 6. IANA Considerations 337 6.1. DHCPv6 Option 339 IANA is requested to assign the following new DHCPv6 Option Code in 340 the registry maintained in http://www.iana.org/assignments/ 341 dhcpv6-parameters: 343 Option Name Value 344 ----------------- ----- 345 OPTION_V6_CONVERT TBA 347 6.2. DHCPv4 Option 349 IANA is requested to assign the following new DHCPv4 Option Code in 350 the registry maintained in http://www.iana.org/assignments/bootp- 351 dhcp-parameters/: 353 Option Name Value Data length Meaning 354 ----------------- ----- ----------- --------------------------------- 355 OPTION_V4_CONVERT TBA Variable; Includes one or multiple lists of 356 the minimum Converter IP addresses; each list 357 length is is treated as a separate 358 5. Converter. 360 7. Acknowledgements 362 Many thanks to Olivier Bonaventure for the feedback on this document. 363 Olivier suggested to define the option as a name but that design 364 approach was debated several times within the dhc wg. 366 Thanks to Dan Seibel, Bernie Volz, Niall O'Reilly, Simon Hobson, and 367 Ted Lemon for the feedback on the dhc wg mailing list. 369 8. References 371 8.1. Normative References 373 [I-D.ietf-tcpm-converters] 374 Bonaventure, O., Boucadair, M., Gundavelli, S., Seo, S., 375 and B. Hesmans, "0-RTT TCP Convert Protocol", draft-ietf- 376 tcpm-converters-12 (work in progress), October 2019. 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, 380 DOI 10.17487/RFC2119, March 1997, 381 . 383 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 384 RFC 2131, DOI 10.17487/RFC2131, March 1997, 385 . 387 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 388 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 389 . 391 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 392 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 393 DOI 10.17487/RFC3396, November 2002, 394 . 396 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 397 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 398 2006, . 400 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 401 "TCP Extensions for Multipath Operation with Multiple 402 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 403 . 405 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 406 "Special-Purpose IP Address Registries", BCP 153, 407 RFC 6890, DOI 10.17487/RFC6890, April 2013, 408 . 410 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 411 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 412 May 2017, . 414 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 415 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 416 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 417 RFC 8415, DOI 10.17487/RFC8415, November 2018, 418 . 420 8.2. Informative References 422 [I-D.nam-mptcp-deployment-considerations] 423 Boucadair, M., Jacquenet, C., Bonaventure, O., Henderickx, 424 W., and R. Skog, "Network-Assisted MPTCP: Use Cases, 425 Deployment Scenarios and Operational Considerations", 426 draft-nam-mptcp-deployment-considerations-01 (work in 427 progress), December 2016. 429 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 430 RFC 793, DOI 10.17487/RFC0793, September 1981, 431 . 433 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 434 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 435 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 436 . 438 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 439 Profiles for DHCP Clients", RFC 7844, 440 DOI 10.17487/RFC7844, May 2016, 441 . 443 [RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP 444 Configuration on the Basis of Network Topology", RFC 7969, 445 DOI 10.17487/RFC7969, October 2016, 446 . 448 Appendix A. DHCP Server Configuration Guidelines 450 DHCP servers that support the DHCP Converter option can be configured 451 with a list of IP addresses of the Converter(s). If multiple IP 452 addresses are configured, the DHCP server MUST be explicitly 453 configured whether all or some of these addresses refer to: 455 1. the same Converter: the DHCP server returns multiple addresses in 456 the same instance of the DHCP Converter option. 458 2. distinct Converters : the DHCP server returns multiple lists of 459 Converter IP addresses to the requesting DHCP client (encoded as 460 multiple OPTION_V6_CONVERT or in the same OPTION_V4_CONVERT); 461 each list refers to a distinct Converter. 463 Precisely how DHCP servers are configured to separate lists of IP 464 addresses according to which Converter they refer to is out of scope 465 for this document. However, DHCP servers MUST NOT combine the IP 466 addresses of multiple Converters and return them to the DHCP client 467 as if they were belonging to a single Converter, and DHCP servers 468 MUST NOT separate the addresses of a single Converter and return them 469 as if they were belonging to distinct Converters. For example, if an 470 administrator configures the DHCP server by providing a Fully 471 Qualified Domain Name (FQDN) for a Converter, even if that FQDN 472 resolves to multiple addresses, the DHCP server MUST deliver them 473 within a single server address block. 475 DHCPv6 servers that implement this option and that can populate the 476 option by resolving FQDNs will need a mechanism for indicating 477 whether to query A records or only AAAA records. When a query 478 returns A records, the IP addresses in those records are returned in 479 the DHCPv6 response as IPv4-mapped IPv6 addresses. 481 Since this option requires support for IPv4-mapped IPv6 addresses, a 482 DHCPv6 server implementation will not be complete if it does not 483 query A records and represent any that are returned as IPv4-mapped 484 IPv6 addresses in DHCPv6 responses. The mechanism whereby DHCPv6 485 implementations provide this functionality is beyond the scope of 486 this document. 488 For guidelines on providing context-specific configuration 489 information (e.g., returning a regional-based configuration), and 490 information on how a DHCP server might be configured with FQDNs that 491 get resolved on demand, see [RFC7969]. 493 Authors' Addresses 495 Mohamed Boucadair 496 Orange 497 Rennes 35000 498 France 500 Email: mohamed.boucadair@orange.com 502 Christian Jacquenet 503 Orange 504 Rennes 505 France 507 Email: christian.jacquenet@orange.com 508 Tirumaleswar Reddy 509 McAfee, Inc. 510 Embassy Golf Link Business Park 511 Bangalore, Karnataka 560071 512 India 514 Email: kondtir@gmail.com