draft-ietf-tsvwg-sctp-udp-encaps-00.txt   draft-ietf-tsvwg-sctp-udp-encaps-01.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: January 26, 2012 Adara Networks Expires: May 1, 2012 Adara Networks
July 25, 2011 October 29, 2011
UDP Encapsulation of SCTP Packets UDP Encapsulation of SCTP Packets
draft-ietf-tsvwg-sctp-udp-encaps-00.txt draft-ietf-tsvwg-sctp-udp-encaps-01.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 January 26, 2012. This Internet-Draft will expire on May 1, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 23 skipping to change at page 2, line 23
3.2. Legacy NAT traversal . . . . . . . . . . . . . . . . . . . 4 3.2. Legacy NAT traversal . . . . . . . . . . . . . . . . . . . 4
4. SCTP over UDP . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. SCTP over UDP . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Architectural Considerations . . . . . . . . . . . . . . . 4 4.1. Architectural Considerations . . . . . . . . . . . . . . . 4
4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Encapsulation Procedure . . . . . . . . . . . . . . . . . . 5 4.3. Encapsulation Procedure . . . . . . . . . . . . . . . . . . 5
4.4. Decapsulation Procedure . . . . . . . . . . . . . . . . . . 5 4.4. Decapsulation Procedure . . . . . . . . . . . . . . . . . . 5
4.5. ICMP considerations . . . . . . . . . . . . . . . . . . . . 6 4.5. ICMP considerations . . . . . . . . . . . . . . . . . . . . 6
4.6. Path MTU considerations . . . . . . . . . . . . . . . . . . 6 4.6. Path MTU considerations . . . . . . . . . . . . . . . . . . 6
4.7. Handling of Embedded IP-addresses . . . . . . . . . . . . . 6 4.7. Handling of Embedded IP-addresses . . . . . . . . . . . . . 6
4.8. ECN considerations . . . . . . . . . . . . . . . . . . . . 6 4.8. ECN considerations . . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Socket API Considerations . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5.1. Get or Set the Remote UDP Encapsulation Port Number
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 (SCTP_REMOTE_UDP_ENCAPS_PORT) . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
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 is defined in [RFC4960]. There are two main into UDP packets. SCTP is defined in [RFC4960]. There are two main
reasons for this: reasons for this:
o Allow SCTP traffic to pass legacy NATs, which do not provide o Allow SCTP traffic to pass legacy NATs, which do not provide
native SCTP support as specified in [I-D.ietf-behave-sctpnat] and native SCTP support as specified in [I-D.ietf-behave-sctpnat] and
[I-D.ietf-tsvwg-natsupp]. [I-D.ietf-tsvwg-natsupp].
skipping to change at page 3, line 44 skipping to change at page 3, line 44
systems implementations are available, but require special privileges systems implementations are available, but require special privileges
to install and/or use them. In some cases no kernel implementation to install and/or use them. In some cases no kernel implementation
might be available at all. When proving an SCTP implementation as might be available at all. When proving an SCTP implementation as
part of a user process, most operating systems require special part of a user process, most operating systems require special
privileges to access the IP layer directly. privileges to access the IP layer directly.
Using UDP encapsulation makes it possible to provide an SCTP Using UDP encapsulation makes it possible to provide an SCTP
implementation as part of a user process which does not require any implementation as part of a user process which does not require any
special privileges. special privileges.
A crucial point for implementing SCTP in userland is controlling the A crucial point for implementing SCTP in user-land is controlling the
source address of outgoing packets. This is not an issue when using source address of outgoing packets. This is not an issue when using
all available addresses. However, this is not the case when also all available addresses. However, this is not the case when also
using the address management required for NAT traversal described in using the address management required for NAT traversal described in
Section 4.7. Section 4.7.
3.2. Legacy NAT traversal 3.2. Legacy NAT traversal
Using UDP encapsulation allows an SCTP communication traversing Using UDP encapsulation allows SCTP communication when traversing
legacy NATs not supporting SCTP as described in legacy NATs (i.e those NATs not supporting SCTP as described in
[I-D.ietf-behave-sctpnat] and [I-D.ietf-tsvwg-natsupp]. It is [I-D.ietf-behave-sctpnat] and [I-D.ietf-tsvwg-natsupp]). It is
important to realize that for single homed associations it is only important to realize that for single homed associations it is only
necessary that no IP addresses are listen in the INIT- and INIT-ACK necessary that no IP addresses are listed in the INIT and INIT-ACK
chunks. Dynamic address reconfiguration to change the single address chunks. To use multiple addresses, the dynamic address
has to make use of wildcard addresses as described in [RFC5061]. reconfiguration extension described in [RFC5061] must be used with
wildcard addresses in combination with [RFC4895].
For multi-homed SCTP association the address management as described For multi-homed SCTP association the address management as described
in Section 4.7 MUST be performed. in Section 4.7 MUST be performed.
4. SCTP over UDP 4. SCTP over UDP
4.1. Architectural Considerations 4.1. Architectural Considerations
An SCTP implementation supporting UDP encapsulation MUST store a UDP An SCTP implementation supporting UDP encapsulation MUST store a UDP
encapsulation port per destination address for each SCTP association. encapsulation port per destination address for each SCTP association.
4.2. Packet Format 4.2. Packet Format
To encapsulate an SCTP packet, a UDP header header as defined in To encapsulate an SCTP packet, a UDP header as defined in [RFC0768]
[RFC0768] is inserted between the IP header and the SCTP common is inserted between the IP header as defined in [RFC0791] and the
header. SCTP common header as defined in [RFC4960].
Figure 1 shows the packet format of an encapsulated SCTP packet when Figure 1 shows the packet format of an encapsulated SCTP packet when
IPv4 is used. IPv4 is used.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Header | | IPv4 Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header | | UDP Header |
skipping to change at page 5, line 5 skipping to change at page 5, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Chunk #1 | | SCTP Chunk #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Chunk #n | | SCTP Chunk #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
The packet format for an encapsulated SCTP packet when using IPv6 is The packet format for an encapsulated SCTP packet when using IPv6 as
shown in Figure 2. Please note the the number m of IPv6 extension defined in [RFC2460] is shown in Figure 2. Please note the the
headers can be 0. number m of IPv6 extension headers can be 0.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Base Header | | IPv6 Base Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Extension Header #1 | | IPv6 Extension Header #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 5, line 39 skipping to change at page 5, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Figure 2
The UDP checksum MUST NOT be zero. The UDP checksum MUST NOT be zero.
4.3. Encapsulation Procedure 4.3. Encapsulation Procedure
When inserting the UDP header, the source port is 9899, the When inserting the UDP header, the source port is 9899, the
destination port is the one stored for the destination address the destination port is the one stored for the destination address the
packet is sent to or 9899 if not destination address is stored. packet is sent to or 9899 if no destination address is stored.
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 checksum MUST be computed. The UDP checksum 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 of the SCTP destination address the received SCTP encapsulation port for the destination address the SCTP packet is
packet is sent from. received from (see Section 4.1).
Please note that when a non-encapsulated SCTP packet is received, the
encapsulation of outgoing packets belonging to the same association
and the corresponding destination address is disabled.
4.5. ICMP considerations 4.5. ICMP considerations
When receiving ICMP or ICMPv6 response packet, there might not be When receiving ICMP or ICMPv6 response packet, there might not be
enough bytes in the payload to identify the SCTP association which enough bytes in the payload to identify the SCTP association which
the SCTP packet triggering the ICMP or ICMPv6 packet belongs to. If the SCTP packet triggering the ICMP or ICMPv6 packet belongs to. If
a received ICMP or ICMPv6 packet can to be related to a specific SCTP a received ICMP or ICMPv6 packet can not be related to a specific
association, it MUST be discarded silently. SCTP association, it MUST be discarded silently.
4.6. Path MTU considerations 4.6. Path MTU considerations
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 an UDP header. MUST decrease the path MTU of that path by the size of the UDP
If it stops encapsulating them, the path MTU MUST be increased by the header. If it stops encapsulating them, the path MTU SHOULD be
size of an UDP header. increased by the size of the UDP header.
When performing path MTU discovery as described in [RFC4820] it MUST When performing path MTU discovery as described in [RFC4820] and
take into account that it cannot rely on the feedback provided by [RFC4821] it MUST be taken into account that one cannot rely on the
ICMP or ICMPv6 due to the limitation laid out in Section 4.5. feedback provided by ICMP or ICMPv6 due to the limitation laid out in
Section 4.5.
4.7. Handling of Embedded IP-addresses 4.7. Handling of Embedded IP-addresses
When using UDP encapsulation is used for legacy NAT traversal, IP When using UDP encapsulation for legacy NAT traversal, IP addresses
address that might be translated MUST NOT be put into any SCTP that might be translated MUST NOT be put into any SCTP packet.
packet.
This means that an SCTP association is setup singled homed and the This means that an SCTP association is setup singled homed and the
protocol extension [RFC5061] is used to add multiple address. Only protocol extension [RFC5061] in combination with [RFC4895] is used to
wildcard addresses are put into the SCTP packet. add other addresses. Only wildcard addresses are put into the SCTP
packet.
When addresses are changed during the lifetime of the 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
TBD During encapsulation and decapsulation the ECN bits MUST NOT be
changed.
5. IANA Considerations 5. Socket API Considerations
This section describes how the socket API defined in
[I-D.ietf-tsvwg-sctpsocket] is extended to provide a way for the
application to control the UDP encapsulation.
Please note that this section is informational only.
A socket API implementation based on [I-D.ietf-tsvwg-sctpsocket] is
extended by supporting one new read/write socket option.
5.1. Get or Set the Remote UDP Encapsulation Port Number
(SCTP_REMOTE_UDP_ENCAPS_PORT)
This socket option can be used to set and retrieve the UDP
encapsulation port number. This allows an endpoint to encapsulate
initial packets.
struct sctp_udpencaps {
sctp_assoc_t sue_assoc_id;
struct sockaddr_storage sue_address;
uint16_t sue_port;
};
sue_assoc_id: This parameter is ignored for one-to-one style
sockets. For one-to-many style sockets the application may fill
in an association identifier or SCTP_FUTURE_ASSOC for this query.
It is an error to use SCTP_{CURRENT|ALL}_ASSOC in spp_assoc_id.
sue_address: This specifies which address is of interest. If a
wildcard address is provided it applies only to future paths.
sue_port: The UDP port number used as the destination port number
for UDP encapsulation. Providing a value of 0 disables UDP
encapsulation.
6. IANA Considerations
This document does not require any actions from IANA. This document does not require any actions from IANA.
6. Security Considerations 7. Security Considerations
Encapsulating SCTP into UDP does not add any additional security Encapsulating SCTP into UDP does not add any additional security
considerations to the ones given in [RFC4960] and [RFC5061]. considerations to the ones given in [RFC4960] and [RFC5061].
7. Acknowledgments 8. Acknowledgments
The authors wish to thank Irene Ruengeler for her invaluable The authors wish to thank Irene Ruengeler for her invaluable
comments. comments.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] 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.
skipping to change at page 7, line 45 skipping to change at page 8, line 40
Protocol (SCTP)", RFC 4895, August 2007. Protocol (SCTP)", RFC 4895, August 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP) Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061, Dynamic Address Reconfiguration", RFC 5061,
September 2007. September 2007.
8.2. Informative References 9.2. Informative References
[I-D.ietf-tsvwg-sctpsocket]
Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
Yasevich, "Sockets API Extensions for Stream Control
Transmission Protocol (SCTP)",
draft-ietf-tsvwg-sctpsocket-32 (work in progress),
October 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-05 (work in progress),
June 2011. June 2011.
[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
 End of changes. 25 change blocks. 
49 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/