draft-ietf-tsvwg-sctp-udp-encaps-13.txt   draft-ietf-tsvwg-sctp-udp-encaps-14.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. R. Stewart Intended status: Standards Track R. R. Stewart
Expires: September 15, 2013 Adara Networks Expires: September 20, 2013 Adara Networks
March 14, 2013 March 19, 2013
UDP Encapsulation of SCTP Packets for End-Host to End-Host Communication UDP Encapsulation of SCTP Packets for End-Host to End-Host Communication
draft-ietf-tsvwg-sctp-udp-encaps-13.txt draft-ietf-tsvwg-sctp-udp-encaps-14.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 47 skipping to change at page 1, line 47
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 15, 2013. This Internet-Draft will expire on September 20, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Portable SCTP Implementations . . . . . . . . . . . . . . 3 3.1. Portable SCTP Implementations . . . . . . . . . . . . . . 3
3.2. Legacy NAT Traversal . . . . . . . . . . . . . . . . . . 4 3.2. Legacy NAT Traversal . . . . . . . . . . . . . . . . . . 4
4. Unilateral Self-Address Fixing (UNSAF) Considerations . . . . 4 4. Unilateral Self-Address Fixing (UNSAF) Considerations . . . . 4
5. SCTP over UDP . . . . . . . . . . . . . . . . . . . . . . . . 4 5. SCTP over UDP . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Architectural Considerations . . . . . . . . . . . . . . 4 5.1. Architectural Considerations . . . . . . . . . . . . . . 4
5.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 5 5.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Encapsulation Procedure . . . . . . . . . . . . . . . . . 6 5.3. Encapsulation Procedure . . . . . . . . . . . . . . . . . 6
5.4. Decapsulation Procedure . . . . . . . . . . . . . . . . . 6 5.4. Decapsulation Procedure . . . . . . . . . . . . . . . . . 7
5.5. ICMP Considerations . . . . . . . . . . . . . . . . . . . 7 5.5. ICMP Considerations . . . . . . . . . . . . . . . . . . . 7
5.6. Path MTU Considerations . . . . . . . . . . . . . . . . . 7 5.6. Path MTU Considerations . . . . . . . . . . . . . . . . . 8
5.7. Handling of Embedded IP-addresses . . . . . . . . . . . . 8 5.7. Handling of Embedded IP-addresses . . . . . . . . . . . . 8
5.8. ECN Considerations . . . . . . . . . . . . . . . . . . . 8 5.8. ECN Considerations . . . . . . . . . . . . . . . . . . . 8
6. Socket API Considerations . . . . . . . . . . . . . . . . . . 8 6. Socket API Considerations . . . . . . . . . . . . . . . . . . 8
6.1. Get or Set the Remote UDP Encapsulation Port Number 6.1. Get or Set the Remote UDP Encapsulation Port Number
(SCTP_REMOTE_UDP_ENCAPS_PORT) . . . . . . . . . . . . . . 8 (SCTP_REMOTE_UDP_ENCAPS_PORT) . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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
skipping to change at page 4, line 43 skipping to change at page 4, line 43
It doesn't cover generic tunneling end-points. It doesn't cover generic tunneling end-points.
Obviously, the exit strategy is to use hosts supporting SCTP natively Obviously, the exit strategy is to use hosts supporting SCTP natively
and middleboxes supporting SCTP as specified in and middleboxes supporting SCTP as specified in
[I-D.ietf-behave-sctpnat] and [I-D.ietf-tsvwg-natsupp]). [I-D.ietf-behave-sctpnat] and [I-D.ietf-tsvwg-natsupp]).
5. SCTP over UDP 5. SCTP over UDP
5.1. Architectural Considerations 5.1. Architectural Considerations
Each SCTP stack uses a single local UDP encapsulation port number as UDP encapsulated SCTP is normally communicated between SCTP stacks
the destination port for all its incoming SCTP packets. using the IANA-assigned UDP port number 9899 (sctp-tunneling) on both
ends. There are circumstances where other ports may be used on
either end: As stated earlier, implementations in the application
space might be required to use other than the registered port. Since
NAT boxes might change UDP port numbers, the receiver might observe
other UDP port numbers than were used by the sender. Discovery of
alternate ports is outside of the scope of this document, but this
section describes considerations for SCTP stack design in light of
their potential use.
If there is only a single SCTP implementation on a host (for example, Each SCTP stack uses a single local UDP encapsulation port number as
a kernel implementation being part of the operating system), using a the destination port for all its incoming SCTP packets. While the
single local UDP encapsulation port number per host can be uniqueness of the local UDP encapsulation port number is not
advantageous (e.g., this reduces the number of mappings in firewalls necessarily required for the protocol, this greatly simplifies
and NATs, among other things). Using a single local UDP implementation design, since different ports for each address would
require a sender implementation to choose the appropriate port while
doing source address selection. Using a single local UDP
encapsulation port number per host is not possible if the SCTP stack encapsulation port number per host is not possible if the SCTP stack
is implemented as part of each application, there are multiple is implemented as part of each application, there are multiple
applications, and some of the applications want to use the same IP- applications, and some of the applications want to use the same IP-
address. address.
An SCTP implementation supporting UDP encapsulation MUST store a An SCTP implementation supporting UDP encapsulation MUST maintain a
remote UDP encapsulation port number per destination address for each remote UDP encapsulation port number per destination address for each
SCTP association. SCTP association. Again, because the remote stack may be using other
than the well-known port, each port may be different from each stack,
but because of remapping of ports by NATs, the remote ports
associated with different remote IP addresses may not be identical,
even if they are associated with the same stack.
UDP encapsulated SCTP is communicated over the IANA-assigned UDP port Implementation note: Because the well-known port might not be used,
number 9899 (sctp-tunneling). However, implementations SHOULD allow implementations need allow other port numbers to be specified as a
other port numbers to be specified as a local or remote UDP local or remote UDP encapsulation port number through APIs.
encapsulation port number through APIs, as applications may have the
need to communicate over different port numbers.
5.2. Packet Format 5.2. Packet Format
To encapsulate an SCTP packet, a UDP header as defined in [RFC0768] To encapsulate an SCTP packet, a UDP header as defined in [RFC0768]
is inserted between the IP header as defined in [RFC0791] and the is inserted between the IP header as defined in [RFC0791] and the
SCTP common header as defined in [RFC4960]. 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.
skipping to change at page 6, line 28 skipping to change at page 6, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SCTP Chunk #n | | SCTP Chunk #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: An SCTP/UDP/IPv6 packet Figure 2: An SCTP/UDP/IPv6 packet
5.3. Encapsulation Procedure 5.3. Encapsulation Procedure
Within the UDP header, the source port MUST be the local UDP Within the UDP header, the source port MUST be the local UDP
encapsulation port number of the SCTP stack, the destination port encapsulation port number of the SCTP stack, the destination port
MUST be the remote UDP encapsulation port number stored for the MUST be the remote UDP encapsulation port number maintained for the
association and the destination address to which the packet is sent association and the destination address to which the packet is sent
(see Section 5.1). (see Section 5.1).
Because the SCTP packet is the UDP payload, the length of the UDP Because the SCTP packet is the UDP payload, the length of the UDP
packet MUST be the length of the SCTP packet plus the size of the UDP packet MUST be the length of the SCTP packet plus the size of the UDP
header. header.
The SCTP checksum MUST be computed and the UDP checksum SHOULD be The SCTP checksum MUST be computed and the UDP checksum SHOULD be
computed for IPv4 (see [RFC0768]) and IPv6 (see [RFC2460] and computed for IPv4 (see [RFC0768]) and IPv6 (see [RFC2460] and
[I-D.ietf-6man-udpzero]). Although UDP with a zero checksum over [I-D.ietf-6man-udpzero]). Although UDP with a zero checksum over
skipping to change at page 8, line 5 skipping to change at page 8, 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 5.5. Section 5.5.
If the implementation does not allow control of the dont't fragment If the implementation does not allow control of the don't fragment
(DF)-bit contained in the IPv4 header, then Path MTU discovery can't (DF)-bit contained in the IPv4 header, then Path MTU discovery can't
be used. In this case, an implementation specific value should be be used. In this case, an implementation specific value should be
used instead. used instead.
5.7. Handling of Embedded IP-addresses 5.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
 End of changes. 14 change blocks. 
24 lines changed or deleted 36 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/