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