A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://www.rfc-editor.org/rfc/rfc9527.xml below:

Introduction 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 . 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 . 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. 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 when, and only when, they appear in all capitals, as shown here. The reader should be familiar with . 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 , this section assumes that the HNA and the home network DHCPv6 client are colocated on the Customer Premises Equipment (CPE) router . 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 . 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 ) of ) by the DM and the RDM. The HNA builds the Homenet Zone (or the Homenet Reverse Zone) and proceeds as described in . The DHCPv6 options provide the necessary non-optional parameters described in Appendix B of . The HNA may complement the configurations with additional parameters via means not yet defined. Appendix B of describes such parameters that may take some specific non-default value.
DHCPv6 Options This section details the payload of the DHCPv6 options following the guidelines of . Registered Homenet Domain Option The Registered Domain Option (OPTION_REGISTERED_DOMAIN) indicates the fully qualified domain name (FQDN) associated with the home network. Registered Domain Option 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 / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 .
Registered Homenet Domain (variable):
The FQDN registered for the homenet encoded as described in .
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. Forward Distribution Manager Option 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 / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 .
Supported Transport (16 bits):
Defines the Supported Transport by the DM (see ). 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 .
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 and DNS Zone Transfer over TLS . 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. 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. Reverse Distribution Manager Option 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 / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 .
Supported Transport (16 bits):
Defines the Supported Transport by the RDM (see ). Each bit represents a supported transport, and an RDM MAY indicate the support of multiple modes. The bit for DomTLS MUST be set.
Reverse Distribution Manager FQDN (variable):
The FQDN of the RDM encoded as described in .
For the port number associated to the Supported Transport, the same considerations as described in apply. 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 .
DNS over mutually authenticated TLS (DomTLS):
Indicates the support of DNS over TLS and DNS Zone Transfer over TLS as described in .
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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DHCPv6 Behavior DHCPv6 Server Behavior 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. 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 and of . Upon receiving a DHCPv6 option, as described in this document, in the Reply message, the HNA SHOULD proceed as described in . DHCPv6 Relay Agent Behavior There are no additional requirements for the DHCPv6 Relay agents. IANA Considerations DHCPv6 Option Codes IANA has assigned the following new DHCPv6 Option Codes in the "Option Codes" registry maintained at . Option Codes Registry Value Description Client ORO Singleton Option Reference 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 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 . 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 ( ). 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 . 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 . The initial registry is as specified in below. Supported Transport Registry Bit Position (least to most significant) Transport Protocol Description Mnemonic Reference 0 DNS over mutually authenticated TLS DomTLS RFC 9527 1-15 Unassigned Security Considerations The security considerations in 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. References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Specification for DNS over Transport Layer Security (TLS) This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) This document describes the Dynamic Host Configuration Protocol for IPv6 (DHCPv6): an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly, or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document updates the text from RFC 3315 (the original DHCPv6 specification) and incorporates prefix delegation (RFC 3633), stateless DHCPv6 (RFC 3736), an option to specify an upper bound for how long a client should wait before refreshing information (RFC 4242), a mechanism for throttling DHCPv6 clients when DHCPv6 service is not available (RFC 7083), and relay agent handling of unknown messages (RFC 7283). In addition, this document clarifies the interactions between models of operation (RFC 7550). As such, this document obsoletes RFC 3315, RFC 3633, RFC 3736, RFC 4242, RFC 7083, RFC 7283, and RFC 7550. DNS Zone Transfer over TLS DNS zone transfers are transmitted in cleartext, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies the use of TLS, rather than cleartext, to prevent zone content collection via passive monitoring of zone transfers: XFR over TLS (XoT). Additionally, this specification updates RFC 1995 and RFC 5936 with respect to efficient use of TCP connections and RFC 7766 with respect to the recommended number of connections between a client and server for each transport. Simple Provisioning of Public Names for Residential Networks Informative References CNAME+DNAME Name Redirection Internet Systems Consortium This document updates RFC1034 to allow coexistence of the CNAME Resource Record with DNAME Resource Record at the same owner node, which provides redirection for a sub-tree of the domain name tree in the DNS system, in a parent zone. By allowing this cooexistence, DNS system will have a way how to create a sub-tree redirection together that includes the Resource Records owner name. This would allow parent zones to create full domain aliases. Work in Progress Automated Delegation of IP6.ARPA reverse zones with Prefix Delegation ISC Work in Progress Domain names - concepts and facilities This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. Clarifications to the DNS Specification This document considers some areas that have been identified as problems with the specification of the Domain Name System, and proposes remedies for the defects identified. [STANDARDS-TRACK] DNAME Redirection in the DNS The DNAME record provides redirection for a subtree of the domain name tree in the DNS. That is, all names that end with a particular suffix are redirected to another part of the DNS. This document obsoletes the original specification in RFC 2672 as well as updates the document on representing IPv6 addresses in DNS (RFC 3363). [STANDARDS-TRACK] Guidelines for Creating New DHCPv6 Options This document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software. It also provides guidelines for expert reviewers to evaluate new registrations. This document updates RFC 3315. IPv6 Home Networking Architecture Principles This text describes evolving networking technology within residential home networks with increasing numbers of devices and a trend towards increased internal routing. The goal of this document is to define a general architecture for IPv6-based home networking, describing the associated principles, considerations, and requirements. The text briefly highlights specific implications of the introduction of IPv6 for home networking, discusses the elements of the architecture, and suggests how standard IPv6 mechanisms and addressing can be employed in home networking. The architecture describes the need for specific protocol extensions for certain additional functionality. It is assumed that the IPv6 home network is not actively managed and runs as an IPv6-only or dual-stack network. There are no recommendations in this text for the IPv4 part of the network. 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. Base Scenario The base scenario, as described in , 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. 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 , DNAME , or CNAME+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 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 . 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. 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 , such settings could be performed in an almost automatic way as to limit the necessary interactions with the end user.
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 . 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 and . With the configuration described in , 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 , 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 and require the HNA to handle multiple Registered Homenet Domains, whereas does not have such a requirement. Acknowledgments We would like to thank , , and for their comments on the design of the DHCPv6 options. We would also like to thank , , and for their remarks on the architecture design. The designed solution has been largely inspired by document as well as discussions with . We also thank and for their reviews and comments and for suggesting appropriate terminology. Contributors The coauthors would like to thank and for providing significant contributions to the early draft versions of this document. Authors' Addresses Ericsson 8275 Trans Canada Route Saint Laurent QC 4S 0B6 Canada daniel.migault@ericsson.com Akamai ralf.weber@akamai.com Internet Systems Consortium, Inc. PO Box 360 Newmarket NH 03857 United States of America tomasz.mrugalski@gmail.com

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4