< draft-andrews-dnsext-udp-fragmentation-00.txt		draft-andrews-dnsext-udp-fragmentation-01.txt >
	Network Working Group M. Andrews		Network Working Group M. Andrews
	Internet-Draft ISC		Internet-Draft ISC
	Intended status: Standards Track December 13, 2011		Intended status: Standards Track January 22, 2012
	Expires: June 15, 2012		Expires: July 25, 2012
	DNS and UDP Fragmentation		DNS and UDP Fragmentation
	draft-andrews-dnsext-udp-fragmentation-00.txt		draft-andrews-dnsext-udp-fragmentation-01.txt
	Abstract		Abstract
	This document provides advice to DNS developers about sending DNS UDP		This document provides advice to DNS developers about sending DNS UDP
	messages and Path MTU Discovery.		messages and Path MTU Discovery.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	skipping to change at page 1, line 31 ¶		skipping to change at page 1, line 31 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on June 15, 2012.		This Internet-Draft will expire on July 25, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 10 ¶		skipping to change at page 3, line 10 ¶
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
	5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4		5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
	6. Normative References . . . . . . . . . . . . . . . . . . . . . 4		6. Normative References . . . . . . . . . . . . . . . . . . . . . 4
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1. Background		1. Background
	IPv6 has changed the dynamics of UDP, Path MTU Discovery (PMTUD) and		IPv6 has changed the dynamics of UDP, Path MTU Discovery (PMTUD) and
	IP fragmentation. With IPv4 DNS/UDP packets were fragmented by the		IP fragmentation. With IPv4 DNS/UDP packets were fragmented by the
	network and no PMTUD was performed. With IPv6 fragmentation occurs		network and no PMTUD was performed. With IPv6 fragmentation occurs
	in the sending node and PMTUD is alway performed unless the IPv6		in the sending node and PMTUD is allways performed unless the IPv6
	packet is fragmented by the sending node using the network MTU.		packet is fragmented by the sending node using the minimum IPv6 MTU.
	DNS/UDP does not work well when PMTUD discover is performed. If the		DNS/UDP does not work well when PMTUD is performed. If the Packet
	Packet Too Big (PTB) / Need Fragmentation ICMP messages are not		Too Big (PTB) / Need Fragmentation ICMP messages are not received
	received there is no feedback path in DNS to reduce the size of the		there is no feedback path in DNS to reduce the size of the fragments
	fragments like there is with TCP.		like there is with TCP.
	Additionally there is no automatic retransmission of UDP packets like		Additionally there is no automatic retransmission of UDP packets like
	there is with TCP in response to a PTB message. The sender needs to		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,		send the request after timing out. Not only is this process slow,
	the resulting traffic patterns can be confused with other common		the resulting traffic patterns can be confused with other common
	sources of error, resulting from badly configured firewalls, leading		sources of error, resulting from badly configured firewalls, leading
	to inappropriate remedial action being taken.		to inappropriate remedial action being taken.
	This document recommends that all DNS/UDP messages are sent such that		This document recommends that all DNS/UDP messages are sent such that
	they do not trigger PMTUD.		they do not trigger PMTUD.
	skipping to change at page 3, line 48 ¶		skipping to change at page 3, line 48 ¶
	is necessary for the application to disable PMTUD on a per socket/		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		packet basis or for the operator to disable it globally if there is
	no per socket/packet control.		no per socket/packet control.
	3. IPv6 and Fragmentation		3. IPv6 and Fragmentation
	It was realised that IPv6 changed the way PMTUD happened and that		It was realised that IPv6 changed the way PMTUD happened and that
	there were applications, like DNS, that would not work well with		there were applications, like DNS, that would not work well with
	PMTUD. For those applications a socket option called		PMTUD. For those applications a socket option called
	IPV6_USE_MIN_MTU was developed [RFC 3542] which tells the IPv6 stack		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		to fragment packets at the minimum IPv6 MTU rather than use PMTUD to
	the actual PMTU.		find the actual PMTU.
	It is RECOMMENDED that IPV6_USE_MIN_MTU be set to 1 (one) when		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		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.		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		If the IPv6 stack does not support IPV6_USE_MIN_MTU, then steps
	should be taken to prevent PMTUD occuring. These include, but are		should be taken to prevent PMTUD occuring. These include, but are
	not limited to, setting the interface the packets are being sent over		not limited to, setting the MTU of the interface the packets are
	should be set to the network MTU (1280 bytes), or restricing DNS/UDP		being sent over to the minimum IPv6 MTU (1280 bytes), or restricing
	packets to no more than 1280 bytes including IPv6 headers.		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		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		PTB message may still be received [RFC 2460] which requires a IPv6 to
	add a Fragmentation header to subsequent packets. There is currently		add a Fragmentation header to subsequent packets. There is currently
	no way to avoid this, without using raw sockets, as there is no way		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		for a application to request that a Fragmentation header be added to
	a packet.		a packet. [I-D.draft-andrews-6man-force-fragmentation] however has
			some proposed methods.
	4. IANA Considerations		4. IANA Considerations
	No IANA Considerations.		No IANA Considerations.
	5. Security Considerations		5. Security Considerations
	Failure to prevent PMTUD can lead to denial of service for DNS		Failure to prevent PMTUD can lead to denial of service for DNS
	clients.		clients.
	Firewalls are often configured to block fragmented IP packets as		Firewalls are often configured to block fragmented IP packets as
	early IP stacks had fragmentation re-assembly bugs. These bugs were		early IP stacks had fragmentation re-assembly bugs. These bugs were
	exploited to perform a number of denial of service and other attacks		exploited to perform a number of denial of service and other attacks
	cira 1999.		cira 1999.
	Such blocks should be relaxed to permit fragmented UDP packets.		Such blocks should be relaxed to permit fragmented UDP packets.
	6. Normative References		6. Normative References
			[I-D.draft-andrews-6man-force-fragmentation]
			Andrews, M., "Forcing Fragmentation of IPv6 Packets",
			draft-andrews-6man-force-fragmentation-01 (work in
			progress), January 2012.
	[RFC 1191]		[RFC 1191]
	Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,		Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
	November 1990.		November 1990.
	[RFC 2119]		[RFC 2119]
	Bradner, S., "Key words for use in RFCs to Indicate		Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC 2460]		[RFC 2460]
	Deering, S. and R. Hinden, "Internet Protocol, Version 6		Deering, S. and R. Hinden, "Internet Protocol, Version 6
End of changes. 10 change blocks.
	17 lines changed or deleted		23 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/