idnits 2.17.1 draft-ietf-homenet-naming-architecture-dhc-options-15.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 (13 June 2022) is 683 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-16 ** Downref: Normative reference to an Experimental draft: draft-ietf-homenet-front-end-naming-delegation (ref. 'I-D.ietf-homenet-front-end-naming-delegation') 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: 15 December 2022 Akamai 6 T. Mrugalski 7 Internet Systems Consortium, Inc. 8 13 June 2022 10 DHCPv6 Options for Home Network Naming Authority 11 draft-ietf-homenet-naming-architecture-dhc-options-15 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 15 December 2022. 38 Copyright Notice 40 Copyright (c) 2022 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 (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Procedure Overview . . . . . . . . . . . . . . . . . . . . . 3 57 4. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Registered Homenet Domain Option . . . . . . . . . . . . 4 59 4.2. Distribution Manager Option . . . . . . . . . . . . . . . 5 60 4.2.1. Supported Transport . . . . . . . . . . . . . . . . . 6 61 4.3. Reverse Distribution Manager Server Option . . . . . . . 6 62 5. DHCPv6 Behavior . . . . . . . . . . . . . . . . . . . . . . . 7 63 5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7 64 5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 7 65 5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 7 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 69 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 72 10.2. Informative References . . . . . . . . . . . . . . . . . 9 73 Appendix A. Scenarios and impact on the End User . . . . . . . . 10 74 Appendix B. Base Scenario . . . . . . . . . . . . . . . . . . . 10 75 B.1. Third Party Registered Homenet Domain . . . . . . . . . . 11 76 B.2. Third Party DNS Infrastructure . . . . . . . . . . . . . 11 77 B.3. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 80 1. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 84 "OPTIONAL" in this document are to be interpreted as described in 85 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 86 capitals, as shown here. 88 The reader should be familiar with 89 [I-D.ietf-homenet-front-end-naming-delegation]. 91 2. Introduction 93 [I-D.ietf-homenet-front-end-naming-delegation] specifies how an 94 entity designated as the Homenet Naming Authority (HNA) outsources a 95 Public Homenet Zone to an Outsourcing DNS Infrastructure (DOI). 97 This document describes how a network can provision the HNA with a 98 specific DOI. This could be particularly useful for a DOI partly 99 managed by an ISP, or to make home networks resilient to HNA 100 replacement. The ISP delegates an IP prefix to the home network as 101 well as the associated reverse zone. The ISP is thus aware of the 102 owner of that IP prefix, and as such becomes a natural candidate for 103 hosting the Homenet Reverse Zone - that is the Reverse Distribution 104 Manager (RDM) and potentially the Reverse Public Authoritative 105 Servers. 107 In addition, ISPs often identify the line of the home network with a 108 name. Such name is used for their internal network management 109 operations and is not a name the home network owner has registered 110 to. ISPs may leverage such infrastructure and provide the homenet 111 with a specific domain name designated as per 112 [I-D.ietf-homenet-front-end-naming-delegation] a Homenet Registered 113 Domain. Similarly to the reverse zone, ISPs are aware of who owns 114 that domain name and may become a natural candidate for hosting the 115 Homenet Zone - that is the Distribution Manager (DM) and the Public 116 Authoritative Servers. 118 This document describes DHCPv6 options that enable an ISP to provide 119 the necessary parameters to the HNA, to proceed. More specifically, 120 the ISP provides the Registered Homenet Domain, necessary information 121 on the DM and the RDM so the HNA can manage and upload the Public 122 Homenet Zone and the Reverse Public Homenet Zone as described in 123 [I-D.ietf-homenet-front-end-naming-delegation]. 125 The use of DHCPv6 options may make the configuration completely 126 transparent to the end user and provides a similar level of trust as 127 the one used to provide the IP prefix - when provisioned via DHCP. 129 3. Procedure Overview 131 This section illustrates how a HNA receives the necessary information 132 via DHCPv6 options to outsource its authoritative naming service to 133 the DOI. For the sake of simplicity, and similarly to 134 [I-D.ietf-homenet-front-end-naming-delegation], this section assumes 135 that the HNA and the home network DHCPv6 client are colocated on the 136 Customer Edge (CE) router [RFC7368]. Note also that this is not 137 mandatory and the DHCPv6 client may instruct remotely the HNA and the 138 DHCPv6 either with a proprietary protocol or a protocol that will be 139 defined in the future. In addition, this section assumes the 140 responsible entity for the DHCPv6 server is configured with the DM 141 and RDM. This means a Registered Homenet Domain can be associated to 142 the DHCPv6 client. 144 This scenario is believed to be the most popular scenario. This 145 document does not ignore scenarios where the DHCPv6 server does not 146 have privileged relations with the DM or RDM. These cases are 147 discussed in Appendix A. Such scenarios do not necessarily require 148 configuration for the end user and can also be zero-config. 150 The scenario considered in this section is as follows: 152 1. The HNA is willing to outsource the Public Homenet Zone or 153 Homenet Reverse Zone. The DHCPv6 client is configured to include 154 in its Option Request Option (ORO) the Registered Homenet Domain 155 Option (OPTION_REGISTERED_DOMAIN), the Distribution Manager 156 Option (OPTION_DIST_MANAGER) and the Reverse Distribution Manager 157 Option (OPTION_REVERSE_DIST_MANAGER) option codes. 159 2. The DHCPv6 server responds to the HNA with the requested DHCPv6 160 options based on the identified homenet. The DHCPv6 client 161 passes the information to the HNA. 163 1. The HNA is authenticated (see Section 4.6 of 164 [I-D.ietf-homenet-front-end-naming-delegation]) by the DM and the 165 RDM. The HNA builds the Homenet Zone (or the Homenet Reverse 166 Zone) and proceed as described in 167 [I-D.ietf-homenet-front-end-naming-delegation]. The DHCPv6 168 options provide the necessary non optional parameters described 169 in Section 14 of [I-D.ietf-homenet-front-end-naming-delegation]. 170 The HNA may complement the configurations with additional 171 parameters via means not yet defined. Section 14 of 172 [I-D.ietf-homenet-front-end-naming-delegation] describes such 173 parameters that MAY take some specific non default value. 175 4. DHCPv6 Option 177 This section details the payload of the DHCPv6 options. 179 4.1. Registered Homenet Domain Option 181 The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the 182 FQDN associated to the home network. 184 0 1 2 3 185 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 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | OPTION_REGISTERED_DOMAIN | option-len | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | 190 / Registered Homenet Domain / 191 | | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 1: Registered Domain Option 196 * option-code (16 bits): OPTION_REGISTERED_DOMAIN, the option code 197 for the Registered Homenet Domain (TBD1). 199 * option-len (16 bits): length in octets of the Registered Homenet 200 Domain field as described in [RFC8415]. 202 * Registered Homenet Domain (variable): the FQDN registered for the 203 homenet encoded as described in Section 10 of [RFC8415]. 205 4.2. Distribution Manager Option 207 The Distributed Manager Option (OPTION_DIST_MANAGER) provides the HNA 208 with the FQDN of the DM as well as the transport protocols for the 209 communication between the HNA and the DM. 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | OPTION_DIST_MANAGER | option-len | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Supported Transport | | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 218 | | 219 / Distribution Manager FQDN / 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 2: Distribution Manager Option 225 * option-code (16 bits): OPTION_DIST_MANAGER, the option code for 226 the Distribution Manager Option (TBD2). 228 * option-len (16 bits): length in octets of the enclosed data as 229 described in [RFC8415]. 231 * Supported Transport (16 bits): defines the supported transport by 232 the DM (see Section 4.2.1). Each bit represents a supported 233 transport, and a DM MAY indicate the support of multiple modes. 234 The bit for DNS over TLS [RFC7858] MUST be set. 236 * Distribution Manager FQDN (variable): the FQDN of the DM encoded 237 as described in Section 10 of [RFC8415]. 239 4.2.1. Supported Transport 241 The Supported Transport field of the DHCPv6 option indicates the 242 supported transport protocols. Each bit represents a specific 243 transport mechanism. A bit sets to 1 indicates the associated 244 transport protocol is supported. The corresponding bits are assigned 245 as described in Figure 3 and Section 6. 247 Bit Position | Transport Protocol | Reference 248 -------------+--------------------+----------- 249 0 | DNS over TLS | This-RFC 250 1-15 | unallocated | 252 Figure 3: Supported Transport 254 DNS over TLS: indicates the support of DNS over TLS as described in 255 [RFC7858]. 257 4.3. Reverse Distribution Manager Server Option 259 The Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) 260 provides the HNA with the FQDN of the DM as well as the transport 261 protocols for the communication between the HNA and the DM. 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | OPTION_REVERSE_DIST_MANAGER | option-len | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Supported Transport | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 270 | | 271 / Reverse Distribution Manager FQDN / 272 | | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Figure 4: Reverse Distribution Manager Option 277 * option-code (16 bits): OPTION_REVERSE_DIST_MANAGER, the option 278 code for the Reverse Distribution Manager Option (TBD3). 280 * option-len (16 bits): length in octets of the option-data field as 281 described in [RFC8415]. 283 * Supported Transport (16 bits): defines the supported transport by 284 the RDM (see Section 4.2.1). Each bit represents a supported 285 transport, and a RDM MAY indicate the support of multiple modes. 286 The bit for DNS over TLS [RFC7858] MUST be set. 288 * Reverse Distribution Manager FQDN (variable): the FQDN of the RDM 289 encoded as described in section 10 of [RFC8415]. 291 5. DHCPv6 Behavior 293 5.1. DHCPv6 Server Behavior 295 Sections 17.2.2 and 18.2 of [RFC8415] govern server operation in 296 regards to option assignment. As a convenience to the reader, we 297 mention here that the server will send option foo only if configured 298 with specific values for foo and if the client requested it. In 299 particular, when configured the DHCPv6 server sends the Registered 300 Homenet Domain Option, Distribution Manager Option, the Reverse 301 Distribution Manager Option when requested by the DHCPv6 client by 302 including necessary option codes in its ORO. 304 5.2. DHCPv6 Client Behavior 306 The DHCPv6 client includes Registered Homenet Domain Option, 307 Distribution Manager Option, the Reverse Distribution Manager Option 308 in an ORO as specified in Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 309 18.2.6, and 21.7 of [RFC8415]. 311 Upon receiving a DHCPv6 option described in this document in the 312 Reply message, the HNA SHOULD proceed as described in 313 [I-D.ietf-homenet-front-end-naming-delegation]. 315 5.3. DHCPv6 Relay Agent Behavior 317 There are no additional requirements for the DHCPv6 Relay agents. 319 6. IANA Considerations 321 IANA is requested to assign the following new DHCPv6 Option Codes in 322 the registry maintained in: https://www.iana.org/assignments/dhcpv6- 323 parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2. 325 Value Description Client ORO Singleton Option 326 TBD1 OPTION_REGISTERED_DOMAIN Yes No 327 TBD2 OPTION_DIST_MANAGER Yes Yes 328 TBD3 OPTION_REVERSE_DIST_MANAGER Yes Yes 330 IANA is requested to maintain a new number space of Supported 331 Transport parameter in the Distributed Manager Option 332 (OPTION_DIST_MANAGER) or the Reverse Distribution Manager Option 333 (OPTION_REVERSE_DIST_MANAGER). The different parameters are defined 334 in Figure 3 in Section 4.2.1. Future code points are assigned under 335 Specification Required as per [RFC8126]. 337 7. Security Considerations 339 The security considerations in [RFC8415] are to be considered. The 340 use of DHCPv6 options provides a similar level of trust as the one 341 used to provide the IP prefix. The link between the HNA and the 342 DHCPv6 server may benefit from additional security for example by 343 using [I-D.ietf-dhc-sedhcpv6]. 345 8. Acknowledgments 347 We would like to thank Marcin Siodelski, Bernie Volz and Ted Lemon 348 for their comments on the design of the DHCPv6 options. We would 349 also like to thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti 350 for their remarks on the architecture design. The designed solution 351 has been largely been inspired by Mark Andrews's document 352 [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We 353 also thank Ray Hunter and Michael Richardson for its reviews, its 354 comments and for suggesting an appropriated terminology. 356 9. Contributors 358 The co-authors would like to thank Chris Griffiths and Wouter 359 Cloetens that provided a significant contribution in the early 360 versions of the document. 362 10. References 364 10.1. Normative References 366 [I-D.ietf-homenet-front-end-naming-delegation] 367 Migault, D., Weber, R., Richardson, M., and R. Hunter, 368 "Simple Provisioning of Public Names for Residential 369 Networks", Work in Progress, Internet-Draft, draft-ietf- 370 homenet-front-end-naming-delegation-16, 13 June 2022, 371 . 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, 376 DOI 10.17487/RFC2119, March 1997, 377 . 379 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 380 and P. Hoffman, "Specification for DNS over Transport 381 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 382 2016, . 384 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 385 Writing an IANA Considerations Section in RFCs", BCP 26, 386 RFC 8126, DOI 10.17487/RFC8126, June 2017, 387 . 389 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 390 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 391 May 2017, . 393 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 394 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 395 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 396 RFC 8415, DOI 10.17487/RFC8415, November 2018, 397 . 399 10.2. Informative References 401 [I-D.andrews-dnsop-pd-reverse] 402 Andrews, M., "Automated Delegation of IP6.ARPA reverse 403 zones with Prefix Delegation", Work in Progress, Internet- 404 Draft, draft-andrews-dnsop-pd-reverse-02, 4 November 2013, 405 . 408 [I-D.ietf-dhc-sedhcpv6] 409 Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. 410 Zhang, "Secure DHCPv6", Work in Progress, Internet-Draft, 411 draft-ietf-dhc-sedhcpv6-21, 21 February 2017, 412 . 415 [I-D.sury-dnsext-cname-dname] 416 Sury, O., "CNAME+DNAME Name Redirection", Work in 417 Progress, Internet-Draft, draft-sury-dnsext-cname-dname- 418 00, 15 April 2010, . 421 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 422 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 423 . 425 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 426 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 427 . 429 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 430 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 431 . 433 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 434 Weil, "IPv6 Home Networking Architecture Principles", 435 RFC 7368, DOI 10.17487/RFC7368, October 2014, 436 . 438 Appendix A. Scenarios and impact on the End User 440 This section details various scenarios and discuss their impact on 441 the end user. This section is not normative and limits the 442 description of a limited scope of scenarios that are assumed to be 443 representative. Many other scenarios may be derived from these. 445 Appendix B. Base Scenario 447 The base scenario is the one described in Section 3 in which an ISP 448 manages the DHCPv6 server, the DM and RDM. 450 The end user subscribes to the ISP (foo), and at subscription time 451 registers for example.foo as its Registered Homenet Domain 452 example.foo. 454 In this scenario, the DHCPv6 server, DM and RDM are managed by the 455 ISP so the DHCPv6 server and as such can provide authentication 456 credentials of the HNA to enable secure authenticated transaction 457 with the DM and the Reverse DM. 459 The main advantage of this scenario is that the naming architecture 460 is configured automatically and transparently for the end user. The 461 drawbacks are that the end user uses a Registered Homenet Domain 462 managed by the ISP and that it relies on the ISP naming 463 infrastructure. 465 B.1. Third Party Registered Homenet Domain 467 This section considers the case when the end user wants its home 468 network to use example.com not managed by her ISP (foo) as a 469 Registered Homenet Domain. This section still consider the ISP 470 manages the home network and still provides example.foo as a 471 Registered Homenet Domain. 473 When the end user buys the domain name example.com, it may request to 474 redirect the name example.com to example.foo using static redirection 475 with CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME 476 [I-D.sury-dnsext-cname-dname]. 478 This configuration is performed once when the domain name example.com 479 is registered. The only information the end user needs to know is 480 the domain name assigned by the ISP. Once this configuration is done 481 no additional configuration is needed anymore. More specifically, 482 the HNA may be changed, the zone can be updated as in Appendix B 483 without any additional configuration from the end user. 485 The main advantage of this scenario is that the end user benefits 486 from the Zero Configuration of the Base Scenario Appendix B. Then, 487 the end user is able to register for its home network an unlimited 488 number of domain names provided by an unlimited number of different 489 third party providers. The drawback of this scenario may be that the 490 end user still rely on the ISP naming infrastructure. Note that the 491 only case this may be inconvenient is when the DNS servers provided 492 by the ISPs results in high latency. 494 B.2. Third Party DNS Infrastructure 496 This scenario considers that the end user uses example.com as a 497 Registered Homenet Domain, and does not want to rely on the 498 authoritative servers provided by the ISP. 500 In this section we limit the outsourcing to the DM and Public 501 Authoritative Server(s) to a third party. The Reverse Public 502 Authoritative Server(s) and the RDM remain managed by the ISP as the 503 IP prefix is managed by the ISP. 505 Outsourcing to a third party DM can be performed in the following 506 ways: 508 1. Updating the DHCPv6 server Information. One can imagine a GUI 509 interface that enables the end user to modify its profile 510 parameters. Again, this configuration update is done once-for- 511 ever. 513 2. Upload the configuration of the DM to the HNA. In some cases, 514 the provider of the CE router hosting the HNA may be the 515 registrar and provide the CE router already configured. In other 516 cases, the CE router may request the end user to log into the 517 registrar to validate the ownership of the Registered Homenet 518 Domain and agree on the necessary credentials to secure the 519 communication between the HNA and the DM. As described in 520 [I-D.ietf-homenet-front-end-naming-delegation], such settings 521 could be performed in an almost automatic way as to limit the 522 necessary interactions with the end user. 524 B.3. Multiple ISPs 526 This scenario considers a HNA connected to multiple ISPs. 528 Suppose the HNA has been configured each of its interfaces 529 independently with each ISPS as described in Appendix B. Each ISP 530 provides a different Registered Homenet Domain. 532 The protocol and DHCPv6 options described in this document are fully 533 compatible with a HNA connected to multiple ISPs with multiple 534 Registered Homenet Domains. However, the HNA should be able to 535 handle different Registered Homenet Domains. This is an 536 implementation issue which is outside the scope of the current 537 document. 539 If a HNA is not able to handle multiple Registered Homenet Domains, 540 the HNA may remain connected to multiple ISP with a single Registered 541 Homenet Domain. In this case, one entity is chosen to host the 542 Registered Homenet Domain. This entity may be one of the ISP or a 543 third party. Note that having multiple ISPs can be motivated for 544 bandwidth aggregation, or connectivity fail-over. In the case of 545 connectivity fail-over, the fail-over concerns the access network and 546 a failure of the access network may not impact the core network where 547 the DM and Public Authoritative Primaries are hosted. In that sense, 548 choosing one of the ISP even in a scenario of multiple ISPs may make 549 sense. However, for sake of simplicity, this scenario assumes that a 550 third party has been chosen to host the Registered Homenet Domain. 551 Configuration is performed as described in Appendix B.1 and 552 Appendix B.2. 554 With the configuration described in Appendix B.1, the HNA is expect 555 to be able to handle multiple Homenet Registered Domain, as the third 556 party redirect to one of the ISPs servers. With the configuration 557 described in Appendix B.2, DNS zone are hosted and maintained by the 558 third party. A single DNS(SEC) Homenet Zone is built and maintained 559 by the HNA. This latter configuration is likely to match most HNA 560 implementations. 562 The protocol and DHCPv6 options described in this document are fully 563 compatible with a HNA connected to multiple ISPs. To configure or 564 not and how to configure the HNA depends on the HNA facilities. 565 Appendix B and Appendix B.1 require the HNA to handle multiple 566 Registered Homenet Domain, whereas Appendix B.2 does not have such 567 requirement. 569 Authors' Addresses 571 Daniel Migault 572 Ericsson 573 8275 Trans Canada Route 574 Saint Laurent, QC 4S 0B6 575 Canada 576 Email: daniel.migault@ericsson.com 578 Ralf Weber 579 Akamai 580 Email: ralf.weber@akamai.com 582 Tomek Mrugalski 583 Internet Systems Consortium, Inc. 584 950 Charter Street 585 Redwood City, 94063 586 United States of America 587 Email: tomasz.mrugalski@gmail.com