idnits 2.17.1 draft-ietf-homenet-naming-architecture-dhc-options-12.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 (April 28, 2021) is 1094 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) == Outdated reference: A later version (-27) exists of draft-ietf-homenet-front-end-naming-delegation-13 Summary: 0 errors (**), 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: October 30, 2021 Akamai 6 T. Mrugalski 7 Internet Systems Consortium, Inc. 8 April 28, 2021 10 DHCPv6 Options for Home Network Naming Authority 11 draft-ietf-homenet-naming-architecture-dhc-options-12 13 Abstract 15 This document defines DHCPv6 options so an agnostic Homenet Naming 16 Authority (HNA) can automatically proceed to the appropriate 17 configuration and outsource the authoritative naming service for the 18 home network. In most cases, the outsourcing mechanism is 19 transparent for the end user. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 30, 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Payload Description . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Registered Homenet Domain Option . . . . . . . . . . . . 4 60 4.2. Distribution Master Option . . . . . . . . . . . . . . . 5 61 4.2.1. Supported Transport . . . . . . . . . . . . . . . . . 6 62 4.3. Reverse Distribution Master Server Option . . . . . . . . 6 63 5. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 64 5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7 65 5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 7 66 5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 7 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 70 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 10.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Appendix A. Scenarios and impact on the End User . . . . . . . . 11 75 Appendix B. Base Scenario . . . . . . . . . . . . . . . . . . . 11 76 B.1. Third Party Registered Homenet Domain . . . . . . . . . . 11 77 B.2. Third Party DNS Infrastructure . . . . . . . . . . . . . 12 78 B.3. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 85 "OPTIONAL" in this document are to be interpreted as described in 86 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 87 capitals, as shown here. 89 The reader is expected to be familiar with 90 [I-D.ietf-homenet-front-end-naming-delegation] and its terminology 91 section. 93 2. Introduction 95 [I-D.ietf-homenet-front-end-naming-delegation] specifies how an 96 entity designated as the Homenet Naming Authority (HNA) outsources a 97 Public Homenet Zone to an Outsourcing DNS Infrastructure (DOI). 99 This document shows how an ISP can provision automatically the HNA 100 with a specific DOI. Most likely the DOI will be - at least partly 101 be - managed or provided by its ISP, but other cases may envision the 102 ISP storing some configuration so the homenet becomes resilient to 103 HNA replacement. 105 The ISP delegates the home network an IP prefix it owns as well as 106 the associated reverse zone. The ISP is well aware of the owner of 107 that prefix, and as such becomes a natural candidate for hosting the 108 Homenet Reverse Zone - that is the Reverse Distribution Master (RDM) 109 and potentially the Reverse Public Authoritative Servers. 111 In addition, the ISP often identifies the home network with a name. 112 In most cases, the name is used by the ISP for its internal network 113 management operations and is not a name the home network owner has 114 registered to. The ISP may thus leverage such infrastructure and 115 provide the homenet a specific domain name designated as per 116 [I-D.ietf-homenet-front-end-naming-delegation] a Homenet Registered 117 Domain. Similarly to the reverse zone, the ISP is well aware of who 118 owns that domain name and may become a natural candidate for hosting 119 the Homenet Zone - that is the Distribution Master (DM) and the 120 Public Authoritative Servers. 122 This document describes DHCPv6 options that enables the ISP to 123 provide the necessary parameters to the HNA, to proceed. More 124 specifically, the ISP provides the Registered Homenet Domain, 125 necessary information on the DM and the RDM so the HNA can manage and 126 upload the Public Homenet Zone and the Reverse Public Homenet Zone as 127 described in [I-D.ietf-homenet-front-end-naming-delegation]. 129 The use of DHCPv6 options makes the configuration completely 130 transparent to the end user and provides a similar level of trust as 131 the one used to provide the IP prefix. 133 3. Protocol Overview 135 This section illustrates how a HNA receives the necessary information 136 via DHCPv6 options to outsource its authoritative naming service to 137 the DOI. For the sake of simplicity, and similarly to 138 [I-D.ietf-homenet-front-end-naming-delegation], this section assumes 139 that the HNA and the home network DHCPv6 client are collocated on the 140 CPE. Note also that this is not mandatory and specific 141 communications between the HNA and the DHCPv6 client only are needed. 142 In addition, this section assumes the responsible entity for the 143 DHCPv6 server is able to configure the DM and RDM. In our case, this 144 means a Registered Homenet Domain can be associated to the DHCP 145 client. 147 This scenario has been chosen as it is believed to be the most 148 popular scenario. This document does not ignore scenarios where the 149 DHCP Server does not have privileged relations with the DM or RDM. 150 These cases are discussed latter in Appendix A. Such scenarios do 151 not necessarily require configuration for the end user and can also 152 be zero-config. 154 The scenario considered in this section is as follows: 156 1. The HNA is willing to outsource the Public Homenet Zone or 157 Homenet Reverse Zone and configures its DHCP Client to include in 158 its Option Request Option (ORO) the Registered Homenet Domain 159 Option (OPTION_REGISTERED_DOMAIN), the Distribution Master Option 160 (OPTION_DIST_MASTER) and the Reverse Distribution Master Option 161 (OPTION_REVERSE_DIST_MASTER) option codes. 163 2. The DHCP Server responds to the HNA with the requested DHCPv6 164 options based on the identified homenet. The DHCP Client 165 transmits the information to the HNA. 167 3. The HNA is able to get authenticated by the DM and the RDM. The 168 HNA builds the Homenet Zone ( resp. the Homenet Reverse Zone) and 169 proceed as described in 170 [I-D.ietf-homenet-front-end-naming-delegation]. The DHCPv6 171 options provide the necessary and non optional parameters 172 described in section 14 of 173 [I-D.ietf-homenet-front-end-naming-delegation]. The HNA MAY set 174 complement the configurations with additional parameters. 175 Section 14 of [I-D.ietf-homenet-front-end-naming-delegation] 176 describes such parameters that MAY take a default value. 178 4. Payload Description 180 This section details the payload of the DHCPv6 options. 182 4.1. Registered Homenet Domain Option 184 The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the 185 FQDN associated to the home network. 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | OPTION_REGISTERED_DOMAIN | option-len | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | | 193 / Registered Homenet Domain / 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 1: Registered Domain Option 199 o option-code (16 bits): OPTION_REGISTERED_DOMAIN, the option code 200 for the Registered Homenet Domain (TBD2). 202 o option-len (16 bits): length in octets of the option-data field as 203 described in [RFC8415]. 205 o Registered Homenet Domain (variable): the FQDN registered for the 206 homenet encoded as described in section 10 of [RFC8415]. 208 4.2. Distribution Master Option 210 The Distributed Master Option (OPTION_DIST_MASTER) provides the HNA 211 to FQDN of the DM as well as the transport protocol for the 212 transaction between the HNA and the DM. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | OPTION_DIST_MASTER | option-len | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Supported Transport | | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 221 | | 222 / Distribution Master FQDN / 223 | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 2: Distribution Master Option 228 o option-code (16 bits): OPTION_DIST_MASTER, the option code for the 229 DM Option (TBD3). 231 o option-len (16 bits): length in octets of the option-data field as 232 described in [RFC8415]. 234 o Supported Transport (16 bits): defines the supported transport by 235 the DM. Each bit represents a supported transport, and a DM MAY 236 indicate the support of multiple modes. The bit for DNS over TLS 237 [RFC7858] MUST be set. 239 o Distribution Master FQDN (variable): the FQDN of the DM encoded as 240 described in section 10 of [RFC8415]. 242 4.2.1. Supported Transport 244 The Supported Transport filed of the DHCPv6 option indicates the 245 supported transport protocol. Each bit represents a specific 246 transport mechanism. The bit sets to 1 indicates the associated 247 transport protocol is supported. The corresponding bits are assigned 248 as described in Figure 3. 250 Bit | Transport Protocol | Reference 251 ----+--------------------+----------- 252 0 | DNS over TLS | This-RFC 253 1-15| unallocated | 255 Figure 3: Supported Transport 257 o DNS over TLS: indicates the support of DNS over TLS as described 258 in [RFC7858]. 260 4.3. Reverse Distribution Master Server Option 262 The Reverse Distribution Master Server Option 263 (OPTION_REVERSE_DIST_MASTER) provides the HNA to FQDN of the DM as 264 well as the transport protocol for the transaction between the HNA 265 and the DM. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | OPTION_REVERSE_DIST_MASTER | option-len | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Supported Transport | | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 274 | | 275 / Reverse Distribution Master FQDN / 276 | | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 4: Reverse Distribution Master Option 281 o option-code (16 bits): OPTION_REVERSE_DIST_MASTER, the option code 282 for the Reverse Distribution Master Option (TBD4). 284 o option-len (16 bits): length in octets of the option-data field as 285 described in [RFC8415]. 287 o Supported Transport (16 bits): defines the supported transport by 288 the DM. Each bit represents a supported transport, and a DM MAY 289 indicate the support of multiple modes. The bit for DoT MUST be 290 set. 292 o Reverse Distribution Master FQDN (variable): the FQDN of the RDM 293 encoded as described in section 10 of [RFC8415]. 295 5. DHCP Behavior 297 5.1. DHCPv6 Server Behavior 299 Sections 17.2.2 and 18.2 of [RFC8415] govern server operation in 300 regards to option assignment. As a convenience to the reader, we 301 mention here that the server will send option foo only if configured 302 with specific values for foo and if the client requested it. In 303 particular, when configured the DHCP Server sends the Registered 304 Homenet Domain Option, Distribution Master Option, the Reverse 305 Distribution Master Option when requested by the DHCPv6 client by 306 including necessary option codes in its ORO. 308 5.2. DHCPv6 Client Behavior 310 The DHCPv6 client sends a ORO with the necessary option codes: 311 Registered Homenet Domain Option, Distribution Master Option, the 312 Reverse Distribution Master Option. 314 Upon receiving a DHCP option described in this document in the Reply 315 message, the HNA SHOULD proceed as described in 316 [I-D.ietf-homenet-front-end-naming-delegation]. 318 5.3. DHCPv6 Relay Agent Behavior 320 There are no additional requirements for the DHCP Relay agents. 322 6. IANA Considerations 324 IANA is requested to assign the following new DHCPv6 Option Codes in 325 the registry maintained in: https://www.iana.org/assignments/dhcpv6- 326 parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2. 328 Value Description Client ORO Singleton Option 329 TBD1 OPTION_REGISTERED_DOMAIN Yes Yes 330 TBD2 OPTION_DIST_MASTER Yes Yes 331 TBD3 OPTION_REVERSE_DIST_MASTER Yes Yes 333 IANA is requested to maintain a new number space of Supported 334 Transport parameter in the Distributed Master Option 335 (OPTION_DIST_MASTER) or the Reverse Distribution Master Server Option 336 (OPTION_REVERSE_DIST_MASTER). The different parameters are defined 337 in Figure 3 in Section 4.2.1. Future code points are assigned under 338 Specification Required as per [RFC8126]. 340 7. Security Considerations 342 The security considerations in [RFC2131] and [RFC8415] are to be 343 considered. The use of DHCPv6 options provides a similar level of 344 trust as the one used to provide the IP prefix. The link between the 345 HNA and the DHCPv6 server may benefit from additional security for 346 example by using [I-D.ietf-dhc-sedhcpv6]. 348 8. Acknowledgments 350 We would like to thank Marcin Siodelski, Bernie Volz and Ted Lemon 351 for their comments on the design of the DHCPv6 options. We would 352 also like to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti 353 for their remarks on the architecture design. The designed solution 354 has been largely been inspired by Mark Andrews's document 355 [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We 356 also thank Ray Hunter for its reviews, its comments and for 357 suggesting an appropriated terminology. 359 9. Contributors 361 The co-authors would like to thank Chris Griffiths and Wouter 362 Cloetens that provided a significant contribution in the early 363 versions of the document. 365 10. References 367 10.1. Normative References 369 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 370 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 371 . 373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 374 Requirement Levels", BCP 14, RFC 2119, 375 DOI 10.17487/RFC2119, March 1997, 376 . 378 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 379 RFC 2131, DOI 10.17487/RFC2131, March 1997, 380 . 382 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 383 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 384 . 386 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 387 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 388 . 390 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 391 and P. Hoffman, "Specification for DNS over Transport 392 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 393 2016, . 395 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 396 Writing an IANA Considerations Section in RFCs", BCP 26, 397 RFC 8126, DOI 10.17487/RFC8126, June 2017, 398 . 400 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 401 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 402 May 2017, . 404 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 405 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 406 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 407 RFC 8415, DOI 10.17487/RFC8415, November 2018, 408 . 410 10.2. Informative References 412 [I-D.andrews-dnsop-pd-reverse] 413 Andrews, M., "Automated Delegation of IP6.ARPA reverse 414 zones with Prefix Delegation", draft-andrews-dnsop-pd- 415 reverse-02 (work in progress), November 2013. 417 [I-D.ietf-dhc-sedhcpv6] 418 Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. 419 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work 420 in progress), February 2017. 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", draft-ietf- 426 homenet-front-end-naming-delegation-13 (work in progress), 427 March 2021. 429 [I-D.sury-dnsext-cname-dname] 430 Sury, O., "CNAME+DNAME Name Redirection", draft-sury- 431 dnsext-cname-dname-00 (work in progress), April 2010. 433 Appendix A. Scenarios and impact on the End User 435 This section details various scenarios and discuss their impact on 436 the end user. This section is not normative and limits the 437 description of a limited scope of scenarios that are assumed to be 438 representative. Many other scenarios may be derived from these. 440 Appendix B. Base Scenario 442 The base scenario is the one described in Section 3 in which an ISP 443 manages the DHCP Server, the DM and RDM. 445 The end user subscribes to the ISP (foo), and at subscription time 446 registers for example.foo as its Registered Homenet Domain 447 example.foo. 449 In this scenario, the DHCP Server, DM and RDM are managed by the ISP 450 so the DHCP Server and as such can provide authentication credentials 451 of the HNA to enable secure authenticated transaction with the DM and 452 the Reverse DM. 454 The main advantage of this scenario is that the naming architecture 455 is configured automatically and transparently for the end user. The 456 drawbacks are that the end user uses a Registered Homenet Domain 457 managed by the ISP and that it relies on the ISP naming 458 infrastructure. 460 B.1. Third Party Registered Homenet Domain 462 This section considers the case when the end user wants its home 463 network to use example.com not managed by her ISP (foo) as a 464 Registered Homenet Domain. This section still consider the ISP 465 manages the home network and still provides example.foo as a 466 Registered Homenet Domain. 468 When the end user buys the domain name example.com, it may request to 469 redirect the name example.com to example.foo using static redirection 470 with CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME 471 [I-D.sury-dnsext-cname-dname]. 473 This configuration is performed once when the domain name example.com 474 is registered. The only information the end user needs to know is 475 the domain name assigned by the ISP. Once this configuration is done 476 no additional configuration is needed anymore. More specifically, 477 the HNA may be changed, the zone can be updated as in Appendix B 478 without any additional configuration from the end user. 480 The main advantage of this scenario is that the end user benefits 481 from the Zero Configuration of the Base Scenario Appendix B. Then, 482 the end user is able to register for its home network an unlimited 483 number of domain names provided by an unlimited number of different 484 third party providers. The drawback of this scenario may be that the 485 end user still rely on the ISP naming infrastructure. Note that the 486 only case this may be inconvenient is when the DNS Servers provided 487 by the ISPs results in high latency. 489 B.2. Third Party DNS Infrastructure 491 This scenario considers that the end user uses example.com as a 492 Registered Homenet Domain, and does not want to rely on the 493 authoritative servers provided by the ISP. 495 In this section we limit the outsourcing to the DM and Public 496 Authoritative Server(s) to a third party. The Reverse Public 497 Authoritative Server(s) and the RDM remain managed by the ISP as the 498 IP prefix is managed by the ISP. 500 Outsourcing to a third party DM can be performed in the following 501 ways: 503 1. Updating the DHCP Server Information. One can imagine a GUI 504 interface that enables the end user to modify its profile 505 parameters. Again, this configuration update is done once-for- 506 ever. 508 2. Upload the configuration of the DM to the HNA. In some cases, 509 the provider of the CPE hosting the HNA may be the registrar and 510 provide the CPE already configured. In other cases, the CPE may 511 request the end user to log into the registrar to validate the 512 ownership of the Registered Homenet Domain and agree on the 513 necessary credentials to secure the communication between the HNA 514 and the DM. As described in 515 [I-D.ietf-homenet-front-end-naming-delegation], such settings 516 could be performed in an almost automatic way as to limit the 517 necessary interactions with the end user. 519 B.3. Multiple ISPs 521 This scenario considers a HNA connected to multiple ISPs. 523 Suppose the HNA has been configured each of its interfaces 524 independently with each ISPS as described in Appendix B. Each ISP 525 provides a different Registered Homenet Domain. 527 The protocol and DHCPv6 options described in this document are fully 528 compatible with a HNA connected to multiple ISPs with multiple 529 Registered Homenet Domains. However, the HNA should be able to 530 handle different Registered Homenet Domains. This is an 531 implementation issue which is outside the scope of the current 532 document. 534 If a HNA is not able to handle multiple Registered Homenet Domains, 535 the HNA may remain connected to multiple ISP with a single Registered 536 Homenet Domain. In this case, one entity is chosen to host the 537 Registered Homenet Domain. This entity may be one of the ISP or a 538 third party. Note that having multiple ISPs can be motivated for 539 bandwidth aggregation, or connectivity fail-over. In the case of 540 connectivity fail-over, the fail-over concerns the access network and 541 a failure of the access network may not impact the core network where 542 the DM Server and Public Authoritative Primaries are hosted. In that 543 sense, choosing one of the ISP even in a scenario of multiple ISPs 544 may make sense. However, for sake of simplicity, this scenario 545 assumes that a third party has been chosen to host the Registered 546 Homenet Domain. Configuration is performed as described in 547 Appendix B.1 and Appendix B.2. 549 With the configuration described in Appendix B.1, the HNA is expect 550 to be able to handle multiple Homenet Registered Domain, as the third 551 party redirect to one of the ISPs Servers. With the configuration 552 described in Appendix B.2, DNS zone are hosted and maintained by the 553 third party. A single DNS(SEC) Homenet Zone is built and maintained 554 by the HNA. This latter configuration is likely to match most HNA 555 implementations. 557 The protocol and DHCPv6 options described in this document are fully 558 compatible with a HNA connected to multiple ISPs. To configure or 559 not and how to configure the HNA depends on the HNA facilities. 560 Appendix B and Appendix B.1 require the HNA to handle multiple 561 Registered Homenet Domain, whereas Appendix B.2 does not have such 562 requirement. 564 Authors' Addresses 566 Daniel Migault 567 Ericsson 568 8275 Trans Canada Route 569 Saint Laurent, QC 4S 0B6 570 Canada 572 EMail: daniel.migault@ericsson.com 573 Ralf Weber 574 Akamai 576 EMail: ralf.weber@akamai.com 578 Tomek Mrugalski 579 Internet Systems Consortium, Inc. 580 950 Charter Street 581 Redwood City 94063 582 US 584 EMail: tomasz.mrugalski@gmail.com