idnits 2.17.1 draft-ietf-homenet-naming-architecture-dhc-options-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 March 2021) is 1115 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) == Outdated reference: A later version (-27) exists of draft-ietf-homenet-front-end-naming-delegation-12 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Homenet D. Migault 3 Internet-Draft Ericsson 4 Intended status: Standards Track R. Weber 5 Expires: 11 September 2021 Akamai 6 T. Mrugalski 7 Internet Systems Consortium, Inc. 8 C. Griffiths 10 W. Cloetens 11 Deutsche Telekom 12 10 March 2021 14 DHCPv6 Options for Home Network Naming Authority 15 draft-ietf-homenet-naming-architecture-dhc-options-09 17 Abstract 19 This document defines DHCPv6 options so any agnostic Homenet Naming 20 Authority (HNA) can automatically proceed to the appropriate 21 configuration and outsource the authoritative naming service for the 22 home network. In most cases, the outsourcing mechanism is 23 transparent for the end user. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 11 September 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Payload Description . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. Registered Homenet Domain Option . . . . . . . . . . . . 5 63 4.2. Distribution Master Option . . . . . . . . . . . . . . . 6 64 4.2.1. Supported Transport . . . . . . . . . . . . . . . . . 6 65 4.3. Reverse Distribution Master Server Option . . . . . . . . 7 66 5. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7 68 5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 8 69 5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 8 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 7. Security Considerations" . . . . . . . . . . . . . . . . . . 8 72 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 9.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Appendix A. Scenarios and impact on the End User . . . . . . . . 10 77 Appendix B. Base Scenario . . . . . . . . . . . . . . . . . . . 10 78 B.1. Third Party Registered Homenet Domain . . . . . . . . . . 10 79 B.2. Third Party DNS Infrastructure . . . . . . . . . . . . . 11 80 B.3. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Terminology 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 87 "OPTIONAL" in this document are to be interpreted as described in 88 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 89 capitals, as shown here. 91 The reader is expected to be familiar with 92 [I-D.ietf-homenet-front-end-naming-delegation] and its terminology 93 section. 95 2. Introduction 97 [I-D.ietf-homenet-front-end-naming-delegation] describes how Homenet 98 Naming Authority (HNA) outsources the Public Homenet Zone to an 99 Outsourcing Infrastructure. 101 This document shows how an ISP can provision automatically the HNA 102 with an DNS Outsourcing Infrastructure (DOI). Most likely the DOI 103 will be - at least partly be - managed or provided by its ISP, but 104 other cases may envision the ISP storing some configuration so the 105 homenet becomes resilient to HNA replacement. 107 The ISP delegates the home network an IP prefix it owns as well as 108 the associated reverse zone. The ISP is well aware of the owner of 109 that prefix, and as such becomes a natural candidate for hosting the 110 Homenet Reverse Zone - that is the Reverse Distribution Master (RDM) 111 and potentially the Reverse Public Authoritative Servers. 113 In addition, the ISP often identifies the home network with a name. 114 In most cases, the name is used by the ISP for its internal network 115 management operations and is not a name the home network owner has 116 registered to. The ISP may thus leverage such infrastructure and 117 provide the homenet a specific domain name designated as per 118 [I-D.ietf-homenet-front-end-naming-delegation] a Homenet Registered 119 Domain. Similarly to the reverse zone, the ISP is well aware of who 120 owns that domain name and may become a natural candidate for hosting 121 the Homenet Zone - that is the Distribution Master (DM) and the 122 Public Authoritative Servers. 124 This document describes DHCPv6 options that enables the ISP to 125 provide the necessary parameters to the HNA, to proceed. More 126 specifically, the ISP provides the Registered Homenet Domain, 127 necessary information on the DM and the RDM so the HNA can manage and 128 upload the Public Homenet Zone and the Reverse Public Homenet Zone as 129 described in [I-D.ietf-homenet-front-end-naming-delegation]. 131 The use of DHCPv6 options makes the configuration completely 132 transparent to the end user and provides a similar level of trust as 133 the one used to provide the IP prefix. The link between the HNA and 134 the DHCPv6 server may benefit from additional security for example by 135 using [I-D.ietf-dhc-sedhcpv6]. 137 3. Protocol Overview 139 This section illustrates how a HNA receives the necessary information 140 via DHCPv6 options to outsource its authoritative naming service to 141 the DOI. For the sake of simplicity, and similarly to 142 [I-D.ietf-homenet-front-end-naming-delegation], this section assumes 143 that the HNA and the home network DHCPv6 client are collocated on the 144 CPE. Note also that this is not mandatory and specific 145 communications between the HNA and the DHCPv6 client only are needed. 146 In addition, this section assumes the responsible entity for the 147 DHCPv6 server is able to configure the DM and RDM. In our case, this 148 means a Registered Homenet Domain can be associated to the DHCP 149 client. 151 This scenario has been chosen as it is believed to be the most 152 popular scenario. This document does not ignore scenarios where the 153 DHCP Server does not have privileged relations with the DM or RDM. 154 These cases are discussed latter in Appendix A. Such scenarios do 155 not necessarily require configuration for the end user and can also 156 be zero-config. 158 The scenario considered in this section is as follows: 160 1. The HNA is willing to outsource the Public Homenet Zone or 161 Homenet Reverse Zone and configures its DHCP Client to include in 162 its Option Request Option (ORO) the Registered Homnet Domain 163 Option (OPTION_REGISTERED_DOMAIN), the Distribution Master Option 164 (OPTION_DIST_MASTER) and the Reverse Distribution Master Option 165 (OPTION_REVERSE_DIST_MASTER) option codes. 167 2. The DHCP Server responds to the HNA with the requested DHCPv6 168 options based on the identified homenet. The DHCP Client 169 transmits the information to the HNA. 171 3. The HNA is able to get authenticated by the DM and the RDM. The 172 HNA builds the Homenet Zone ( resp. the Homenet Reverse Zone) and 173 proceed as described in 174 [I-D.ietf-homenet-front-end-naming-delegation]. 176 4. Payload Description 178 This section details the payload of the DHCPv6 options. 208 4.1. Registered Homenet Domain Option 210 The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the 211 FQDN associated to the home network. 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | OPTION_REGISTERED_DOMAIN | option-len | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | | 219 / Registered Homenet Domain / 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 2: Registered Domain Option 225 * option-code (16 bits): OPTION_REGISTERED_DOMAIN, the option code 226 for the Registered Homenet Domain (TBD2). 228 * option-len (16 bits): length in octets of the option-data field as 229 described in [RFC3315]. 231 * Registered Homenet Domain (varaiable): the FQDN registered for the 232 homenet 234 4.2. Distribution Master Option 236 The Distributed Master Option (OPTION_DIST_MASTER) provides the HNA 237 to FQDN of the DM as well as the transport protocol for the 238 transaction between the HNA and the DM. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | OPTION_DIST_MASTER | option-len | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Supported Transport | | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 247 | | 248 / Distribution Master FQDN / 249 | | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 3: Distribution Master Option 254 * option-code (16 bits): OPTION_DIST_MASTER, the option code for the 255 DM Option (TBD3). 257 * option-len (16 bits): length in octets of the option-data field as 258 described in [RFC3315]. 260 * Supported Transport (16 bits): defines the supported transport by 261 the DM. Each bit represents a supported transport, and a DM MAY 262 indicate the support of multiple modes. The bit for DoT MUST be 263 set. 265 * Distribution Master FQDN (variable): the FQDN of the DM. 267 4.2.1. Supported Transport 269 The Supported Transport filed of the DHCPv6 option indicates the 270 supported transport protocol. Each bit represents a specific 271 transport mechanism. The bit sets to 1 indicates the associated 272 transport protocol is supported. The corresponding bits are assigned 273 as described in Figure 4. 275 Bit | Transport Protocol | Reference 276 ----+--------------------+----------- 277 0 | DNS over TLS | 278 1 | DNS over HTTPS | 279 2-7 | unallocated | 281 Figure 4: Supported Protocols 283 4.3. Reverse Distribution Master Server Option 285 The Reverse Distribution Master Server Option 286 (OPTION_REVERSE_DIST_MASTER) provides the HNA to FQDN of the DM as 287 well as the transport protocol for the transaction between the HNA 288 and the DM. 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | OPTION_REVERSE_DIST_MASTER | option-len | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Supported Transport | | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 297 | | 298 / Reverse Distribution Master FQDN / 299 | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Figure 5: Reverse Distribution Master Option 304 * option-code (16 bits): OPTION_REVERSE_DIST_MASTER, the option code 305 for the Reverse Distribution Master Option (TBD4). 307 * option-len (16 bits): length in octets of the option-data field as 308 described in [RFC3315]. 310 * Supported Transport (16 bits): defines the supported transport by 311 the DM. Each bit represents a supported transport, and a DM MAY 312 indicate the support of multiple modes. The bit for DoT MUST be 313 set. 315 * Reverse Distribution Master FQDN (variable): the FQDN of the RDM. 317 5. DHCP Behavior 319 5.1. DHCPv6 Server Behavior 321 Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in 322 regards to option assignment. As a convenience to the reader, we 323 mention here that the server will send option foo only if configured 324 with specific values for foo and if the client requested it. In 325 particular, when configured the DHCP Server sends the Registered 326 Homenet Domain Option, Distribution Master Option, the Reverse 327 Distribution Master Option when requested by the DHCPv6 client by 328 including necessary option codes in its ORO. 330 5.2. DHCPv6 Client Behavior 332 The DHCPv6 client sends a ORO with the necessary option codes: 333 Registered Homenet Domain Option, Distribution Master Option, the 334 Reverse Distribution Master Option. 336 Upon receiving a DHCP option described in this document in the Reply 337 message, the HNA SHOULD proceed as described in 338 [I-D.ietf-homenet-front-end-naming-delegation]. 340 5.3. DHCPv6 Relay Agent Behavior 342 There are no additional requirements for the DHCP Relay agents. 344 6. IANA Considerations 346 The DHCP options detailed in this document are: * 347 OPTION_REGISTERED_DOMAIN: TBD1 * OPTION_DIST_MASTER: TBD2 * 348 OPTION_REVERSE_DIST_MASTER: TBD3 350 The document also requests a Supported Transport Registry: 352 Bit | Transport Protocol | Reference 353 ----+--------------------+----------- 354 0 | DNS over TLS | 355 1 | DNS over HTTPS | 356 2-7 | unallocated | 358 7. Security Considerations" 360 8. Acknowledgments 362 We would like to thank Marcin Siodelski and Bernie Volz for their 363 comments on the design of the DHCPv6 options. We would also like to 364 thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their 365 remarks on the architecture design. The designed solution has been 366 largely been inspired by Mark Andrews's document 367 [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We 368 also thank Ray Hunter for its reviews, its comments and for 369 suggesting an appropriated terminology. 371 9. References 373 9.1. Normative References 375 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 376 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 377 . 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, 381 DOI 10.17487/RFC2119, March 1997, 382 . 384 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 385 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 386 . 388 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 389 C., and M. Carney, "Dynamic Host Configuration Protocol 390 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 391 2003, . 393 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 394 Rose, "Resource Records for the DNS Security Extensions", 395 RFC 4034, DOI 10.17487/RFC4034, March 2005, 396 . 398 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 399 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 400 . 402 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 403 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 404 May 2017, . 406 9.2. Informative References 408 [I-D.andrews-dnsop-pd-reverse] 409 Andrews, M., "Automated Delegation of IP6.ARPA reverse 410 zones with Prefix Delegation", Work in Progress, Internet- 411 Draft, draft-andrews-dnsop-pd-reverse-02, 4 November 2013, 412 . 415 [I-D.ietf-dhc-sedhcpv6] 416 Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. 417 Zhang, "Secure DHCPv6", Work in Progress, Internet-Draft, 418 draft-ietf-dhc-sedhcpv6-21, 21 February 2017, 419 . 422 [I-D.ietf-homenet-front-end-naming-delegation] 423 Migault, D., Weber, R., Richardson, M., Hunter, R., 424 Griffiths, C., and W. Cloetens, "Simple Provisioning of 425 Public Names for Residential Networks", Work in Progress, 426 Internet-Draft, draft-ietf-homenet-front-end-naming- 427 delegation-12, 2 November 2020, . 431 [I-D.sury-dnsext-cname-dname] 432 Sury, O., "CNAME+DNAME Name Redirection", Work in 433 Progress, Internet-Draft, draft-sury-dnsext-cname-dname- 434 00, 15 April 2010, . 437 Appendix A. Scenarios and impact on the End User 439 This section details various scenarios and discuss their impact on 440 the end user. This section is not normative and limits the 441 description of a limited scope of scenarios that are assumed to be 442 representative. Many other scenarios may be derived from these. 444 Appendix B. Base Scenario 446 The base scenario is the one described in Section 3 in which an ISP 447 manages the DHCP Server, the DM and RDM. 449 The end user subscribes to the ISP (foo), and at subscription time 450 registers for example.foo as its Registered Homenet Domain 451 example.foo. 453 In this scenario, the DHCP Server, DM and RDM are managed by the ISP 454 so the DHCP Server and as such can provide authentication credentials 455 of the HNA to enable secure authenticated transaction with the DM and 456 the Reverse DM. 458 The main advantage of this scenario is that the naming architecture 459 is configured automatically and transparently for the end user. The 460 drawbacks are that the end user uses a Registered Homenet Domain 461 managed by the ISP and that it relies on the ISP naming 462 infrastructure. 464 B.1. Third Party Registered Homenet Domain 466 This section considers the case when the end user wants its home 467 network to use example.com not managed by her ISP (foo) as a 468 Registered Homenet Domain. This section still consider the ISP 469 manages the home network and still provides example.foo as a 470 Registered Homenet Domain. 472 When the end user buys the domain name example.com, it may request to 473 redirect the name example.com to example.foo using static redirection 474 with CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME 475 [I-D.sury-dnsext-cname-dname]. 477 This configuration is performed once when the domain name example.com 478 is registered. The only information the end user needs to know is 479 the domain name assigned by the ISP. Once this configuration is done 480 no additional configuration is needed anymore. More specifically, 481 the HNA may be changed, the zone can be updated as in Appendix B 482 without any additional configuration from the end user. 484 The main advantage of this scenario is that the end user benefits 485 from the Zero Configuration of the Base Scenario The drawback of this 486 scenario may be that the end user still rely on the ISP naming 487 infrastructure. Note that the only case this may be inconvenient is 488 when the DNS Servers provided by the ISPs results in high 489 latency.Appendix B. Then, the end user is able to register for its 490 home network an unlimited number of domain names provided by an 491 unlimited number of different third party providers. 493 B.2. Third Party DNS Infrastructure 495 This scenario considers that the end user uses example.com as a 496 Registered Homenet Domain, and does not want to rely on the 497 authoritative servers provided by the ISP. 499 In this section we limit the outsourcing to the DM and Public 500 Authoritative Server(s) to a third party. The Reverse Public 501 Authoritative Server(s) and the RDM remain managed by the ISP as the 502 IP prefix is managed by the ISP. 504 Outsourcing to a third party DM can be performed in the following 505 ways: 507 1. Updating the DHCP Server Information. One can imagine a GUI 508 interface that enables the end user to modify its profile 509 parameters. Again, this configuration update is done once-for- 510 ever. 512 2. Upload the configuration of the DM to the HNA. In some cases, 513 the provider of the CPE hosting the HNA may be the registrar and 514 provide the CPE already configured. In other cases, the CPE may 515 request the end user to log into the registrar to validate the 516 ownership of the Registered Homenet Domain and agree on the 517 necessary credentials to secure the communication between the HNA 518 and the DM. As described in 519 [I-D.ietf-homenet-front-end-naming-delegation], such settings 520 could be performed in an almost automatic way as to limit the 521 necessary interactions with the end user. 523 B.3. Multiple ISPs 525 This scenario considers a HNA connected to multiple ISPs. 527 Suppose the HNA has been configured each of its interfaces 528 independently with each ISPS as described in Appendix B. Each ISP 529 provides a different Registered Homenet Domain. 531 The protocol and DHCPv6 options described in this document are fully 532 compatible with a HNA connected to multiple ISPs with multiple 533 Registered Homenet Domains. However, the HNA should be able to 534 handle different Registered Homenet Domains. This is an 535 implementation issue which is outside the scope of the current 536 document. 538 If a HNA is not able to handle multiple Registered Homenet Domains, 539 the HNA may remain connected to multiple ISP with a single Registered 540 Homenet Domain. In this case, one entity is chosen to host the 541 Registered Homenet Domain. This entity may be one of the ISP or a 542 third party. Note that having multiple ISPs can be motivated for 543 bandwidth aggregation, or connectivity fail-over. In the case of 544 connectivity fail-over, the fail-over concerns the access network and 545 a failure of the access network may not impact the core network where 546 the DM Server and Public Authoritative Primaries are hosted. In that 547 sense, choosing one of the ISP even in a scenario of multiple ISPs 548 may make sense. However, for sake of simplicity, this scenario 549 assumes that a third party has been chosen to host the Registered 550 Homenet Domain. Configuration is performed as described in 551 Appendix B.1 and Appendix B.2. 553 With the configuration described in Appendix B.1, the HNA is expect 554 to be able to handle multiple Homenet Registered Domain, as the third 555 party redirect to one of the ISPs Servers. With the configuration 556 described in Appendix B.2, DNS zone are hosted and maintained by the 557 third party. A single DNS(SEC) Homenet Zone is built and maintained 558 by the HNA. This latter configuration is likely to match most HNA 559 implementations. 561 The protocol and DHCPv6 options described in this document are fully 562 compatible with a HNA connected to multiple ISPs. To configure or 563 not and how to configure the HNA depends on the HNA facilities. 564 Appendix B and Appendix B.1 require the HNA to handle multiple 565 Registered Homenet Domain, whereas Appendix B.2 does not have such 566 requirement. 568 Authors' Addresses 570 Daniel Migault 571 Ericsson 572 8275 Trans Canada Route 573 Saint Laurent, QC 4S 0B6 574 Canada 576 Email: daniel.migault@ericsson.com 578 Ralf Weber 579 Akamai 581 Email: ralf.weber@akamai.com 583 Tomek Mrugalski 584 Internet Systems Consortium, Inc. 585 950 Charter Street 586 Redwood City, 94063 587 United States of America 589 Email: tomasz.mrugalski@gmail.com 591 Chris Griffiths 593 Email: cgriffiths@gmail.com 595 Wouter Cloetens 596 Deutsche Telekom 598 Email: wouter.cloetens@external.telekom.de