]> OpenBSD

florian+ietf@narrans.de

This document specifies a DNS Resolver Information Key to inform DNS clients of the presence of DNS64.

Introduction DNS64 performed by a DNS resolver together with NAT64 allows an IPv6-only client to initiate communications by name to an IPv4-only server. specifies a DNS resource record (RR) type RESINFO to allow resolvers to publish information about their capabilities and policies. This can be used to inform DNS clients that DNS64 is performed by the DNS resolver.

Requirements Notation 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.

Relation to RFC 7050 describes a heuristic to learn the IPv6 prefix used by a NAT64 gateway. Nodes can use this information to perform local address synthesis, for example when using 464XLAT as a transition mechanism. This has security implications, making difficult to deploy. A modern mechanism, like PREF64 is easier to deploy, leading to a desire to deprecate entirely. Using the RESINFO mechanism solely to inform clients about the presence of DNS64 without conveying any prefix information avoids the security problems of .

dns64 Resolver Information Key

dns64:

The presence of this key indicates that the DNS resolver performs address synthesis. A resolver which supports SHOULD add the dns64 key if it performs DNS64 address synthesis. Note that, per the rules for the keys defined in Section 6.4 of , if there is no '=' in a key, then it is a boolean attribute, simply identified as being present, with no value.

Security Considerations The security considerations of apply.

IANA Considerations The IANA is requested to add the key "dns64", with the description of "The presence of the key indicates that DNS64 address synthesis is performed", and a reference to this document. Name Description Reference dns64 The presence of the key indicates that DNS64 address synthesis is performed. RFC EDITOR: THIS DOCUMENT

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. This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD. 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. This document specifies a method for DNS resolvers to publish information about themselves. DNS clients can use the resolver information to identify the capabilities of DNS resolvers. How DNS clients use such information is beyond the scope of this document. DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators. [STANDARDS-TRACK] This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. This document specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate prefixes of Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) to hosts.