idnits 2.17.1 draft-ietf-homenet-naming-architecture-dhc-options-11.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 13, 2021) is 1107 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 (-12) exists of draft-ietf-dprive-dnsoquic-01 == Outdated reference: A later version (-27) exists of draft-ietf-homenet-front-end-naming-delegation-12 Summary: 0 errors (**), 0 flaws (~~), 3 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 15, 2021 Akamai 6 T. Mrugalski 7 Internet Systems Consortium, Inc. 8 C. Griffiths 10 W. Cloetens 11 Deutsche Telekom 12 April 13, 2021 14 DHCPv6 Options for Home Network Naming Authority 15 draft-ietf-homenet-naming-architecture-dhc-options-11 17 Abstract 19 This document defines DHCPv6 options so an 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 October 15, 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 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Payload Description . . . . . . . . . . . . . . . . . . . . . 4 63 4.1. Registered Homenet Domain Option . . . . . . . . . . . . 4 64 4.2. Distribution Master Option . . . . . . . . . . . . . . . 5 65 4.2.1. Supported Transport . . . . . . . . . . . . . . . . . 6 66 4.3. Reverse Distribution Master Server Option . . . . . . . . 6 67 5. DHCP Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5.1. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7 69 5.2. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 7 70 5.3. DHCPv6 Relay Agent Behavior . . . . . . . . . . . . . . . 8 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 7. Security Considerations" . . . . . . . . . . . . . . . . . . 8 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 9.2. Informative References . . . . . . . . . . . . . . . . . 10 77 Appendix A. Scenarios and impact on the End User . . . . . . . . 11 78 Appendix B. Base Scenario . . . . . . . . . . . . . . . . . . . 11 79 B.1. Third Party Registered Homenet Domain . . . . . . . . . . 11 80 B.2. Third Party DNS Infrastructure . . . . . . . . . . . . . 12 81 B.3. Multiple ISPs . . . . . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Terminology 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as described in 89 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 90 capitals, as shown here. 92 The reader is expected to be familiar with 93 [I-D.ietf-homenet-front-end-naming-delegation] and its terminology 94 section. 96 2. Introduction 98 [I-D.ietf-homenet-front-end-naming-delegation] describes how Homenet 99 Naming Authority (HNA) outsources the Public Homenet Zone to an 100 Outsourcing Infrastructure. 102 This document shows how an ISP can provision automatically the HNA 103 with a DNS Outsourcing Infrastructure (DOI). Most likely the DOI 104 will be - at least partly be - managed or provided by its ISP, but 105 other cases may envision the ISP storing some configuration so the 106 homenet becomes resilient to HNA replacement. 108 The ISP delegates the home network an IP prefix it owns as well as 109 the associated reverse zone. 110 The ISP is well aware of the owner of that prefix, and as such 111 becomes a natural candidate for hosting the Homenet Reverse Zone - 112 that is the Reverse Distribution Master (RDM) and potentially the 113 Reverse Public Authoritative Servers. 115 In addition, the ISP often identifies the home network with a name. 116 In most cases, the name is used by the ISP for its internal network 117 management operations and is not a name the home network owner has 118 registered to. The ISP may thus leverage such infrastructure and 119 provide the homenet a specific domain name designated as per 120 [I-D.ietf-homenet-front-end-naming-delegation] a Homenet Registered 121 Domain. Similarly to the reverse zone, the ISP is well aware of who 122 owns that domain name and may become a natural candidate for hosting 123 the Homenet Zone - that is the Distribution Master (DM) and the 124 Public Authoritative Servers. 126 This document describes DHCPv6 options that enables the ISP to 127 provide the necessary parameters to the HNA, to proceed. 128 More specifically, the ISP provides the Registered Homenet Domain, 129 necessary information on the DM and the RDM so the HNA can manage and 130 upload the Public Homenet Zone and the Reverse Public Homenet Zone as 131 described in [I-D.ietf-homenet-front-end-naming-delegation]. 133 The use of DHCPv6 options makes the configuration completely 134 transparent to the end user and provides a similar level of trust as 135 the one used to provide the IP prefix. 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 Homenet 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]. The DHCPv6 175 options provide the necessary and non optional parameters 176 described in section 14 of 177 [I-D.ietf-homenet-front-end-naming-delegation]. The HNA MAY set 178 complement the configurations with additional parameters. 179 Section 14 of [I-D.ietf-homenet-front-end-naming-delegation] 180 describes such parameters that MAY take a default value. 182 4. Payload Description 184 This section details the payload of the DHCPv6 options. 186 4.1. Registered Homenet Domain Option 188 The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the 189 FQDN associated to the home network. 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | OPTION_REGISTERED_DOMAIN | option-len | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | | 197 / Registered Homenet Domain / 198 | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Figure 1: Registered Domain Option 203 o option-code (16 bits): OPTION_REGISTERED_DOMAIN, the option code 204 for the Registered Homenet Domain (TBD2). 206 o option-len (16 bits): length in octets of the option-data field as 207 described in [RFC8415]. 209 o Registered Homenet Domain (variable): the FQDN registered for the 210 homenet encoded as described in section 10 of [RFC8415]. 212 4.2. Distribution Master Option 214 The Distributed Master Option (OPTION_DIST_MASTER) provides the HNA 215 to FQDN of the DM as well as the transport protocol for the 216 transaction between the HNA and the DM. 218 0 1 2 3 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | OPTION_DIST_MASTER | option-len | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Supported Transport | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 225 | | 226 / Distribution Master FQDN / 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 2: Distribution Master Option 232 o option-code (16 bits): OPTION_DIST_MASTER, the option code for the 233 DM Option (TBD3). 235 o option-len (16 bits): length in octets of the option-data field as 236 described in [RFC8415]. 238 o Supported Transport (16 bits): defines the supported transport by 239 the DM. Each bit represents a supported transport, and a DM MAY 240 indicate the support of multiple modes. The bit for DNS over TLS 241 [RFC7858] MUST be set. 243 o Distribution Master FQDN (variable): the FQDN of the DM encoded as 244 described in section 10 of [RFC8415]. 246 4.2.1. Supported Transport 248 The Supported Transport filed of the DHCPv6 option indicates the 249 supported transport protocol. Each bit represents a specific 250 transport mechanism. The bit sets to 1 indicates the associated 251 transport protocol is supported. The corresponding bits are assigned 252 as described in Figure 3. 254 Bit | Transport Protocol | Reference 255 ----+--------------------+----------- 256 0 | DNS | This-RFC 257 1 | DNS over TLS | This-RFC 258 2 | DNS over HTTPS | This-RFC 259 3 | DNS over QUIC | This-RFC 260 4-15| unallocated | This-RFC 262 Figure 3: Supported Transport 264 o DNS: indicates the support of DNS over port 53 as described in 265 [RFC1035]. 267 o DNS over TLS: indicates the support of DNS over TLS as described 268 in [RFC7858]. 270 o DNS over HTTPS: indicates the support of DNS over HTTPS as 271 described in [RFC8484]. 273 o DNS over QUIC: indicates the support of DNS over QUIC as defined 274 in [I-D.ietf-dprive-dnsoquic]. 276 4.3. Reverse Distribution Master Server Option 278 The Reverse Distribution Master Server Option 279 (OPTION_REVERSE_DIST_MASTER) provides the HNA to FQDN of the DM as 280 well as the transport protocol for the transaction between the HNA 281 and the DM. 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | OPTION_REVERSE_DIST_MASTER | option-len | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Supported Transport | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 290 | | 291 / Reverse Distribution Master FQDN / 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 4: Reverse Distribution Master Option 297 o option-code (16 bits): OPTION_REVERSE_DIST_MASTER, the option code 298 for the Reverse Distribution Master Option (TBD4). 300 o option-len (16 bits): length in octets of the option-data field as 301 described in [RFC8415]. 303 o Supported Transport (16 bits): defines the supported transport by 304 the DM. Each bit represents a supported transport, and a DM MAY 305 indicate the support of multiple modes. The bit for DoT MUST be 306 set. 308 o Reverse Distribution Master FQDN (variable): the FQDN of the RDM 309 encoded as described in section 10 of [RFC8415]. 311 5. DHCP Behavior 313 5.1. DHCPv6 Server Behavior 315 Sections 17.2.2 and 18.2 of [RFC8415] govern server operation in 316 regards to option assignment. As a convenience to the reader, we 317 mention here that the server will send option foo only if configured 318 with specific values for foo and if the client requested it. In 319 particular, when configured the DHCP Server sends the Registered 320 Homenet Domain Option, Distribution Master Option, the Reverse 321 Distribution Master Option when requested by the DHCPv6 client by 322 including necessary option codes in its ORO. 324 5.2. DHCPv6 Client Behavior 326 The DHCPv6 client sends a ORO with the necessary option codes: 327 Registered Homenet Domain Option, Distribution Master Option, the 328 Reverse Distribution Master Option. 330 Upon receiving a DHCP option described in this document in the Reply 331 message, the HNA SHOULD proceed as described in 332 [I-D.ietf-homenet-front-end-naming-delegation]. 334 5.3. DHCPv6 Relay Agent Behavior 336 There are no additional requirements for the DHCP Relay agents. 338 6. IANA Considerations 340 IANA is requested to assign the following new DHCPv6 Option Codes in 341 the registry maintained in: https://www.iana.org/assignments/dhcpv6- 342 parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2. 344 Value Description Client ORO Singleton Option 345 TBD1 OPTION_REGISTERED_DOMAIN Yes Yes 346 TBD2 OPTION_DIST_MASTER Yes Yes 347 TBD3 OPTION_REVERSE_DIST_MASTER Yes Yes 349 IANA is requested to maintain a new number space of Supported 350 Transport parameter in the Distributed Master Option 351 (OPTION_DIST_MASTER) or the Reverse Distribution Master Server Option 352 (OPTION_REVERSE_DIST_MASTER). The different parameters are defined 353 in Figure 3 in Section 4.2.1. Future code points 4 - 8 are assigned 354 under the IETF Review, other code points are assigned under 355 Specification Required as per [RFC8126]. 357 7. Security Considerations" 359 The security considerations in [RFC2131] and [RFC8415] are to be 360 considered. 361 The use of DHCPv6 options provides a similar level of trust as the 362 one used to provide the IP prefix. The link between the HNA and the 363 DHCPv6 server may benefit from additional security for example by 364 using [I-D.ietf-dhc-sedhcpv6]. 366 8. Acknowledgments 368 We would like to thank Marcin Siodelski and Bernie Volz for their 369 comments on the design of the DHCPv6 options. We would also like to 370 thank Mark Andrews, Andrew Sullivan and Lorenzo Colliti for their 371 remarks on the architecture design. The designed solution has been 372 largely been inspired by Mark Andrews's document 373 [I-D.andrews-dnsop-pd-reverse] as well as discussions with Mark. We 374 also thank Ray Hunter for its reviews, its comments and for 375 suggesting an appropriated terminology. 377 9. References 379 9.1. Normative References 381 [I-D.ietf-dprive-dnsoquic] 382 Huitema, C., Mankin, A., and S. Dickinson, "Specification 383 of DNS over Dedicated QUIC Connections", draft-ietf- 384 dprive-dnsoquic-01 (work in progress), October 2020. 386 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 387 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 388 . 390 [RFC1035] Mockapetris, P., "Domain names - implementation and 391 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 392 November 1987, . 394 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, 396 DOI 10.17487/RFC2119, March 1997, 397 . 399 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 400 RFC 2131, DOI 10.17487/RFC2131, March 1997, 401 . 403 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 404 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 405 . 407 [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the 408 DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, 409 . 411 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 412 and P. Hoffman, "Specification for DNS over Transport 413 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 414 2016, . 416 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 417 Writing an IANA Considerations Section in RFCs", BCP 26, 418 RFC 8126, DOI 10.17487/RFC8126, June 2017, 419 . 421 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 422 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 423 May 2017, . 425 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 426 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 427 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 428 RFC 8415, DOI 10.17487/RFC8415, November 2018, 429 . 431 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 432 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 433 . 435 9.2. Informative References 437 [I-D.andrews-dnsop-pd-reverse] 438 Andrews, M., "Automated Delegation of IP6.ARPA reverse 439 zones with Prefix Delegation", draft-andrews-dnsop-pd- 440 reverse-02 (work in progress), November 2013. 442 [I-D.ietf-dhc-sedhcpv6] 443 Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. 444 Zhang, "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-21 (work 445 in progress), February 2017. 447 [I-D.ietf-homenet-front-end-naming-delegation] 448 Migault, D., Weber, R., Richardson, M., Hunter, R., 449 Griffiths, C., and W. Cloetens, "Simple Provisioning of 450 Public Names for Residential Networks", draft-ietf- 451 homenet-front-end-naming-delegation-12 (work in progress), 452 November 2020. 454 [I-D.sury-dnsext-cname-dname] 455 Sury, O., "CNAME+DNAME Name Redirection", draft-sury- 456 dnsext-cname-dname-00 (work in progress), April 2010. 458 Appendix A. Scenarios and impact on the End User 460 This section details various scenarios and discuss their impact on 461 the end user. This section is not normative and limits the 462 description of a limited scope of scenarios that are assumed to be 463 representative. Many other scenarios may be derived from these. 465 Appendix B. Base Scenario 467 The base scenario is the one described in Section 3 in which an ISP 468 manages the DHCP Server, the DM and RDM. 470 The end user subscribes to the ISP (foo), and at subscription time 471 registers for example.foo as its Registered Homenet Domain 472 example.foo. 474 In this scenario, the DHCP Server, DM and RDM are managed by the ISP 475 so the DHCP Server and as such can provide authentication credentials 476 of the HNA to enable secure authenticated transaction with the DM and 477 the Reverse DM. 479 The main advantage of this scenario is that the naming architecture 480 is configured automatically and transparently for the end user. The 481 drawbacks are that the end user uses a Registered Homenet Domain 482 managed by the ISP and that it relies on the ISP naming 483 infrastructure. 485 B.1. Third Party Registered Homenet Domain 487 This section considers the case when the end user wants its home 488 network to use example.com not managed by her ISP (foo) as a 489 Registered Homenet Domain. 490 This section still consider the ISP manages the home network and 491 still provides example.foo as a Registered Homenet Domain. 493 When the end user buys the domain name example.com, it may request to 494 redirect the name example.com to example.foo using static redirection 495 with CNAME [RFC2181], [RFC1034], DNAME [RFC6672] or CNAME+DNAME 496 [I-D.sury-dnsext-cname-dname]. 498 This configuration is performed once when the domain name example.com 499 is registered. The only information the end user needs to know is 500 the domain name assigned by the ISP. Once this configuration is done 501 no additional configuration is needed anymore. More specifically, 502 the HNA may be changed, the zone can be updated as in Appendix B 503 without any additional configuration from the end user. 505 The main advantage of this scenario is that the end user benefits 506 from the Zero Configuration of the Base Scenario Appendix B. Then, 507 the end user is able to register for its home network an unlimited 508 number of domain names provided by an unlimited number of different 509 third party providers. 510 The drawback of this scenario may be that the end user still rely on 511 the ISP naming infrastructure. Note that the only case this may be 512 inconvenient is when the DNS Servers provided by the ISPs results in 513 high latency. 515 B.2. Third Party DNS Infrastructure 517 This scenario considers that the end user uses example.com as a 518 Registered Homenet Domain, and does not want to rely on the 519 authoritative servers provided by the ISP. 521 In this section we limit the outsourcing to the DM and Public 522 Authoritative Server(s) to a third party. The Reverse Public 523 Authoritative Server(s) and the RDM remain managed by the ISP as the 524 IP prefix is managed by the ISP. 526 Outsourcing to a third party DM can be performed in the following 527 ways: 529 1. Updating the DHCP Server Information. One can imagine a GUI 530 interface that enables the end user to modify its profile 531 parameters. Again, this configuration update is done once-for- 532 ever. 534 2. Upload the configuration of the DM to the HNA. In some cases, 535 the provider of the CPE hosting the HNA may be the registrar and 536 provide the CPE already configured. In other cases, the CPE may 537 request the end user to log into the registrar to validate the 538 ownership of the Registered Homenet Domain and agree on the 539 necessary credentials to secure the communication between the HNA 540 and the DM. As described in 541 [I-D.ietf-homenet-front-end-naming-delegation], such settings 542 could be performed in an almost automatic way as to limit the 543 necessary interactions with the end user. 545 B.3. Multiple ISPs 547 This scenario considers a HNA connected to multiple ISPs. 549 Suppose the HNA has been configured each of its interfaces 550 independently with each ISPS as described in Appendix B. Each ISP 551 provides a different Registered Homenet Domain. 553 The protocol and DHCPv6 options described in this document are fully 554 compatible with a HNA connected to multiple ISPs with multiple 555 Registered Homenet Domains. However, the HNA should be able to 556 handle different Registered Homenet Domains. This is an 557 implementation issue which is outside the scope of the current 558 document. 560 If a HNA is not able to handle multiple Registered Homenet Domains, 561 the HNA may remain connected to multiple ISP with a single Registered 562 Homenet Domain. In this case, one entity is chosen to host the 563 Registered Homenet Domain. This entity may be one of the ISP or a 564 third party. Note that having multiple ISPs can be motivated for 565 bandwidth aggregation, or connectivity fail-over. In the case of 566 connectivity fail-over, the fail-over concerns the access network and 567 a failure of the access network may not impact the core network where 568 the DM Server and Public Authoritative Primaries are hosted. In that 569 sense, choosing one of the ISP even in a scenario of multiple ISPs 570 may make sense. However, for sake of simplicity, this scenario 571 assumes that a third party has been chosen to host the Registered 572 Homenet Domain. Configuration is performed as described in 573 Appendix B.1 and Appendix B.2. 575 With the configuration described in Appendix B.1, the HNA is expect 576 to be able to handle multiple Homenet Registered Domain, as the third 577 party redirect to one of the ISPs Servers. With the configuration 578 described in Appendix B.2, DNS zone are hosted and maintained by the 579 third party. A single DNS(SEC) Homenet Zone is built and maintained 580 by the HNA. This latter configuration is likely to match most HNA 581 implementations. 583 The protocol and DHCPv6 options described in this document are fully 584 compatible with a HNA connected to multiple ISPs. To configure or 585 not and how to configure the HNA depends on the HNA facilities. 586 Appendix B and Appendix B.1 require the HNA to handle multiple 587 Registered Homenet Domain, whereas Appendix B.2 does not have such 588 requirement. 590 Authors' Addresses 592 Daniel Migault 593 Ericsson 594 8275 Trans Canada Route 595 Saint Laurent, QC 4S 0B6 596 Canada 598 EMail: daniel.migault@ericsson.com 599 Ralf Weber 600 Akamai 602 EMail: ralf.weber@akamai.com 604 Tomek Mrugalski 605 Internet Systems Consortium, Inc. 606 950 Charter Street 607 Redwood City 94063 608 US 610 EMail: tomasz.mrugalski@gmail.com 612 Chris Griffiths 614 EMail: cgriffiths@gmail.com 616 Wouter Cloetens 617 Deutsche Telekom 619 EMail: wouter.cloetens@external.telekom.de