Network Working Group M. Andrews Internet-Draft ISC Intended status: Standards Track December 13, 2011 Expires: June 15, 2012 DNS and UDP Fragmentation draft-andrews-dnsext-udp-fragmentation-00.txt Abstract This document provides advice to DNS developers about sending DNS UDP messages and Path MTU Discovery. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on June 15, 2012. Copyright Notice Copyright (c) 2011 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Andrews Expires June 15, 2012 [Page 1] Internet-Draft DNS and UDP Fragmentation December 2011 Table of Contents 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 2. IPv4 and Fragmentation . . . . . . . . . . . . . . . . . . . . 3 3. IPv6 and Fragmentation . . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Andrews Expires June 15, 2012 [Page 2] Internet-Draft DNS and UDP Fragmentation December 2011 1. Background IPv6 has changed the dynamics of UDP, Path MTU Discovery (PMTUD) and IP fragmentation. With IPv4 DNS/UDP packets were fragmented by the network and no PMTUD was performed. With IPv6 fragmentation occurs in the sending node and PMTUD is alway performed unless the IPv6 packet is fragmented by the sending node using the network MTU. DNS/UDP does not work well when PMTUD discover is performed. If the Packet Too Big (PTB) / Need Fragmentation ICMP messages are not received there is no feedback path in DNS to reduce the size of the fragments like there is with TCP. Additionally there is no automatic retransmission of UDP packets like there is with TCP in response to a PTB message. The sender needs to send the request after timing out. Not only is this process slow, the resulting traffic patterns can be confused with other common sources of error, resulting from badly configured firewalls, leading to inappropriate remedial action being taken. This document recommends that all DNS/UDP messages are sent such that they do not trigger PMTUD. 1.1. Reserved Words 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]. 2. IPv4 and Fragmentation There are a number of IP stacks that enable PMTUD for all IP packets by default against the advice of [RFC 1191]. On those IP stacks it is necessary for the application to disable PMTUD on a per socket/ packet basis or for the operator to disable it globally if there is no per socket/packet control. 3. IPv6 and Fragmentation It was realised that IPv6 changed the way PMTUD happened and that there were applications, like DNS, that would not work well with PMTUD. For those applications a socket option called IPV6_USE_MIN_MTU was developed [RFC 3542] which tells the IPv6 stack to fragment packets at the network MTU rather than use PMTUD to find the actual PMTU. Andrews Expires June 15, 2012 [Page 3] Internet-Draft DNS and UDP Fragmentation December 2011 It is RECOMMENDED that IPV6_USE_MIN_MTU be set to 1 (one) when sending DNS/UDP messages over IPv6. This option can be set at the socket level or it can be set on a per UDP datagram basis. If the IPv6 stack does not support IPV6_USE_MIN_MTU, then steps should be taken to prevent PMTUD occuring. These include, but are not limited to, setting the interface the packets are being sent over should be set to the network MTU (1280 bytes), or restricing DNS/UDP packets to no more than 1280 bytes including IPv6 headers. It should be noted that even with IPV6_USE_MIN_MTU set to one that a PTB message may still be received [RFC 2460] which requires a IPv6 to add a Fragmentation header to subsequent packets. There is currently no way to avoid this, without using raw sockets, as there is no way for a application to request that a Fragmentation header be added to a packet. 4. IANA Considerations No IANA Considerations. 5. Security Considerations Failure to prevent PMTUD can lead to denial of service for DNS clients. Firewalls are often configured to block fragmented IP packets as early IP stacks had fragmentation re-assembly bugs. These bugs were exploited to perform a number of denial of service and other attacks cira 1999. Such blocks should be relaxed to permit fragmented UDP packets. 6. Normative References [RFC 1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 Andrews Expires June 15, 2012 [Page 4] Internet-Draft DNS and UDP Fragmentation December 2011 (IPv6) Specification", RFC 2460, December 1998. [RFC 3542] Stevens, W., Thomas, M., Normark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 2003, May 2003. Author's Address Mark Andrews Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 US Email: marka@isc.org Andrews Expires June 15, 2012 [Page 5]