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/ |