diff options
Diffstat (limited to 'doc/rfc/rfc9527.txt')
| -rw-r--r-- | doc/rfc/rfc9527.txt | 666 |
1 files changed, 666 insertions, 0 deletions
diff --git a/doc/rfc/rfc9527.txt b/doc/rfc/rfc9527.txt new file mode 100644 index 0000000..15f7eca --- /dev/null +++ b/doc/rfc/rfc9527.txt @@ -0,0 +1,666 @@ + + + + +Internet Engineering Task Force (IETF) D. Migault +Request for Comments: 9527 Ericsson +Category: Standards Track R. Weber +ISSN: 2070-1721 Akamai + T. Mrugalski + ISC + January 2024 + + + DHCPv6 Options for the Homenet Naming Authority + +Abstract + + This document defines DHCPv6 options so that a Homenet Naming + Authority (HNA) can automatically set the appropriate configuration + and outsource the authoritative naming service for the home network. + In most cases, the outsourcing mechanism is transparent for the end + user. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9527. + +Copyright Notice + + Copyright (c) 2024 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Procedure Overview + 4. DHCPv6 Options + 4.1. Registered Homenet Domain Option + 4.2. Forward Distribution Manager Option + 4.3. Reverse Distribution Manager Server Option + 4.4. Supported Transport + 5. DHCPv6 Behavior + 5.1. DHCPv6 Server Behavior + 5.2. DHCPv6 Client Behavior + 5.3. DHCPv6 Relay Agent Behavior + 6. IANA Considerations + 6.1. DHCPv6 Option Codes + 6.2. Supported Transport Parameter + 7. Security Considerations + 8. References + 8.1. Normative References + 8.2. Informative References + Appendix A. Scenarios and Impact on the End User + A.1. Base Scenario + A.2. Third-Party Registered Homenet Domain + A.3. Third-Party DNS Infrastructure + A.4. Multiple ISPs + Acknowledgments + Contributors + Authors' Addresses + +1. Introduction + + [RFC9526] specifies how an entity designated as the Homenet Naming + Authority (HNA) outsources a Public Homenet Zone to a DNS Outsourcing + Infrastructure (DOI). + + This document describes how a network can provision the HNA with a + specific DOI. This could be particularly useful for a DOI partly + managed by an ISP or to make home networks resilient to HNA + replacement. The ISP delegates an IP prefix and the associated + reverse zone to the home network. The ISP is thus aware of the owner + of that IP prefix and, as such, becomes a natural candidate for + hosting the Homenet Reverse Zone -- that is, the Reverse Distribution + Manager (RDM) and potentially the Reverse Public Authoritative + Servers. + + In addition, ISPs often identify the line of the home network with a + name. Such name is used for their internal network management + operations and is not a name the home network owner has registered + to. ISPs may leverage such infrastructure and provide the home + network with a specific domain name designated per a Registered + Homenet Domain [RFC9526]. Similarly to the reverse zone, ISPs are + aware of who owns that domain name and may become a natural candidate + for hosting the Homenet Zone -- that is, the Distribution Manager + (DM) and the Public Authoritative Servers. + + This document describes DHCPv6 options that enable an ISP to provide + the necessary parameters to the HNA to proceed. More specifically, + the ISP provides the Registered Homenet Domain and the necessary + information on the DM and the RDM so the HNA can manage and upload + the Public Homenet Zone and the Reverse Public Homenet Zone as + described in [RFC9526]. + + The use of DHCPv6 options may make the configuration completely + transparent to the end user and provides a similar level of trust as + the one used to provide the IP prefix, when provisioned via DHCP. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + + The reader should be familiar with [RFC9526]. + +3. Procedure Overview + + This section illustrates how an HNA receives the necessary + information via DHCPv6 options to outsource its authoritative naming + service to the DOI. For the sake of simplicity, and similarly to + [RFC9526], this section assumes that the HNA and the home network + DHCPv6 client are colocated on the Customer Premises Equipment (CPE) + router [RFC7368]. Also, note that this is not mandatory, and the + DHCPv6 client may remotely instruct the HNA with a protocol that will + be standardized in the future. In addition, this section assumes + that the responsible entity for the DHCPv6 server is provisioned with + the DM and RDM information, which is associated with the requested + Registered Homenet Domain. This means a Registered Homenet Domain + can be associated with the DHCPv6 client. + + This scenario is believed to be the most popular scenario. This + document does not ignore scenarios where the DHCPv6 server does not + have privileged relations with the DM or RDM. These cases are + discussed in Appendix A. Such scenarios do not necessarily require + configuration for the end user and can also be zero configuration. + + The scenario considered in this section is as follows: + + 1. The HNA is willing to outsource the Public Homenet Zone or + Homenet Reverse Zone. The DHCPv6 client is configured to include + in its Option Request Option (ORO) the Registered Homenet Domain + Option (OPTION_REGISTERED_DOMAIN), the Forward Distribution + Manager Option (OPTION_FORWARD_DIST_MANAGER), and the Reverse + Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) option + codes. + + 2. The DHCPv6 server responds to the DHCPv6 client with the + requested DHCPv6 options based on the identified homenet. The + DHCPv6 client passes the information to the HNA. + + 3. The HNA is authenticated (see "Securing the Control Channel" + (Section 6.6) of [RFC9526]) by the DM and the RDM. The HNA + builds the Homenet Zone (or the Homenet Reverse Zone) and + proceeds as described in [RFC9526]. The DHCPv6 options provide + the necessary non-optional parameters described in Appendix B of + [RFC9526]. The HNA may complement the configurations with + additional parameters via means not yet defined. Appendix B of + [RFC9526] describes such parameters that may take some specific + non-default value. + +4. DHCPv6 Options + + This section details the payload of the DHCPv6 options following the + guidelines of [RFC7227]. + +4.1. Registered Homenet Domain Option + + The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the + fully qualified domain name (FQDN) associated with the home network. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OPTION_REGISTERED_DOMAIN | option-len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + / Registered Homenet Domain / + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: Registered Domain Option + + option-code (16 bits): OPTION_REGISTERED_DOMAIN; the option code for + the Registered Homenet Domain (145). + + option-len (16 bits): Length in octets of the Registered Homenet + Domain field as described in [RFC8415]. + + Registered Homenet Domain (variable): The FQDN registered for the + homenet encoded as described in Section 10 of [RFC8415]. + +4.2. Forward Distribution Manager Option + + The Forward Distribution Manager Option (OPTION_FORWARD_DIST_MANAGER) + provides the HNA with the FQDN of the DM as well as the transport + protocols for the communication between the HNA and the DM. As + opposed to IP addresses, the FQDN requires a DNS resolution before + establishing the communication between the HNA and the DM. However, + the use of an FQDN provides multiple advantages over IP addresses. + Firstly, it makes the DHCPv6 option easier to parse and smaller, + especially when IPv4 and IPv6 addresses are expected to be provided. + Then, the FQDN can reasonably be seen as a more stable identifier + than IP addresses as well as a pointer to additional information that + may be useful, in the future, to establish the communication between + the HNA and the DM. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OPTION_FORWARD_DIST_MANAGER | option-len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Supported Transport | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + / Distribution Manager FQDN / + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: Forward Distribution Manager Option + + option-code (16 bits): OPTION_FORWARD_DIST_MANAGER; the option code + for the Forward Distribution Manager Option (146). + + option-len (16 bits): Length in octets of the enclosed data as + described in [RFC8415]. + + Supported Transport (16 bits): Defines the Supported Transport by + the DM (see Section 4.4). Each bit represents a supported + transport, and a DM MAY indicate the support of multiple modes. + The bit for DNS over mutually authenticated TLS (DomTLS) MUST be + set. + + Distribution Manager FQDN (variable): The FQDN of the DM encoded as + described in Section 10 of [RFC8415]. + + It is worth noting that the DHCPv6 option specifies the Supported + Transport without specifying any explicit port. Unless the HNA and + the DM have agreed on using a specific port -- for example, by + configuration, or any out-of-band mechanism -- the default port is + used and must be specified. The specification of such default port + may be defined in the specification of the designated Supported + Transport or in any other document. In the case of DomTLS, the + default port value is 853 per DNS over TLS [RFC7858] and DNS Zone + Transfer over TLS [RFC9103]. + + The need to associate the port value to each Supported Transport in + the DHCPv6 option has been balanced with the difficulty of handling a + list of tuples (transport, port) and the possibility of using a + dedicated IP address for the DM in case the default port is already + in use. + +4.3. Reverse Distribution Manager Server Option + + The Reverse Distribution Manager Option (OPTION_REVERSE_DIST_MANAGER) + provides the HNA with the FQDN of the DM as well as the transport + protocols for the communication between the HNA and the DM. + + 0 1 2 3 + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OPTION_REVERSE_DIST_MANAGER | option-len | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Supported Transport | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + / Reverse Distribution Manager FQDN / + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: Reverse Distribution Manager Option + + option-code (16 bits): OPTION_REVERSE_DIST_MANAGER; the option code + for the Reverse Distribution Manager Option (147). + + option-len (16 bits): Length in octets of the option-data field as + described in [RFC8415]. + + Supported Transport (16 bits): Defines the Supported Transport by + the RDM (see Section 4.4). Each bit represents a supported + transport, and an RDM MAY indicate the support of multiple modes. + The bit for DomTLS [RFC7858] MUST be set. + + Reverse Distribution Manager FQDN (variable): The FQDN of the RDM + encoded as described in Section 10 of [RFC8415]. + + For the port number associated to the Supported Transport, the same + considerations as described in Section 4.2 apply. + +4.4. Supported Transport + + The Supported Transport field of the DHCPv6 option indicates the + Supported Transport protocols. Each bit represents a specific + transport mechanism. A bit set to 1 indicates the associated + transport protocol is supported. The corresponding bits are assigned + as described in Table 2. + + DNS over mutually authenticated TLS (DomTLS): Indicates the support + of DNS over TLS [RFC7858] and DNS Zone Transfer over TLS [RFC9103] + as described in [RFC9526]. + + As an example, the Supported Transport field expressing support for + DomTLS looks as follows and has a numeric value of 0x0001: + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | must be zero |1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +5. DHCPv6 Behavior + +5.1. DHCPv6 Server Behavior + + Section 18.3 of [RFC8415] governs server operation regarding option + assignment. As a convenience to the reader, we mention here that the + server will send option foo only if configured with specific values + for foo and if the client requested it. In particular, when + configured, the DHCPv6 server sends the Registered Homenet Domain + Option, Distribution Manager Option, and Reverse Distribution Manager + Option when requested by the DHCPv6 client by including necessary + option codes in its ORO. + +5.2. DHCPv6 Client Behavior + + The DHCPv6 client includes the Registered Homenet Domain Option, + Distribution Manager Option, and Reverse Distribution Manager Option + in an ORO as specified in Sections 18.2 and 21.7 of [RFC8415]. + + Upon receiving a DHCPv6 option, as described in this document, in the + Reply message, the HNA SHOULD proceed as described in [RFC9526]. + +5.3. DHCPv6 Relay Agent Behavior + + There are no additional requirements for the DHCPv6 Relay agents. + +6. IANA Considerations + +6.1. DHCPv6 Option Codes + + IANA has assigned the following new DHCPv6 Option Codes in the + "Option Codes" registry maintained at + <https://www.iana.org/assignments/dhcpv6-parameters>. + + +=====+=============================+======+===========+===========+ + |Value| Description |Client| Singleton | Reference | + | | |ORO | Option | | + +=====+=============================+======+===========+===========+ + |145 | OPTION_REGISTERED_DOMAIN |Yes | No | RFC 9527, | + | | | | | Section | + | | | | | 4.1 | + +-----+-----------------------------+------+-----------+-----------+ + |146 | OPTION_FORWARD_DIST_MANAGER |Yes | Yes | RFC 9527, | + | | | | | Section | + | | | | | 4.2 | + +-----+-----------------------------+------+-----------+-----------+ + |147 | OPTION_REVERSE_DIST_MANAGER |Yes | Yes | RFC 9527, | + | | | | | Section | + | | | | | 4.3 | + +-----+-----------------------------+------+-----------+-----------+ + + Table 1: Option Codes Registry + +6.2. Supported Transport Parameter + + IANA has created and maintains a new registry called "Supported + Transport" under the "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)" registry at <https://www.iana.org/assignments/ + dhcpv6-parameters>. This registry contains Supported Transport + parameters in the Distributed Manager Option + (OPTION_FORWARD_DIST_MANAGER) or the Reverse Distribution Manager + Option (OPTION_REVERSE_DIST_MANAGER). The different parameters are + defined in Table 2 (Section 6.2). + + The Supported Transport field of the DHCPv6 option is a two-octet + field that indicates the Supported Transport protocols. Each bit + represents a specific transport mechanism. + + New entries MUST specify the bit position, the transport protocol + description, a mnemonic, and a reference as shown in Table 2. + + Changes to the format or policies of the registry are managed by the + IETF via the IESG. + + Future code points are assigned under RFC Required per [RFC8126]. + The initial registry is as specified in Table 2 below. + + +======================+====================+==========+===========+ + | Bit Position (least | Transport Protocol | Mnemonic | Reference | + | to most significant) | Description | | | + +======================+====================+==========+===========+ + | 0 | DNS over mutually | DomTLS | RFC 9527 | + | | authenticated TLS | | | + +----------------------+--------------------+----------+-----------+ + | 1-15 | Unassigned | | | + +----------------------+--------------------+----------+-----------+ + + Table 2: Supported Transport Registry + +7. Security Considerations + + The security considerations in [RFC8415] are to be considered. The + trust associated with the information carried by the DHCPv6 options + described in this document is similar to the one associated with the + IP prefix, when configured via DHCPv6. + + In some cases, the ISP MAY identify the HNA by its wire line (i.e., + physically), which may not require relying on TLS to authenticate the + HNA. As the use of TLS is mandatory, it is expected that the HNA + will be provisioned with a certificate. In some cases, the HNA may + use a self-signed certificate. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., + and P. Hoffman, "Specification for DNS over Transport + Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May + 2016, <https://www.rfc-editor.org/info/rfc7858>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., + Richardson, M., Jiang, S., Lemon, T., and T. Winters, + "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", + RFC 8415, DOI 10.17487/RFC8415, November 2018, + <https://www.rfc-editor.org/info/rfc8415>. + + [RFC9103] Toorop, W., Dickinson, S., Sahib, S., Aras, P., and A. + Mankin, "DNS Zone Transfer over TLS", RFC 9103, + DOI 10.17487/RFC9103, August 2021, + <https://www.rfc-editor.org/info/rfc9103>. + + [RFC9526] Migault, D., Weber, R., Richardson, M., and R. Hunter, + "Simple Provisioning of Public Names for Residential + Networks", RFC 9526, DOI 10.17487/RFC9526, January 2024, + <https://www.rfc-editor.org/info/rfc9526>. + +8.2. Informative References + + [CNAME-PLUS-DNAME] + Surý, O., "CNAME+DNAME Name Redirection", Work in + Progress, Internet-Draft, draft-sury-dnsop-cname-plus- + dname-01, 15 July 2018, + <https://datatracker.ietf.org/doc/html/draft-sury-dnsop- + cname-plus-dname-01>. + + [PD-REVERSE] + Andrews, M., "Automated Delegation of IP6.ARPA reverse + zones with Prefix Delegation", Work in Progress, Internet- + Draft, draft-andrews-dnsop-pd-reverse-02, 5 November 2013, + <https://datatracker.ietf.org/doc/html/draft-andrews- + dnsop-pd-reverse-02>. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, + <https://www.rfc-editor.org/info/rfc1034>. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, + <https://www.rfc-editor.org/info/rfc2181>. + + [RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the + DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, + <https://www.rfc-editor.org/info/rfc6672>. + + [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and + S. Krishnan, "Guidelines for Creating New DHCPv6 Options", + BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, + <https://www.rfc-editor.org/info/rfc7227>. + + [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. + Weil, "IPv6 Home Networking Architecture Principles", + RFC 7368, DOI 10.17487/RFC7368, October 2014, + <https://www.rfc-editor.org/info/rfc7368>. + +Appendix A. Scenarios and Impact on the End User + + This appendix details various scenarios and discusses their impact on + the end user. This appendix is not normative and limits the + description of a limited scope of scenarios that are assumed to be + representative. Many other scenarios may be derived from these. + +A.1. Base Scenario + + The base scenario, as described in Section 3, is one in which an ISP + manages the DHCPv6 server, DM, and RDM. + + The end user subscribes to the ISP (foo), and at subscription time, + it registers foo.example as its Registered Homenet Domain. + + In this scenario, the DHCPv6 server, DM, and RDM are managed by the + ISP, so the DHCPv6 server and such can provide authentication + credentials of the HNA to enable secure authenticated transaction + with the DM and the Reverse DM. + + The main advantage of this scenario is that the naming architecture + is configured automatically and transparently for the end user. The + drawbacks are that the end user uses a Registered Homenet Domain + managed by the ISP and that it relies on the ISP naming + infrastructure. + +A.2. Third-Party Registered Homenet Domain + + This appendix considers the case where the end user wants its home + network to use example.com but does not want it to be managed by the + ISP (foo) as a Registered Homenet Domain, and the ISP manages the + home network and still provides foo.example as a Registered Homenet + Domain. + + When the end user buys the domain name example.com, it may request to + redirect example.com to foo.example using static redirection with + CNAME [RFC1034] [RFC2181], DNAME [RFC6672], or CNAME+DNAME + [CNAME-PLUS-DNAME]. The only information the end user needs to know + is the domain name assigned by the ISP. Once the redirection has + been configured, the HNA may be changed, and the zone can be updated + as described in Appendix A.1 without any additional configuration + from the end user. + + The main advantage of this scenario is that the end user benefits + from the zero configuration of the base scenario in Appendix A.1. + Then, the end user is able to register an unlimited number of domain + names provided by an unlimited number of different third-party + providers for its home network. The drawback of this scenario may be + that the end user still needs to rely on the ISP naming + infrastructure. Note that this may be inconvenient in the case where + the DNS servers provided by the ISPs result in high latency. + +A.3. Third-Party DNS Infrastructure + + This scenario involves the end user using example.com as a Registered + Homenet Domain and not relying on the authoritative servers provided + by the ISP. + + In this appendix, we limit the outsourcing of the DM and Public + Authoritative Server(s) to a third party. The Reverse Public + Authoritative Server(s) and the RDM remain managed by the ISP as the + IP prefix is managed by the ISP. + + Outsourcing to a third-party DM can be performed in the following + ways: + + 1. Updating the DHCPv6 server information. One can imagine a GUI + interface that enables the end user to modify its profile + parameters. Again, this configuration update only needs to be + performed one time. + + 2. Uploading the configuration of the DM to the HNA. In some cases, + the provider of the CPE router hosting the HNA may be the + registrar, and the registrar may provide the CPE router already + configured. In other cases, the CPE router may request the end + user to log into the registrar to validate the ownership of the + Registered Homenet Domain and agree on the necessary credentials + to secure the communication between the HNA and the DM. As + described in [RFC9526], such settings could be performed in an + almost automatic way as to limit the necessary interactions with + the end user. + +A.4. Multiple ISPs + + This scenario involves an HNA connected to multiple ISPs. + + Suppose the HNA has configured each of its interfaces independently + with each ISP as described in Appendix A.1. Each ISP provides a + different Registered Homenet Domain. + + The protocol and DHCPv6 options described in this document are fully + compatible with an HNA connected to multiple ISPs with multiple + Registered Homenet Domains. However, the HNA should be able to + handle different Registered Homenet Domains. This is an + implementation issue, which is outside the scope of this document. + + If an HNA is not able to handle multiple Registered Homenet Domains, + the HNA may remain connected to multiple ISPs with a single + Registered Homenet Domain. In this case, one entity is chosen to + host the Registered Homenet Domain. This entity may be an ISP or a + third party. Note that having multiple ISPs can be motivation for + bandwidth aggregation or connectivity failover. In the case of + connectivity failover, the failover concerns the access network, and + a failure of the access network may not impact the core network where + the DM and Public Authoritative Primaries are hosted. In that sense, + choosing one of the ISPs even in a scenario of multiple ISPs may make + sense. However, for the sake of simplicity, this scenario assumes + that a third party has been chosen to host the Registered Homenet + Domain. Configuration is performed as described in Appendices A.2 + and A.3. + + With the configuration described in Appendix A.2, the HNA is expected + to be able to handle multiple Registered Homenet Domains as the + third-party redirect to one of the ISP's servers. With the + configuration described in Appendix A.3, DNS zones are hosted and + maintained by the third party. A single DNS(SEC) Homenet Zone is + built and maintained by the HNA. This latter configuration is likely + to match most HNA implementations. + + The protocol and DHCPv6 options described in this document are fully + compatible with an HNA connected to multiple ISPs. Whether to + configure the HNA or not, and how to configure the HNA, depends on + the HNA facilities. Appendices A.1 and A.2 require the HNA to handle + multiple Registered Homenet Domains, whereas Appendix A.3 does not + have such a requirement. + +Acknowledgments + + We would like to thank Marcin Siodelski, Bernie Volz, and Ted Lemon + for their comments on the design of the DHCPv6 options. We would + also like to thank Mark Andrews, Andrew Sullivan, and Lorenzo Colliti + for their remarks on the architecture design. The designed solution + has been largely inspired by Mark Andrews's document [PD-REVERSE] as + well as discussions with Mark. We also thank Ray Hunter and Michael + Richardson for their reviews and comments and for suggesting + appropriate terminology. + +Contributors + + The coauthors would like to thank Chris Griffiths and Wouter Cloetens + for providing significant contributions to the early draft versions + of this document. + +Authors' Addresses + + Daniel Migault + Ericsson + 8275 Trans Canada Route + Saint Laurent QC 4S 0B6 + Canada + Email: daniel.migault@ericsson.com + + + Ralf Weber + Akamai + Email: ralf.weber@akamai.com + + + Tomek Mrugalski + Internet Systems Consortium, Inc. + PO Box 360 + Newmarket, NH 03857 + United States of America + Email: tomasz.mrugalski@gmail.com |