< draft-andrews-6man-force-fragmentation-00.txt		draft-andrews-6man-force-fragmentation-01.txt >
	Network Working Group M. Andrews		Network Working Group M. Andrews
	Internet-Draft ISC		Internet-Draft ISC
	Updates: RFC 3542 December 13, 2011		Updates: RFC 3542 (if approved) January 22, 2012
	(if approved)
	Intended status: Informational		Intended status: Informational
	Expires: June 15, 2012		Expires: July 25, 2012
	Forcing Fragmentation of IPv6 Packets		Forcing Fragmentation of IPv6 Packets
	draft-andrews-6man-force-fragmentation-00		draft-andrews-6man-force-fragmentation-01
	Abstract		Abstract
	Extend The Advanced Sockets API for IPv6 (RFC 3542) to provide a		Extend The Advanced Sockets API for IPv6 (RFC 3542) to provide a
	mechanism to force a Fragment header to be added to a packet.		mechanism to force a Fragment header to be added to a packet.
	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 33 ¶		skipping to change at page 1, line 32 ¶
	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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . . 3
	2. Extend IPV6_USE_MIN_MTU . . . . . . . . . . . . . . . . . . . . 3		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Extend IPV6_DONTFRAG . . . . . . . . . . . . . . . . . . . . . 3		3. Extend IPV6_USE_MIN_MTU . . . . . . . . . . . . . . . . . . . . 4
	4. Add IPV6_DOFRAG . . . . . . . . . . . . . . . . . . . . . . . . 3		4. Extend IPV6_DONTFRAG . . . . . . . . . . . . . . . . . . . . . 4
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4		5. Add IPV6_DOFRAG . . . . . . . . . . . . . . . . . . . . . . . . 4
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
	7. Normative References . . . . . . . . . . . . . . . . . . . . . 4		7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4		8. Normative References . . . . . . . . . . . . . . . . . . . . . 5
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1. Background		1. Background
	In order to avoid PMTUD [RFC 1191] in IPv6 an application must not		In order to avoid Path MTU Discover (MTUD) [RFC 1191] in IPv6 an
	only force packets to be fragmented at the network MTU it must also		application must not only force packets to be fragmented at the
	force the addition of a Fragment header to unfragmented packets		minimum IPv6 MTU it must also force the addition of a Fragment header
	otherwise PTB ICMPv6 may be sent if the packet goes through a IPv6 to		to unfragmented packets otherwise PTB ICMPv6 may be sent if the
	IPv4 translating router [RFC 2460].		packet goes through a IPv6 to IPv4 translating router [RFC 2460].
	The Advanced Sockets API for IPv6 [RFC 3542] provides mechanisms to		The Advanced Sockets API for IPv6 [RFC 3542] provides mechanisms to
	force fragmentation of packet greater than the network MTU		force fragmentation of a packet greater than the minimum IPv6 MTU
	(IPV6_USE_MIN_MTU). It also provides mechanisms to prevent		(IPV6_USE_MIN_MTU). It also provides mechanisms to prevent
	fragmentation of a packet (IPV6_DONTFRAG). It however does not		fragmentation of a packet (IPV6_DONTFRAG). It however does not
	provide a mechanism to force a fragmentation header to be added.		provide a mechanism to force a fragmentation header to be added.
	This document intends to add such a mechanism.		This document intends to add such a mechanism.
	There appears to be 3 viable alternatives. 1) extend IPV6_USE_MIN_MTU		There appears to be 3 viable alternatives. 1) extend IPV6_USE_MIN_MTU
	to force the inclusion of a Fragment header. 2) extend IPV6_DONTFRAG		to force the inclusion of a Fragment header. 2) extend IPV6_DONTFRAG
	to signal that a Fragment header needs to be included. 3) add a new		to signal that a Fragment header needs to be included. 3) add a new
	socket option like IPV6_DOFRAG.		socket option like IPV6_DOFRAG.
			While there are multiple options available we should select exactly
			one.
	1.1. Reserved Words		1.1. Reserved Words
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC 2119].		document are to be interpreted as described in [RFC 2119].
	2. Extend IPV6_USE_MIN_MTU		2. Background
			Path MTU Discover assumes that the application / network stack will
			be in the position to retransmit the packet apon reception of a PTB
			ICMPv6 message. While this is true of TCP, there is class of
			protocols for which this is not true, like DNS/UDP. DNS/UDP is a
			stateless single packet exchange protocol. The client asks a query
			of the server and the server responds, usually with a bigger
			response, then immediately forgets the request. This works well for
			IPv4 where routers fragment the packets. For IPv6, however, it
			requires the client to timeout as the PTB message is usually being
			sent to the server which has no memory of the packet that triggered
			the PTB message. Setting IPV6_USE_MIN_MTU to 1 on the UDP socket
			reduces but does not remove the problem as the "minimum IPv6 MTU" of
			1280 is not a true minimum.
			[RFC 2460] permits PTB messages with values smaller than 1280 and
			requires the sending node to add a fragmentation header to subsequent
			packets. To avoid timeouts protocols, like DNS/UDP, need a way to
			force the addition of a fragment header to packets at or below the
			minimum IPv6 MTU.
			3. Extend IPV6_USE_MIN_MTU
			Currently IPV6_USE_MIN_MTU only requires a Fragmentation header to be
			added when the packet size is greater that 1280 byte, packets less
			that 1280 bytes are not required to have a Fragment header added.
			This change would result in a Fragmentation header also being added
			to packets that are 1280 bytes or less.
	If IPV6_USE_MIN_MTU is set to 1 then a Fragment header MUST be added		If IPV6_USE_MIN_MTU is set to 1 then a Fragment header MUST be added
	to both multicast and unicast packets.		to both multicast and unicast packets.
	If IPV6_USE_MIN_MTU is set to -1 then a Fragment header MUST be added		If IPV6_USE_MIN_MTU is set to -1 then a Fragment header MUST be added
	to multicast packets.		to multicast packets.
	3. Extend IPV6_DONTFRAG		Alternatively, one could use 2 and -2 to indicate the forced addition
			of a Fragment header in addition to limiting the MTU.
			4. Extend IPV6_DONTFRAG
	If IPV6_DONTFRAG is set to -1 (new value) then a Fragment header MUST		If IPV6_DONTFRAG is set to -1 (new value) then a Fragment header MUST
	be added to the packet.		be added to the packet.
	4. Add IPV6_DOFRAG		5. Add IPV6_DOFRAG
	This is similar to IPV6_USE_MIN_MTU in that it is a tri-state flag.		This is similar to IPV6_USE_MIN_MTU in that it is a tri-state flag.
	When set to -1 a Fragment header MUST be added to multicast packets.		When set to -1 a Fragment header MUST be added to multicast packets.
	When set to 1 a Fragment header MUST be added to both multicast and		When set to 1 a Fragment header MUST be added to both multicast and
	unicast packets. When set to 0 a Fragment header is only added if		unicast packets. When set to 0 a Fragment header is only added if
	fragmentation would otherwise happen.		fragmentation would otherwise happen.
	int on = 1;		int on = 1;
	setsockopt(fd, IPPROTO_IPV6, IPV6_DOFRAG, &on, sizeof(on));		setsockopt(fd, IPPROTO_IPV6, IPV6_DOFRAG, &on, sizeof(on));
	Setting IPV6_DONTFRAG to 1 will force IPV6_DOFRAG to 0.		Setting IPV6_DONTFRAG to 1 will force IPV6_DOFRAG to 0.
	Setting IPV6_DOFRAG to 1 or -1 will force IPV6_DONTFRAG to 0.		Setting IPV6_DOFRAG to 1 or -1 will force IPV6_DONTFRAG to 0.
	5. IANA Considerations		6. IANA Considerations
	No IANA Considerations.		No IANA Considerations.
	6. Security Considerations		7. Security Considerations
	TBA		TBA
	7. Normative References		8. Normative References
	[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]
End of changes. 16 change blocks.
	27 lines changed or deleted		61 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/