draft-ietf-tsvwg-sctp-udp-encaps-05.txt   draft-ietf-tsvwg-sctp-udp-encaps-06.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: April 22, 2013 Adara Networks Expires: April 23, 2013 Adara Networks
October 19, 2012 October 20, 2012
UDP Encapsulation of SCTP Packets UDP Encapsulation of SCTP Packets
draft-ietf-tsvwg-sctp-udp-encaps-05.txt draft-ietf-tsvwg-sctp-udp-encaps-06.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 April 22, 2013. This Internet-Draft will expire on April 23, 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 4, line 29 skipping to change at page 4, line 29
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 An SCTP implementation supporting UDP encapsulation MUST store 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.
Each SCTP stack uses a single local UDP encapsulation port number as Each SCTP stack uses a single local UDP encapsulation port number as
the destination port for all its incoming SCTP packets. The IANA the destination port for all its incoming SCTP packets. The IANA
assigned value of 9989 MAY be used as this port number. If there is assigned value of 9899 MAY be used as this port number. If there is
only a single SCTP implementation on a host (for example, a kernel only a single SCTP implementation on a host (for example, a kernel
implementation being part of the operating system), using a single implementation being part of the operating system), using a single
UDP encapsulation port number per host can be advantageous (e.g., UDP encapsulation port number per host can be advantageous (e.g.,
this reduces the number of mappings in firewalls and NATs, among this reduces the number of mappings in firewalls and NATs, among
other things). However, this is not possible if the SCTP stack is other things). However, this is not possible if the SCTP stack is
implemented as part of an application. implemented as part of an application.
4.2. Packet Format 4.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]
skipping to change at page 8, line 35 skipping to change at page 8, line 35
sue_address: This specifies which address is of interest. If a sue_address: This specifies which address is of interest. If a
wildcard address is provided it applies only to future paths. wildcard address is provided it applies only to future paths.
sue_port: The UDP port number in network byte order used as the sue_port: The UDP port number in network byte order used as the
destination port number for UDP encapsulation. Providing a value destination port number for UDP encapsulation. Providing a value
of 0 disables UDP encapsulation. of 0 disables UDP encapsulation.
6. IANA Considerations 6. IANA Considerations
This document does not require any actions from IANA. This document does not require any actions from IANA. It refers to
the already assigned UDP port 9899 (sctp-tunneling).
7. 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].
8. Acknowledgments 8. Acknowledgments
The authors wish to thank Gorry Fairhurst, Irene Ruengeler, and Dan The authors wish to thank Gorry Fairhurst, Irene Ruengeler, and Dan
Wing for their invaluable comments. Wing for their invaluable comments.
 End of changes. 5 change blocks. 
6 lines changed or deleted 7 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/