doc: Add RFC documents

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