Internet Draft Jim Reid Expiration Date: April 2003 Nominum Suzanne Woolf Internet Software Consortium October 26 2002 Indicating Resolver Support for AAAA Records draft-reid-ipv6ok-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC-2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract In order to simplify the deployment of AAAA records in the DNS, name servers should only perform automatic inclusion of these RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and describes the necessary protocol changes to implement that notification. 3. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 4. Introduction This document updates RFC 1886 by adding new requirements. The intention is to extend the protocol to include AAAA records in the new requirements set out by RFC 3225 for DNSSEC and in RFC 3226 for DNSSEC and A6. AAAA records [RFC1886] have been defined to represent IPv6 addresses in the DNS. As IPv6 is deployed, it is likely that clients that are not IPv6-aware will query name servers that serve AAAA records. These responses may have an adverse operational impact on DNS infrastructure, notably excessive truncated responses and thus high rates of TCP-based query retries. This document discusses a method to avoid these negative impacts, namely IPv6-aware servers should only respond with AAAA RRs when there is an explicit indication from the resolver that it can understand those RRs. For the purposes of this document, "IPv6 RRs" are considered RRs of type AAAA. 5. Rationale Initially, as IPv6 is deployed and zones populated with IPv6 RRs the vast majority of queries will be from resolvers that are not IPv6 aware and therefore may not understand or support those RRs. As DNS UDP datagrams are limited to 512 bytes [RFC1035], responses including IPv6 RRs have a high probability of resulting in a truncated response being returned and the resolver retrying the query using TCP. TCP DNS queries result in significant overhead due to connection setup and teardown. Operationally, the impact of these TCP queries will likely be quite detrimental in terms of increased network traffic (typically five packets for a single query/response instead of two), increased latency resulting from the additional round trip times, increased incidences of queries failing due to timeouts, and significantly increased load on nameservers. Busy name servers may suffer performance problems from keeping state information about large numbers of short-lived TCP connections from these retries. Given these operational implications, explicitly notifying the nameserver that the client is prepared to receive (if not understand) IPv6 RRs would be prudent. Client-side support of IPv6 RRs is assumed to be binary -- either the client is willing to receive all IPv6 RRs or it is not willing to accept any. As such, a single bit is sufficient to indicate client-side support for IPv6 RRs. As effective use of IPv6 implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS enhanced DNS header) are scarce, and there may be situations in which non-compliant caching or forwarding servers inappropriately copy data from classic headers as queries are passed on to authoritative servers, the use of a bit from the EDNS0 header is proposed. An alternative approach would be to use the existence of an EDNS0 header as an implicit indication of client-side support of IPv6. This approach was not chosen as there may be applications in which EDNS0 is supported but in which the use of IPv6 is inappropriate. 6. Protocol Changes The mechanism chosen for the explicit notification of the ability of the client to accept (if not understand) IPv6 RRs is using the second most significant bit of the Z field on the EDNS0 OPT header in the query. This bit is referred to as the "IPv6 OK" (IO) bit. The most significant bit in the Z field is already assigned to indicate client DNSSEC capabilities [RFC3225]. In the context of the EDNS0 OPT meta-RR, the IO bit is the second bit of the third and fourth bytes of the "extended RCODE and flags" portion of the EDNS0 OPT meta-RR, structured as follows: +0 (MSB) +1 (LSB) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0: | EXTENDED-RCODE | VERSION | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2: | |IO| Z | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Setting the IO bit to one in a query indicates to the server that the resolver is able to accept IPv6 RRs. The DO bit cleared (set to zero) indicates the resolver is unprepared to handle IPv6 RRs and those RRs MUST NOT be returned in the response unless those RRs are explicitly queried for. The IO bit of the query MUST be copied in the response. More explicitly, IPv6-aware nameservers MUST NOT insert AAAA RRs in a response unless the IO bit was set on the request. IPv6 records that match an explicit AAAA, or are part of the zone data for an AXFR or IXFR query, are included whether or not the IO bit was set. A recursive IPv6-aware server MUST set the IO bit on recursive requests, regardless of the status of the IO bit on the initiating resolver request. If the initiating resolver request does not have the IO bit set, the recursive IPv6-aware server MUST remove IPv6 RRs before returning the data to the client, however cached data MUST NOT be modified. In the event a server returns a NOTIMP, FORMERR or SERVFAIL response to a query that has the IO bit set, the resolver SHOULD NOT expect IPv6 RRs and SHOULD retry the query without EDNS0. Operational Considerations This proposal is based on the assumption that both IPv6-aware resolvers and EDNS0 will eventually become default behavior, but that today's default is non-IPv6 aware resolvers and non-EDNS0 capable servers. It is an effort to avoid forcing a TCP-retry in what is currently the most common case for AAAA data-- that a non-EDNS0 resolver is probably, unable to use AAAA records, but not necessarily-- without imposing too much of a burden in the case we expect will eventually become the default. Its usefulness is somewhat dependent, then, on the assumption that EDNS0 and IPv6 will deploy roughly in parallel, but not perfectly, so we want to optimize for that case without precluding other behavior when that expectation does not apply. Security Considerations The absence of IPv6 data in response to a query with the IO bit set MUST NOT be taken to mean no IPv6 information is available for that zone as the response may be forged or a non-forged response of an altered (IO bit cleared) query. IANA Considerations EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record, these bits are encoded into the TTL field of the OPT record (RFC2671 section 4.6). This document reserves one of these bits as the OK bit. It is requested that the second most significant bit be allocated. Thus the USE of the OPT record TTL field would look like +0 (MSB) +1 (LSB) +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 0: | EXTENDED-RCODE | VERSION | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 2: | |IO| Z | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ Acknowledgements Several people have been involved in the discussions leading up to this draft, particularly Paul Vixie, Jinmei Tatuya, and Michael Graff. References [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987. [RFC1886] Thompson, S. and Huitema, C., "DNS Extensions to support IP version 6", RFC1886, December 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225, December 2001.