]> Akamai Technologies

erik+ietf@nygren.org

General DNSOP Internet-Draft As the DNS is the primary mechanism for translating from hostnames to IP addresses, it is a logical place to signal that endpoints are IPv6-only. It is thus also a logical place to signal that legacy endpoints supporting IPv4 are being deprecated. This specification introduces two SvcParams for SVCB-compatible RR types that signal IPv6-only endpoints (ipv6only) as well as deprecated endpoints (deprecated). TO BE REMOVED: This document is being collaborated on in Github at: https://github.com/enygren/draft-nygren-dnsop-ipv6only-indicator. The most recent working version of the document, open issues, etc. should all be available there. The authors (gratefully) accept pull requests.

Introduction This specification introduces the ipv6only and deprecated SvcParamKeys to allow service providers to indicate that preferred Service Endpoints are IPv6-only and that legacy IPv4-supporting Service Endpoints are deprecated and will be retired. As part of the multi-decade transition from IPv4 to IPv6 () there is a desire to phase out support for providing services over IPv4. This involves switching from the long-standing assumption that all services are available over IPv4 or dual-stack IPv4+IPv6 to instead being only available over IPv6. As clients lacking IPv6 connectivity will not be able to access IPv6-only resources, there will be a transitional phase where service providers will want to indicate that legacy endpoints supporting IPv4 are deprecated and will go away at some point. For example, the government of Czechia has set an end-date after which government services may only be provided over IPv6 . Leading up to this, there will be a need to signal that the IPv6-only services are preferred and that legacy IPv4-supporting services are deprecated. In , the SVCB ("Service Binding") and HTTPS DNS RR types are specified to provide clients with complete instructions for accessing a service. Individual service bindings (SVCB RRs) describe Service Endpoints and their properties and relative priorities. By adding the ipv6only and deprecated SvcParamKeys, individual Service Endpoints can be annotated to indicate their IPv6-only and deprecated nature to clients. It is expected that the deprecated SvcParamKey may also be used for other future purposes. As an example, the following provides two Service Endpoints for www.example.com. The preferred endpoint of modern.example.com (the one with the lowest SvcPriority) is listed as ipv6only. An additional Service Endpoint of legacy.example.com is also available but is listed as deprecated. The optional use of mandatory=ipv6only will cause clients not understanding the new ipv6only SvcParamKey to ignore the modern IPv6-only endpoint and skip directly to the legacy endpoint.

Conventions and Definitions 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. Terminology used in this specification includes:

• Service Endpoint: a ServiceMode SVCB (or SVCB-compatible) DNS RR () that specifies how to access a service. This corresponds to an "alternative endpoint" in .

Additional DNS terminology intends to be consistent with .

The "ipv6only" SvcParamKey The ipv6only SvcParamKey indicates that the associated Service Endpoint is only available over IPv6. It takes no value. With ipv6only, the presentation and wire format values MUST be empty. The ipv6only and ipv4hint SvcParamKeys SHOULD NOT be included in the same SVCB RR. When ipv6only is present, the ipv4hint SvcParam MUST be ignored by clients.

Client behavior for "ipv6only" Clients implementing the ipv6only SvcParamKey do the following when encountering a SVCB RR with this SvcParam, as a modification to the algorithm specified in Section 3:

1. Clients SHOULD NOT perform an A DNS lookup for an IPv4 address for the TargetName. (It is possible that clients already performed the A lookup or have one in their DNS cache, in which case it MUST be ignored.)
2. Clients MUST only attempt to connect to the Service Endpoint over IPv6 and MUST NOT attempt to connect to the Service Endpoint over IPv4.
3. Clients who are certain that they have no IPv6 connectivity SHOULD treat this Service Endpoint as not "compatible" ( Section 8) and not include it in their candidate list.

If the only Service Endpoints available have ipv6only, and if the service has no DNS A record, the Client MAY present the user with a notice that the service is only available over IPv6 and that the user lacks IPv6 connectivity. (TODO: determine if "updates: 9460" is needed.)

Clients using a Proxy Clients using a domain-oriented transport proxy like HTTP CONNECT () or SOCKS5 () with named destinations may not know if their proxy supports IPv6 or only IPv4. Clients lacking information about whether a Proxy supports IPv6 SHOULD opportunistically use Service Endpoints with ipv6only, but MUST retry with subsequent Service Endpoints if this fails. Clients MAY use the Proxy-Status response header field to get an indication that a proxy is unable to reach a given target over IPv6 (such as looking for regular occurrences of error=destination_ip_unroutable) but MUST NOT extrapolate this to general IPv6 unreachability from the Proxy absent some other explicit signal.

The "deprecated" SvcParamKey The deprecated SvcParamKey indicates that the associated Service Endpoint is deprecated. It takes an optional value with a freeform textual deprecation reason. This text is NOT intended for automated processing, and clients MUST NOT alter their connection behavior on the basis of its content beyond treating the mere presence of the "deprecated" key as advisory. The deprecated SvcParam SHOULD always be on the lowest priority Service Endpoints.

Presentation Format for "deprecated" The presentation value of "deprecated" is OPTIONAL. When present, it follows the generic SvcParamValue presentation format defined in . If no value is given, the key appears with no reason text, e.g.: If a reason is given:

Wire Format for "deprecated" In wire format, the SvcParamValue for "deprecated" consists of the UTF-8 encoding of the freeform reason text, with no internal length, count, or type octets. If no reason text is present, the SvcParamValue is zero-length: the SvcParamKey appears with a SvcParamValue length of 0, per the general wire format described in . Implementations MUST NOT assume any particular character encoding beyond UTF-8, MUST NOT parse the value for embedded structure, and SHOULD treat malformed UTF-8 by ignoring the value while still honoring the mere presence of the key as an indication of deprecation.

Client behavior for "deprecated" The deprecated indicator is intended for operational uses and is not intended to substantively impact general end-user behavior. Clients SHOULD NOT provide special treatment to Service Endpoints due to the presence of deprecated. Clients MAY provide an indicator and SHOULD log a warning when using a Service Endpoint with deprecated.

Example usage of "deprecated" outside of IPv4 deprecation The deprecated SvcParamKey is generally usable outside of just the IPv4 deprecation context. For example it could be used to indicate that the default ALPN of http/1.1 is deprecated and that only alpn=h2,h3 will be supported going forwards:

Operational Usage for IPv4 Deprecation A typical operational workflow for using this will involve moving through a deprecation process of: 1) Introducing both the ipv6only Service Endpoint and marking the legacy Service Endpoint as deprecated. 2) Removing the deprecated endpoint, leaving only the ipv6only Service Endpoint.

Step One: Indicating Deprecation In the first step, the service is configured with at least two ServiceMode Service Endpoints:

• The higher priority Service Endpoint (lesser numeric SvcPriority) MUST have ipv6only and mandatory=ipv6only SvcParams. Its TargetName MUST only have DNS AAAA records and no DNS A records. By marking the highest priority Service Endpoint with ipv6only as mandatory=ipv6only we cause clients who do not understand the ipv6only SvcParamKey to ignore that ServiceMode record and move on to the next one.
• The lower priority Service Endpoint (greater numeric SvcPriority) SHOULD have a deprecated SvcParam with an optional description. Its TargetName MUST be dual-stacked with both DNS AAAA records and A records.
• The fallback hostname MUST be dual-stacked with both DNS AAAA records and A records.

For example: The www.example.com endpoint remains as dual-stacked with A and AAAA records for clients not understanding the ipv6only SvcParamKey.

Step Two: Removing Deprecated Service Endpoint In the second step we remove the dual-stack Service Endpoint (and also make the fallback name IPv6-only):

• The remaining Service Endpoint MUST have an ipv6only SvcParam. It MUST NOT have the mandatory=ipv6only SvcParam, as this would cause clients not implementing the ipv6only SvcParam to have a Service Endpoint to use, even if they support IPv6. Its TargetName MUST only have DNS AAAA records and no DNS A records.
• The fallback hostname MUST be IPv6-only with only DNS AAAA records and no A records.

For example, to complete deprecation we remove the deprecated Service Endpoint: At this point the service no longer has any IPv4 support.

Security Considerations Communications in the DNS are subject to inspection and modification unless DNSSEC and secure communication from the client to DNS resolver is used ( Section 12). As discussed in Section 12 this could force the usage of a less secure Service Endpoint (such as one that is deprecated). Service operators SHOULD consider the security implications of continuing to run deprecated services, especially when these might increase their vulnerability footprint. How this impacts this specification depends on the threat model for the environment, but for the ipv6only SvcParam an attacker who can exploit this could also likely block individual IPv4 or IPv6 flows and force fallback without this specification. The free-form text provided with deprecated should be assumed to be coming from a hostile source. Clients MUST NOT present it to users in a way that it could lead to confusion or be used for phishing or other attacks. Any logging of this provided text MUST assume that it contains potential cross-site-scripting or prompt injection or other malicious content and must escape and annotate it accordingly.

Privacy Considerations Service operators should take into consideration that all information included as freeform text for deprecated is publicly available and thus should take care to not include sensitive or proprietary information. The presence of ipv6only influences client behavior so its presence adds an additional bit that could help fingerprint clients.

IANA Considerations

Updates to IANA SvcParam Registry The "Service Binding (SVCB) Parameter Registry" () shall have the following SvcParam Keys added:

Number	Name	Meaning	Reference	Change Controller
TBA	ipv6only	The endpoint is only available over IPv6	(This document)	IETF
TBA	deprecated	The endpoint is deprecated and may go away soon	(This document)	IETF

(TO BE REMOVED but potential considerations for assignment: * A cute assignment for ipv6only might be "864", with the meaning of "getting rid of IPv4 due to running out". * Similarly, "86" might be a memorable assignment for "deprecated"?)

References Normative References This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. This document specifies the "SVCB" ("Service Binding") and "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics"). By providing more information to the client before it attempts to establish a connection, these records offer potential benefits to both performance and privacy. 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. 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. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This memo describes a protocol that is an evolution of the previous version of the protocol, version 4 [1]. This new protocol stems from active discussions and prototype implementations. [STANDARDS-TRACK] ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279. Informative References IANA CZ.NIC This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. This document defines the Proxy-Status HTTP response field to convey the details of an intermediary's response handling, including generated errors.

Acknowledgments Thank you to ... for their feedback and suggestions on this draft. Some of the initial thoughts around this go back to the IETF sunset4 working group, so additional thanks go to people who participated in that work, as well as to others working towards the eventual universal deprecation of IPv4.

Change history (This section to be removed by the RFC editor.)