idnits 2.17.1 draft-boucadair-mptcp-dhc-07.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 -- The document date (April 18, 2017) is 2563 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 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: 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 M. Boucadair 3 Internet-Draft C. Jacquenet 4 Intended status: Standards Track Orange 5 Expires: October 20, 2017 T. Reddy 6 Cisco 7 April 18, 2017 9 DHCP Options for Network-Assisted Multipath TCP (MPTCP) 10 draft-boucadair-mptcp-dhc-07 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 MPTCP 17 Conversion Point (MCP). Network-assisted MPTCP deployment models are 18 designed to facilitate the adoption of MPTCP for the establishment of 19 multi-path communications without making any assumption about the 20 support of MPTCP by the communicating peers. MCPs located in the 21 network are responsible for establishing multi-path communications on 22 behalf of endpoints, thereby taking advantage of MPTCP capabilities 23 to 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 MPTCP Conversion Point(s) is explicitly configured on 30 connected hosts. This document specifies DHCP (IPv4 and IPv6) 31 options to configure hosts with Multipath TCP (MPTCP) 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 http://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 October 20, 2017. 56 Copyright Notice 58 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. DHCPv6 MPTCP Option . . . . . . . . . . . . . . . . . . . . . 5 76 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 6 78 4. DHCPv4 MPTCP Option . . . . . . . . . . . . . . . . . . . . . 7 79 4.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 4.2. DHCPv4 Client Behavior . . . . . . . . . . . . . . . . . 8 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 82 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 7.1. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . 9 85 7.2. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . . 9 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 89 9.2. Informative References . . . . . . . . . . . . . . . . . 11 90 Appendix A. DHCP Server Configuration Guidelines . . . . . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 93 1. Introduction 95 One of the promising deployment scenarios for Multipath TCP (MPTCP, 96 [RFC6824]) is to enable a Customer Premises Equipment (CPE) that is 97 connected to multiple networks (e.g., DSL, LTE, WLAN) to optimize the 98 usage of such resources. This deployment scenario relies on MPTCP 99 Conversion Points (MCPs) located on both the CPE and network sides 100 (Figure 1). The latter plays the role of traffic concentrator. An 101 MCP terminates the MPTCP sessions established from a CPE, before 102 redirecting traffic into a legacy TCP session. Further Network- 103 Assisted MPTCP deployment and operational considerations are 104 discussed in [I-D.nam-mptcp-deployment-considerations]. 106 +------------+ _--------_ +----------------+ 107 | | ( LTE ) | | 108 | CPE +=======+ +===+ Backbone | 109 | (MCP) | (_ _) | Network | 110 | | (_______) |+--------------+| 111 | | IP Network #1 || Concentrator ||------> Internet 112 | | || (MCP) || 113 | | |+--------------+| 114 | | IP Network #2 | | 115 | | _--------_ | | 116 | | ( DSL ) | | 117 | +=======+ +==+ | 118 | | (_ _) | | 119 +-----+------+ (_______) +----------------+ 120 | 121 ---- LAN ---- 122 | 123 end-nodes 125 Figure 1: "Network-Assisted" MPTCP Design 127 This document focuses on the explicit mode that consists in 128 configuring explicitly the reachability information of the MCP on a 129 host. Concretely, the explicit mode has several advantages, e.g.,: 131 o It does not impose any specific constraint on the location of the 132 MCP. For example, the MCP can be located in any access network, 133 located upstream in the core network, or located in a data canter 134 facility. 136 o Tasks required for activating the explicit mode are minimal. In 137 particular, this mode does not require any specific routing and/or 138 forwarding policies for handling outbound packets other than 139 ensuring that an MCP is reachable from a CPE, and vice versa 140 (which is straightforward IP routing policy operation). 142 o The engineering effort to change the location of an MCP for some 143 reason (e.g., to better accommodate dimensioning constraints, to 144 move the MCP to a data canter, to enable additional MCP instances 145 closer to the customer premises, etc.) is minimal 147 o An operator can easily enforce strategies for differentiating the 148 treatment of MPTCP connections that are directly initiated by an 149 MPTCP-enabled host connected to an MCP if the explicit mode is 150 enabled. Typically, an operator may decide to offload MPTCP 151 connections originated by an MPTCP-enabled terminal from being 152 forwarded through a specific MCP, or decide to relay them via a 153 specific MCP. Such policies can be instructed to the MCP. 154 Implementing such differentiating behavior if the implicit mode is 155 in use may be complex to achieve. 157 o Multiple MCPs can be supported to service the same CPE, e.g., an 158 MCP can be enabled for internal services (to optimize the delivery 159 of some operator-specific services) while another MCP may be 160 solicited for external services (e.g., access to the Internet). 161 The explicit mode allows the deployment of such scenario owing to 162 the provisioning of an MCP selection policy table that relies upon 163 the destination IP prefixes to select the MCP to involve for an 164 ongoing MPTCP connection, for instance. 166 o Because the MCP's reachability information is explicitly 167 configured on the CPE, means to guarantee successful inbound 168 connections can be enabled in the CPE to dynamically discover the 169 external IP address that has been assigned for communicating with 170 remote servers, instruct the MCP to maintain active bindings so 171 that incoming packets can be successfully redirected towards the 172 appropriate CPE, etc. 174 o Troubleshooting and root cause analysis may be facilitated in the 175 explicit mode since faulty key nodes that may have caused a 176 service degradation are known. Because of the loose adherence to 177 the traffic forwarding and routing polices, troubleshooting a 178 service degradation that is specific to multi-access serviced 179 customers should first investigate the behavior of the involved 180 MCP. 182 This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options 183 that can be used to configure hosts with MCP IP addresses. 185 This specification assumes an MCP is reachable through one or 186 multiple IP addresses. As such, a list of IP addresses can be 187 returned in the DHCP MPTCP option. Also, it assumes the various 188 network attachments provided to an MPTCP-enabled CPE are managed by 189 the same administrative entity. 191 2. Terminology 193 This document makes use of the following terms: 195 o Multipath Conversion Point (MCP): a function that terminates a 196 transport flow and relays all data received over it over another 197 transport flow. This element is located upstream in the network. 198 One or multiple MCPs can be deployed in the network side to assist 199 MPTCP-enabled devices to establish MPTCP connections via available 200 network attachments. 202 On the uplink path, the MCP terminates the MPTCP connections 203 [RFC6824] received from its customer-facing interfaces and 204 transforms these connections into legacy TCP connections [RFC0793] 205 towards upstream servers. 207 On the downlink path, the MCP turns the legacy server's TCP 208 connection into MPTCP connections towards its customer-facing 209 interfaces. 210 o DHCP refers to both DHCPv4 [RFC2131] and DHCPv6 [RFC3315]. 211 o DHCP client denotes a node that initiates requests to obtain 212 configuration parameters from one or more DHCP servers. 213 o DHCP server refers to a node that responds to requests from DHCP 214 clients. 216 3. DHCPv6 MPTCP Option 218 3.1. Format 220 The DHCPv6 MPTCP option can be used to configure a list of IPv6 221 addresses of an MCP. 223 The format of this option is shown in Figure 2. As a reminder, this 224 format follows the guidelines for creating new DHCPv6 options 225 (Section 5.1 of [RFC7227]). 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | OPTION_V6_MPTCP | Option-length | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | | 232 | ipv6-address | 233 | | 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | | 237 | ipv6-address | 238 | | 239 | | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | ... | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 2: DHCPv6 MPTCP option 246 The fields of the option shown in Figure 2 are as follows: 248 o Option-code: OPTION_V6_MPTCP (TBA, see Section 7.1) 249 o Option-length: Length of the 'MCP IP Address(es)' field in octets. 250 MUST be a multiple of 16. 251 o MCP IPv6 Addresses: Includes one or more IPv6 addresses [RFC4291] 252 of the MCP to be used by the MPTCP client. 254 Note, IPv4-mapped IPv6 addresses (Section 2.5.5.2 of [RFC4291]) 255 are allowed to be included in this option. 257 To return more than one MCPs to the requesting DHCPv6 client, the 258 DHCPv6 server returns multiple instances of OPTION_V6_MPTCP. Some 259 guidelines for DHCP servers are elaborated in Appendix A. 261 3.2. DHCPv6 Client Behavior 263 Clients MAY request option OPTION_V6_MPTCP, as defined in [RFC3315], 264 Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7. As a 265 convenience to the reader, we mention here that the client includes 266 requested option codes in the Option Request Option. 268 The DHCPv6 client MUST be prepared to receive multiple instances of 269 OPTION_V6_MPTCP; each instance is to be treated separately as it 270 corresponds to a given MCP: there are as many MCPs as instances of 271 the OPTION_V6_MPTCP option. 273 If an IPv4-mapped IPv6 address is received in OPTION_V6_MPTCP, it 274 indicates that the MCP has the corresponding IPv4 address. 276 The DHCPv6 client MUST silently discard multicast and host loopback 277 addresses [RFC6890] conveyed in OPTION_V6_MPTCP. 279 4. DHCPv4 MPTCP Option 281 4.1. Format 283 The DHCPv4 MPTCP option can be used to configure a list of IPv4 284 addresses of an MCP. The format of this option is illustrated in 285 Figure 3. 287 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Code | Length | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | List-Length | List of | 292 +-+-+-+-+-+-+-+-+ MPTCP | 293 / MCP IPv4 Addresses / 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 295 | List-Length | List of | | 296 +-+-+-+-+-+-+-+-+ MPTCP | | 297 / MCP IPv4 Addresses / | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 299 . ... . Optional 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 301 | List-Length | List of | | 302 +-+-+-+-+-+-+-+-+ MPTCP | | 303 / MCP IPv4 Addresses / | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --- 306 Figure 3: DHCPv4 MPTCP option 308 The fields of the option shown in Figure 3 are as follows: 310 o Code: OPTION_V4_MPTCP (TBA, see Section 7.2); 311 o Length: Length of all included data in octets. The minimum length 312 is 5. 313 o List-Length: Length of the "List of MCP IPv4 Addresses" field in 314 octets; MUST be a multiple of 4. 315 o List of MCP IPv4 Addresses: Contains one or more IPv4 addresses of 316 the MCP to be used by the MPTCP client. The format of this field 317 is shown in Figure 4. 318 o OPTION_V4_MPTCP can include multiple lists of MCP IPv4 addresses; 319 each list is treated separately as it corresponds to a given MCP. 321 When several lists of MCP IPv4 addresses are to be included, 322 "List-Length" and "MCP IPv4 Addresses" fields are repeated. 324 0 8 16 24 32 40 48 325 +-----+-----+-----+-----+-----+-----+-- 326 | a1 | a2 | a3 | a4 | a1 | a2 | ... 327 +-----+-----+-----+-----+-----+-----+-- 328 IPv4 Address 1 IPv4 Address 2 ... 330 This format assumes that an IPv4 address is encoded as a1.a2.a3.a4. 332 Figure 4: Format of the List of MCP IPv4 Addresses 334 OPTION_V4_MPTCP is a concatenation-requiring option. As such, the 335 mechanism specified in [RFC3396] MUST be used if OPTION_V4_MPTCP 336 exceeds the maximum DHCPv4 option size of 255 octets. 338 Some guidelines for DHCP servers are elaborated in Appendix A. 340 4.2. DHCPv4 Client Behavior 342 To discover one or more MCPs, the DHCPv4 client MUST include 343 OPTION_V4_MPTCP in a Parameter Request List Option [RFC2132]. 345 The DHCPv4 client MUST be prepared to receive multiple lists of MCP 346 IPv4 addresses in the same OPTION_V4_MPTCP; each list is to be 347 treated as a separate MCP instance. 349 The DHCPv4 client MUST silently discard multicast and host loopback 350 addresses [RFC6890] conveyed in OPTION_V4_MPTCP. 352 5. Security Considerations 354 The security considerations in [RFC2131] and [RFC3315] are to be 355 considered. 357 MPTCP-related security considerations are discussed in [RFC6824]. 359 Means to protect the MCP against Denial-of-Service (DoS) attacks must 360 be enabled. Such means include the enforcement of ingress filtering 361 policies at the boundaries of the network. In order to prevent 362 exhausting the resources of the MCP by creating an aggressive number 363 of simultaneous subflows for each MPTCP connection, the administrator 364 should limit the number of allowed subflows per host for a given 365 connection. 367 Attacks outside the domain can be prevented if ingress filtering is 368 enforced. Nevertheless, attacks from within the network between a 369 host and an MCP instance are yet another actual threat. Means to 370 ensure that illegitimate nodes cannot connect to a network should be 371 implemented. 373 Traffic theft is also a risk if an illegitimate MCP is inserted in 374 the path. Indeed, inserting an illegitimate MCP in the forwarding 375 path allows to intercept traffic and can therefore provide access to 376 sensitive data issued by or destined to a host. To mitigate this 377 threat, secure means to discover an MCP (for non-transparent modes) 378 should be enabled. 380 6. Privacy Considerations 382 Generic privacy-related considerations are discussed in [RFC7844]. 384 The MCP may have access to privacy-related information (e.g., 385 International Mobile Subscriber Identity (IMSI), link identifier, 386 subscriber credentials, etc.). The MCP must not leak such sensitive 387 information outside an administrative domain. 389 7. IANA Considerations 391 7.1. DHCPv6 Option 393 IANA is requested to assign the following new DHCPv6 Option Code in 394 the registry maintained in http://www.iana.org/assignments/ 395 dhcpv6-parameters: 397 Option Name Value 398 --------------- ----- 399 OPTION_V6_MPTCP TBA 401 7.2. DHCPv4 Option 403 IANA is requested to assign the following new DHCPv4 Option Code in 404 the registry maintained in http://www.iana.org/assignments/bootp- 405 dhcp-parameters/: 407 Option Name Value Data length Meaning 408 --------------- ----- ------------- --------------------------------- 409 OPTION_V4_MPTCP TBA Variable; the Includes one or multiple lists of 410 minimum MCP IP addresses; each list is 411 length is 5. treated as a separate MCP. 413 8. Acknowledgements 415 Many thanks to Olivier Bonaventure for the feedback on this document. 416 Olivier suggested to define the option as a name but that design 417 approach was debated several times within the dhc wg. 419 Thanks to Dan Seibel, Bernie Volz, Niall O'Reilly, Simon Hobson, and 420 Ted Lemon for the feedback on the dhc wg mailing list. 422 9. References 424 9.1. Normative References 426 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 427 Requirement Levels", BCP 14, RFC 2119, 428 DOI 10.17487/RFC2119, March 1997, 429 . 431 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 432 RFC 2131, DOI 10.17487/RFC2131, March 1997, 433 . 435 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 436 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 437 . 439 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 440 C., and M. Carney, "Dynamic Host Configuration Protocol 441 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 442 2003, . 444 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 445 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 446 DOI 10.17487/RFC3396, November 2002, 447 . 449 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 450 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 451 2006, . 453 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 454 "TCP Extensions for Multipath Operation with Multiple 455 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 456 . 458 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, 459 "Special-Purpose IP Address Registries", BCP 153, 460 RFC 6890, DOI 10.17487/RFC6890, April 2013, 461 . 463 9.2. Informative References 465 [I-D.nam-mptcp-deployment-considerations] 466 Boucadair, M., Jacquenet, C., Bonaventure, O., Henderickx, 467 W., and R. Skog, "Network-Assisted MPTCP: Use Cases, 468 Deployment Scenarios and Operational Considerations", 469 draft-nam-mptcp-deployment-considerations-01 (work in 470 progress), December 2016. 472 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 473 RFC 793, DOI 10.17487/RFC0793, September 1981, 474 . 476 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 477 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 478 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 479 . 481 [RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity 482 Profiles for DHCP Clients", RFC 7844, 483 DOI 10.17487/RFC7844, May 2016, 484 . 486 [RFC7969] Lemon, T. and T. Mrugalski, "Customizing DHCP 487 Configuration on the Basis of Network Topology", RFC 7969, 488 DOI 10.17487/RFC7969, October 2016, 489 . 491 Appendix A. DHCP Server Configuration Guidelines 493 DHCP servers that support the DHCP MCP option can be configured with 494 a list of IP addresses of the MCP(s). If multiple IP addresses are 495 configured, the DHCP server MUST be explicitly configured whether all 496 or some of these addresses refer to: 498 1. the same MCP: the DHCP server returns multiple addresses in the 499 same instance of the DHCP MCP option. 501 2. distinct MCPs : the DHCP server returns multiple lists of MCP IP 502 addresses to the requesting DHCP client (encoded as multiple 503 OPTION_V6_MPTCP or in the same OPTION_V4_MPTCP); each list refers 504 to a distinct MCP. 506 Precisely how DHCP servers are configured to separate lists of IP 507 addresses according to which MCP they refer to is out of scope for 508 this document. However, DHCP servers MUST NOT combine the IP 509 addresses of multiple MCPs and return them to the DHCP client as if 510 they were belonging to a single MCP, and DHCP servers MUST NOT 511 separate the addresses of a single MCP and return them as if they 512 were belonging to distinct MCPs. For example, if an administrator 513 configures the DHCP server by providing a Fully Qualified Domain Name 514 (FQDN) for an MCP, even if that FQDN resolves to multiple addresses, 515 the DHCP server MUST deliver them within a single server address 516 block. 518 DHCPv6 servers that implement this option and that can populate the 519 option by resolving FQDNs will need a mechanism for indicating 520 whether to query A records or only AAAA records. When a query 521 returns A records, the IP addresses in those records are returned in 522 the DHCPv6 response as IPv4-mapped IPv6 addresses. 524 Since this option requires support for IPv4-mapped IPv6 addresses, a 525 DHCPv6 server implementation will not be complete if it does not 526 query A records and represent any that are returned as IPv4-mapped 527 IPv6 addresses in DHCPv6 responses. The mechanism whereby DHCPv6 528 implementations provide this functionality is beyond the scope of 529 this document. 531 For guidelines on providing context-specific configuration 532 information (e.g., returning a regional-based configuration), and 533 information on how a DHCP server might be configured with FQDNs that 534 get resolved on demand, see [RFC7969]. 536 Authors' Addresses 538 Mohamed Boucadair 539 Orange 540 Rennes 35000 541 France 543 Email: mohamed.boucadair@orange.com 545 Christian Jacquenet 546 Orange 547 Rennes 548 France 550 Email: christian.jacquenet@orange.com 551 Tirumaleswar Reddy 552 Cisco Systems, Inc. 553 Cessna Business Park, Varthur Hobli 554 Sarjapur Marathalli Outer Ring Road 555 Bangalore, Karnataka 560103 556 India 558 Email: tireddy@cisco.com