< draft-ietf-tsvwg-sctp-udp-encaps-03.txt		draft-ietf-tsvwg-sctp-udp-encaps-04.txt >
	Network Working Group M. Tuexen		Network Working Group M. Tuexen
	Internet-Draft Muenster Univ. of Appl. Sciences		Internet-Draft Muenster Univ. of Appl. Sciences
	Intended status: Standards Track R. Stewart		Intended status: Standards Track R. Stewart
	Expires: September 12, 2012 Adara Networks		Expires: January 6, 2013 Adara Networks
	March 11, 2012		July 5, 2012
	UDP Encapsulation of SCTP Packets		UDP Encapsulation of SCTP Packets
	draft-ietf-tsvwg-sctp-udp-encaps-03.txt		draft-ietf-tsvwg-sctp-udp-encaps-04.txt
	Abstract		Abstract
	This document describes a simple method of encapsulating SCTP Packets		This document describes a simple method of encapsulating SCTP Packets
	into UDP packets and its limitations. This allows the usage of SCTP		into UDP packets and its limitations. This allows the usage of SCTP
	in networks with legacy NAT not supporting SCTP. It can also be used		in networks with legacy NAT not supporting SCTP. It can also be used
	to implement SCTP on hosts without directly accessing the IP-layer,		to implement SCTP on hosts without directly accessing the IP-layer,
	for example implementing it as part of the application without		for example implementing it as part of the application without
	requiring special privileges.		requiring special privileges.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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 September 12, 2012.		This Internet-Draft will expire on January 6, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	4.1. Architectural Considerations . . . . . . . . . . . . . . . 4		4.1. Architectural Considerations . . . . . . . . . . . . . . . 4
	4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 4		4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 4
	4.3. Encapsulation Procedure . . . . . . . . . . . . . . . . . 6		4.3. Encapsulation Procedure . . . . . . . . . . . . . . . . . 6
	4.4. Decapsulation Procedure . . . . . . . . . . . . . . . . . 6		4.4. Decapsulation Procedure . . . . . . . . . . . . . . . . . 6
	4.5. ICMP Considerations . . . . . . . . . . . . . . . . . . . 6		4.5. ICMP Considerations . . . . . . . . . . . . . . . . . . . 6
	4.6. Path MTU Considerations . . . . . . . . . . . . . . . . . 7		4.6. Path MTU Considerations . . . . . . . . . . . . . . . . . 7
	4.7. Handling of Embedded IP-addresses . . . . . . . . . . . . 7		4.7. Handling of Embedded IP-addresses . . . . . . . . . . . . 7
	4.8. ECN Considerations . . . . . . . . . . . . . . . . . . . . 7		4.8. ECN Considerations . . . . . . . . . . . . . . . . . . . . 7
	5. Socket API Considerations . . . . . . . . . . . . . . . . . . 7		5. Socket API Considerations . . . . . . . . . . . . . . . . . . 7
	5.1. Get or Set the Remote UDP Encapsulation Port Number		5.1. Get or Set the Remote UDP Encapsulation Port Number
	(SCTP_REMOTE_UDP_ENCAPS_PORT) . . . . . . . . . . . . . . 7		(SCTP_REMOTE_UDP_ENCAPS_PORT) . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 8		7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	9.2. Informative References . . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	This document describes a simple method of encapsulating SCTP packets		This document describes a simple method of encapsulating SCTP packets
	into UDP packets. SCTP as defined in [RFC4960] runs directly over		into UDP packets. SCTP as defined in [RFC4960] runs directly over
	IPv4 or IPv6. There are two main reasons for encapsulating SCTP		IPv4 or IPv6. There are two main reasons for encapsulating SCTP
	packets:		packets:
	skipping to change at page 6, line 15 ¶		skipping to change at page 6, line 15 ¶
	4.3. Encapsulation Procedure		4.3. Encapsulation Procedure
	When inserting the UDP header, the source port is the local UDP		When inserting the UDP header, the source port is the local UDP
	encapsulation port number of the SCTP stack, the destination port is		encapsulation port number of the SCTP stack, the destination port is
	the remote UDP encapsulation port number stored for the destination		the remote UDP encapsulation port number stored for the destination
	address the packet is sent to (see Section 4.1).		address the packet is sent to (see Section 4.1).
	The length of the UDP packet is the length of the SCTP packet plus		The length of the UDP packet is the length of the SCTP packet plus
	the size of the UDP header.		the size of the UDP header.
	The UDP checksum and the SCTP checksum MUST be computed.		The UDP checksum SHOULD be computed and the SCTP checksum MUST be
			computed.
	4.4. Decapsulation Procedure		4.4. Decapsulation Procedure
	When an encapsulated packet is received, the UDP header is removed.		When an encapsulated packet is received, the UDP header is removed.
	Then a lookup is performed to find the association the received SCTP		Then a lookup is performed to find the association the received SCTP
	packet belongs to. The UDP source port is stored as the		packet belongs to. The UDP source port is stored as the
	encapsulation port for the destination address the SCTP packet is		encapsulation port for the destination address the SCTP packet is
	received from (see Section 4.1).		received from (see Section 4.1).
	Please note that when a non-encapsulated SCTP packet is received, the		Please note that when a non-encapsulated SCTP packet is received, the
	skipping to change at page 7, line 17 ¶		skipping to change at page 7, line 17 ¶
	If an SCTP endpoint starts to encapsulate the packets of a path, it		If an SCTP endpoint starts to encapsulate the packets of a path, it
	MUST decrease the path MTU of that path by the size of the UDP		MUST decrease the path MTU of that path by the size of the UDP
	header. If it stops encapsulating them, the path MTU SHOULD be		header. If it stops encapsulating them, the path MTU SHOULD be
	increased by the size of the UDP header.		increased by the size of the UDP header.
	When performing path MTU discovery as described in [RFC4820] and		When performing path MTU discovery as described in [RFC4820] and
	[RFC4821] it MUST be taken into account that one cannot rely on the		[RFC4821] it MUST be taken into account that one cannot rely on the
	feedback provided by ICMP or ICMPv6 due to the limitation laid out in		feedback provided by ICMP or ICMPv6 due to the limitation laid out in
	Section 4.5.		Section 4.5.
			If the implementation does not allow to control the dont't fragment
			(DF)-bit contained in the IPv4 header, path MTU discovery can't be
			used. In this case, an implementation specific value should be used
			instead.
	4.7. Handling of Embedded IP-addresses		4.7. Handling of Embedded IP-addresses
	When using UDP encapsulation for legacy NAT traversal, IP addresses		When using UDP encapsulation for legacy NAT traversal, IP addresses
	that might require translation MUST NOT be put into any SCTP packet.		that might require translation MUST NOT be put into any SCTP packet.
	This means that a multi homed SCTP association is setup initially as		This means that a multi homed SCTP association is setup initially as
	a singled homed one and the protocol extension [RFC5061] in		a singled homed one and the protocol extension [RFC5061] in
	combination with [RFC4895] is used to add the other addresses. Only		combination with [RFC4895] is used to add the other addresses. Only
	wildcard addresses are put into the SCTP packet.		wildcard addresses are put into the SCTP packet.
	When addresses are changed during the lifetime of an association		When addresses are changed during the lifetime of an association
	[RFC5061] MUST be used with wildcard addresses only.		[RFC5061] MUST be used with wildcard addresses only.
	4.8. ECN Considerations		4.8. ECN Considerations
	During encapsulation and decapsulation the ECN bits MUST NOT be		If the implementation supports the sending and receiving of the ECN
	changed.		bits for the IP protocols being used by an SCTP association, the ECN
			bits MUST NOT be changed during encapsulation and decapsulation. In
			the other case, ECN MUST NOT be used for such an SCTP association.
	5. Socket API Considerations		5. Socket API Considerations
	This section describes how the socket API defined in [RFC6458] is		This section describes how the socket API defined in [RFC6458] is
	extended to provide a way for the application to control the UDP		extended to provide a way for the application to control the UDP
	encapsulation.		encapsulation.
	Please note that this section is informational only.		Please note that this section is informational only.
	A socket API implementation based on [RFC6458] is extended by		A socket API implementation based on [RFC6458] is extended by
	skipping to change at page 9, line 43 ¶		skipping to change at page 10, line 5 ¶
	9.2. Informative References		9.2. Informative References
	[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.		[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
	Yasevich, "Sockets API Extensions for the Stream Control		Yasevich, "Sockets API Extensions for the Stream Control
	Transmission Protocol (SCTP)", RFC 6458, December 2011.		Transmission Protocol (SCTP)", RFC 6458, December 2011.
	[I-D.ietf-behave-sctpnat]		[I-D.ietf-behave-sctpnat]
	Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control		Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control
	Transmission Protocol (SCTP) Network Address Translation",		Transmission Protocol (SCTP) Network Address Translation",
	draft-ietf-behave-sctpnat-05 (work in progress),		draft-ietf-behave-sctpnat-06 (work in progress),
	June 2011.		March 2012.
	[I-D.ietf-tsvwg-natsupp]		[I-D.ietf-tsvwg-natsupp]
	Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control		Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control
	Transmission Protocol (SCTP) Network Address Translation		Transmission Protocol (SCTP) Network Address Translation
	Support", draft-ietf-tsvwg-natsupp-01 (work in progress),		Support", draft-ietf-tsvwg-natsupp-02 (work in progress),
	June 2011.		March 2012.
	Authors' Addresses		Authors' Addresses
	Michael Tuexen		Michael Tuexen
	Muenster University of Applied Sciences		Muenster University of Applied Sciences
	Stegerwaldstrasse 39		Stegerwaldstrasse 39
	48565 Steinfurt		48565 Steinfurt
	DE		DE
	Email: tuexen@fh-muenster.de		Email: tuexen@fh-muenster.de
End of changes. 10 change blocks.
	14 lines changed or deleted		22 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/