idnits 2.17.1 draft-andrews-dnsext-udp-fragmentation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 22, 2012) is 4468 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'I-D.draft-andrews-6man-force-fragmentation' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Andrews 3 Internet-Draft ISC 4 Intended status: Standards Track January 22, 2012 5 Expires: July 25, 2012 7 DNS and UDP Fragmentation 8 draft-andrews-dnsext-udp-fragmentation-01.txt 10 Abstract 12 This document provides advice to DNS developers about sending DNS UDP 13 messages and Path MTU Discovery. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on July 25, 2012. 32 Copyright Notice 34 Copyright (c) 2012 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3 51 2. IPv4 and Fragmentation . . . . . . . . . . . . . . . . . . . . 3 52 3. IPv6 and Fragmentation . . . . . . . . . . . . . . . . . . . . 3 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 55 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 56 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 1. Background 60 IPv6 has changed the dynamics of UDP, Path MTU Discovery (PMTUD) and 61 IP fragmentation. With IPv4 DNS/UDP packets were fragmented by the 62 network and no PMTUD was performed. With IPv6 fragmentation occurs 63 in the sending node and PMTUD is allways performed unless the IPv6 64 packet is fragmented by the sending node using the minimum IPv6 MTU. 66 DNS/UDP does not work well when PMTUD is performed. If the Packet 67 Too Big (PTB) / Need Fragmentation ICMP messages are not received 68 there is no feedback path in DNS to reduce the size of the fragments 69 like there is with TCP. 71 Additionally there is no automatic retransmission of UDP packets like 72 there is with TCP in response to a PTB message. The sender needs to 73 send the request after timing out. Not only is this process slow, 74 the resulting traffic patterns can be confused with other common 75 sources of error, resulting from badly configured firewalls, leading 76 to inappropriate remedial action being taken. 78 This document recommends that all DNS/UDP messages are sent such that 79 they do not trigger PMTUD. 81 1.1. Reserved Words 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in [RFC 2119]. 87 2. IPv4 and Fragmentation 89 There are a number of IP stacks that enable PMTUD for all IP packets 90 by default against the advice of [RFC 1191]. On those IP stacks it 91 is necessary for the application to disable PMTUD on a per socket/ 92 packet basis or for the operator to disable it globally if there is 93 no per socket/packet control. 95 3. IPv6 and Fragmentation 97 It was realised that IPv6 changed the way PMTUD happened and that 98 there were applications, like DNS, that would not work well with 99 PMTUD. For those applications a socket option called 100 IPV6_USE_MIN_MTU was developed [RFC 3542] which tells the IPv6 stack 101 to fragment packets at the minimum IPv6 MTU rather than use PMTUD to 102 find the actual PMTU. 104 It is RECOMMENDED that IPV6_USE_MIN_MTU be set to 1 (one) when 105 sending DNS/UDP messages over IPv6. This option can be set at the 106 socket level or it can be set on a per UDP datagram basis. 108 If the IPv6 stack does not support IPV6_USE_MIN_MTU, then steps 109 should be taken to prevent PMTUD occuring. These include, but are 110 not limited to, setting the MTU of the interface the packets are 111 being sent over to the minimum IPv6 MTU (1280 bytes), or restricing 112 DNS/UDP packets to no more than 1280 bytes including IPv6 headers. 114 It should be noted that even with IPV6_USE_MIN_MTU set to one that a 115 PTB message may still be received [RFC 2460] which requires a IPv6 to 116 add a Fragmentation header to subsequent packets. There is currently 117 no way to avoid this, without using raw sockets, as there is no way 118 for a application to request that a Fragmentation header be added to 119 a packet. [I-D.draft-andrews-6man-force-fragmentation] however has 120 some proposed methods. 122 4. IANA Considerations 124 No IANA Considerations. 126 5. Security Considerations 128 Failure to prevent PMTUD can lead to denial of service for DNS 129 clients. 131 Firewalls are often configured to block fragmented IP packets as 132 early IP stacks had fragmentation re-assembly bugs. These bugs were 133 exploited to perform a number of denial of service and other attacks 134 cira 1999. 136 Such blocks should be relaxed to permit fragmented UDP packets. 138 6. Normative References 140 [I-D.draft-andrews-6man-force-fragmentation] 141 Andrews, M., "Forcing Fragmentation of IPv6 Packets", 142 draft-andrews-6man-force-fragmentation-01 (work in 143 progress), January 2012. 145 [RFC 1191] 146 Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, 147 November 1990. 149 [RFC 2119] 150 Bradner, S., "Key words for use in RFCs to Indicate 151 Requirement Levels", BCP 14, RFC 2119, March 1997. 153 [RFC 2460] 154 Deering, S. and R. Hinden, "Internet Protocol, Version 6 155 (IPv6) Specification", RFC 2460, December 1998. 157 [RFC 3542] 158 Stevens, W., Thomas, M., Normark, E., and T. Jinmei, 159 "Advanced Sockets Application Program Interface (API) for 160 IPv6", RFC 2003, May 2003. 162 Author's Address 164 Mark Andrews 165 Internet Systems Consortium 166 950 Charter Street 167 Redwood City, CA 94063 168 US 170 Email: marka@isc.org