draft-ietf-tsvwg-natsupp-05.txt   draft-ietf-tsvwg-natsupp-06.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Adara Networks Internet-Draft Adara Networks
Intended status: Standards Track M. Tuexen Intended status: Standards Track M. Tuexen
Expires: August 29, 2013 I. Ruengeler Expires: March 13, 2014 I. Ruengeler
Muenster Univ. of Appl. Sciences Muenster Univ. of Appl. Sciences
February 25, 2013 September 09, 2013
Stream Control Transmission Protocol (SCTP) Network Address Translation Stream Control Transmission Protocol (SCTP) Network Address Translation
Support Support
draft-ietf-tsvwg-natsupp-05.txt draft-ietf-tsvwg-natsupp-06.txt
Abstract Abstract
Stream Control Transmission Protocol [RFC4960] provides a reliable Stream Control Transmission Protocol [RFC4960] provides a reliable
communications channel between two end-hosts in many ways similar to communications channel between two end-hosts in many ways similar to
TCP [RFC0793]. With the widespread deployment of Network Address TCP [RFC0793]. With the widespread deployment of Network Address
Translators (NAT), specialized code has been added to NAT for TCP Translators (NAT), specialized code has been added to NAT for TCP
that allows multiple hosts to reside behind a NAT and yet use only a that allows multiple hosts to reside behind a NAT and yet use only a
single globally unique IPv4 address, even when two hosts (behind a single globally unique IPv4 address, even when two hosts (behind a
NAT) choose the same port numbers for their connection. This NAT) choose the same port numbers for their connection. This
additional code is sometimes classified as Network Address and Port additional code is sometimes classified as Network Address and Port
Translation (NAPT). To date, specialized code for SCTP has not yet Translation (NAPT). To date, specialized code for SCTP has not yet
been added to most NATs so that only pure NAT is available. The end been added to most NATs so that only pure NAT is available. The end
result of this is that only one SCTP capable host can be behind a result of this is that only one SCTP capable host can be behind a
NAT. NAT.
This document describes the protocol extensions required for the SCTP This document describes the protocol extensions required for the SCTP
endpoints to help NATs provide similar features of NAPT in the endpoints to help NATs provide similar features of NAPT in the
single-point and multi-point traversal scenario. single-point and multi-point traversal scenario.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 29, 2013. This Internet-Draft will expire on March 13, 2014.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 6 4.1. Modified Chunks . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . . 6 4.1.1. Extended ABORT Chunk . . . . . . . . . . . . . . . . 5
4.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . . 7 4.1.2. Extended ERROR Chunk . . . . . . . . . . . . . . . . 5
4.2. New Error Causes . . . . . . . . . . . . . . . . . . . . . 7 4.2. New Error Causes . . . . . . . . . . . . . . . . . . . . 6
4.2.1. VTag and Port Number Collision Error Cause . . . . . . 7 4.2.1. VTag and Port Number Collision Error Cause . . . . . 6
4.2.2. Missing State Error Cause . . . . . . . . . . . . . . 8 4.2.2. Missing State Error Cause . . . . . . . . . . . . . . 7
4.2.3. Port Number Collision Error Cause . . . . . . . . . . 8 4.2.3. Port Number Collision Error Cause . . . . . . . . . . 7
4.3. New Parameters . . . . . . . . . . . . . . . . . . . . . . 9 4.3. New Parameters . . . . . . . . . . . . . . . . . . . . . 8
4.3.1. Disable Restart Parameter . . . . . . . . . . . . . . 9 4.3.1. Disable Restart Parameter . . . . . . . . . . . . . . 8
4.3.2. VTags Parameter . . . . . . . . . . . . . . . . . . . 9 4.3.2. VTags Parameter . . . . . . . . . . . . . . . . . . . 8
5. Problem Space and Procedures . . . . . . . . . . . . . . . . . 10 5. Problem Space and Procedures . . . . . . . . . . . . . . . . 9
5.1. Problem Space Overview . . . . . . . . . . . . . . . . . . 11 5.1. Problem Space Overview . . . . . . . . . . . . . . . . . 9
5.2. Association Setup Considerations . . . . . . . . . . . . . 11 5.2. Association Setup Considerations . . . . . . . . . . . . 10
5.3. Handling of Internal Port Number and Verification Tag 5.3. Handling of Internal Port Number and Verification Tag
Collisions . . . . . . . . . . . . . . . . . . . . . . . . 11 Collisions . . . . . . . . . . . . . . . . . . . . . . . 10
5.4. Handling of Internal Port Number Collisions . . . . . . . 12 5.4. Handling of Internal Port Number Collisions . . . . . . . 11
5.5. Handling of Missing State . . . . . . . . . . . . . . . . 13 5.5. Handling of Missing State . . . . . . . . . . . . . . . . 12
5.6. Multi-Point Traversal Considerations . . . . . . . . . . . 15 5.6. Multi-Point Traversal Considerations . . . . . . . . . . 14
6. Socket API Considerations . . . . . . . . . . . . . . . . . . 15 6. Socket API Considerations . . . . . . . . . . . . . . . . . . 14
6.1. Get or Set the NAT Friendliness (SCTP_NAT_FRIENDLY) . . . 16 6.1. Get or Set the NAT Friendliness
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 (SCTP_NAT_FRIENDLY) . . . . . . . . . . . . . . . . . . . 14
7.1. New Chunk Flags for Two Existing Chunk Types . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7.2. Three New Error Causes . . . . . . . . . . . . . . . . . . 17 7.1. New Chunk Flags for Two Existing Chunk Types . . . . . . 15
7.3. Two New Chunk Parameter Types . . . . . . . . . . . . . . 18 7.2. Three New Error Causes . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7.3. Two New Chunk Parameter Types . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Stream Control Transmission Protocol [RFC4960] provides a reliable Stream Control Transmission Protocol [RFC4960] provides a reliable
communications channel between two end-hosts in many ways similar to communications channel between two end-hosts in many ways similar to
TCP [RFC0793]. With the widespread deployment of Network Address TCP [RFC0793]. With the widespread deployment of Network Address
Translators (NAT), specialized code has been added to NAT for TCP Translators (NAT), specialized code has been added to NAT for TCP
that allows multiple hosts to reside behind a NAT using private that allows multiple hosts to reside behind a NAT using private
addresses (see [RFC5735]) and yet use only a single globally unique addresses (see [RFC6890]) and yet use only a single globally unique
IPv4 address, even when two hosts (behind a NAT) choose the same port IPv4 address, even when two hosts (behind a NAT) choose the same port
numbers for their connection. This additional code is sometimes numbers for their connection. This additional code is sometimes
classified as Network Address and Port Translation (NAPT). To date, classified as Network Address and Port Translation (NAPT). To date,
specialized code for SCTP has not yet been added to most NATs so that specialized code for SCTP has not yet been added to most NATs so that
only true NAT is available. The end result of this is that only one only true NAT is available. The end result of this is that only one
SCTP capable host can be behind a NAT. SCTP capable host can be behind a NAT.
This document describes SCTP specific packets and procedures to help This document describes SCTP specific packets and procedures to help
NATs provide similar features of NAPT in the single-point and multi- NATs provide similar features of NAPT in the single-point and multi-
point traversal scenario. An SCTP implementation supporting this point traversal scenario. An SCTP implementation supporting this
skipping to change at page 4, line 38 skipping to change at page 3, line 42
SCTP packet formats. NATs should refer to [I-D.ietf-behave-sctpnat] SCTP packet formats. NATs should refer to [I-D.ietf-behave-sctpnat]
for the BCP in using these formats. for the BCP in using these formats.
When considering this feature it is possible to have multiple levels When considering this feature it is possible to have multiple levels
of support. At each level, the Internal Host, External Host and NAT of support. At each level, the Internal Host, External Host and NAT
may or may not support the features described in this document. The may or may not support the features described in this document. The
following table illustrates the results of the various combinations following table illustrates the results of the various combinations
of support and if communications can occur between two endpoints. of support and if communications can occur between two endpoints.
+---------------+------------+---------------+---------------+ +---------------+------------+---------------+---------------+
| Internal Host | NAT | External Host | Communication | | Internal Host | NAT | External Host | Communication |
+---------------+------------+---------------+---------------+ +---------------+------------+---------------+---------------+
| Support | Support | Support | Yes | | Support | Support | Support | Yes |
| Support | Support | No Support | Limited | | Support | Support | No Support | Limited |
| Support | No Support | Support | None | | Support | No Support | Support | None |
| Support | No Support | No Support | None | | Support | No Support | No Support | None |
| No Support | Support | Support | Limited | | No Support | Support | Support | Limited |
| No Support | Support | No Support | Limited | | No Support | Support | No Support | Limited |
| No Support | No Support | Support | None | | No Support | No Support | Support | None |
| No Support | No Support | No Support | None | | No Support | No Support | No Support | None |
+---------------+------------+---------------+---------------+ +---------------+------------+---------------+---------------+
Table 1: Communication possibilities Table 1: Communication possibilities
From the table we can see that when a NAT does not support the From the table we can see that when a NAT does not support the
extension no communication can occur. This is because for the most extension no communication can occur. This is because for the most
part of the current situation i. e. SCTP packets sent externally part of the current situation i. e. SCTP packets sent externally from
from behind a NAT are discarded by the NAT. In some cases, where the behind a NAT are discarded by the NAT. In some cases, where the NAT
NAT supports the feature but one of the two external hosts does not supports the feature but one of the two external hosts does not
support the feature, communication may occur but in a limited way. support the feature, communication may occur but in a limited way.
For example only one host may be able to have a connection when a For example only one host may be able to have a connection when a
collision case occurs. collision case occurs.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
This document uses the following terms, which are depicted in This document uses the following terms, which are depicted in Figure
Figure 1. 1.
Private-Address (Priv-Addr): The private address that is known to Private-Address (Priv-Addr): The private address that is known to
the internal host. the internal host.
Internal-Port (Int-Port): The port number that is in use by the host Internal-Port (Int-Port): The port number that is in use by the host
holding the Private-Address. holding the Private-Address.
Internal-VTag (Int-VTag): The Verification Tag that the internal Internal-VTag (Int-VTag): The Verification Tag that the internal
host has chosen for its communication. The VTag is a unique 32- host has chosen for its communication. The VTag is a unique
bit tag that must accompany any incoming SCTP packet for this 32-bit tag that must accompany any incoming SCTP packet for this
association to the Private-Address. association to the Private-Address.
External-Address (Ext-Addr): The address that an internal host is External-Address (Ext-Addr): The address that an internal host is
attempting to contact. attempting to contact.
External-Port (Ext-Port): The port number of the peer process at the External-Port (Ext-Port): The port number of the peer process at the
External-Address. External-Address.
External-VTag (Ext-VTag): The Verification Tag that the host holding External-VTag (Ext-VTag): The Verification Tag that the host holding
the External-Address has chosen for its communication. The VTag the External-Address has chosen for its communication. The VTag
skipping to change at page 10, line 31 skipping to change at page 9, line 25
Parameter Length: 2 bytes (unsigned integer) Parameter Length: 2 bytes (unsigned integer)
This field holds the length in bytes of the parameter. The value This field holds the length in bytes of the parameter. The value
MUST be 16. MUST be 16.
ASCONF-Request Correlation ID: 4 bytes (unsigned integer) ASCONF-Request Correlation ID: 4 bytes (unsigned integer)
This is an opaque integer assigned by the sender to identify each This is an opaque integer assigned by the sender to identify each
request parameter. The receiver of the ASCONF Chunk will copy request parameter. The receiver of the ASCONF Chunk will copy
this 32-bit value into the ASCONF Response Correlation ID field of this 32-bit value into the ASCONF Response Correlation ID field of
the ASCONF-ACK response parameter. The sender of the ASCONF can the ASCONF-ACK response parameter. The sender of the ASCONF can
use this same value in the ASCONF-ACK to find which request the use this same value in the ASCONF-ACK to find which request the
response is for. Note that the receiver MUST NOT change this 32- response is for. Note that the receiver MUST NOT change this
bit value. 32-bit value.
Internal Verification Tag: 4 bytes (unsigned integer) Internal Verification Tag: 4 bytes (unsigned integer)
The Verification Tag that the internal host has chosen for its The Verification Tag that the internal host has chosen for its
communication. The Verification Tag is a unique 32-bit tag that communication. The Verification Tag is a unique 32-bit tag that
must accompany any incoming SCTP packet for this association to must accompany any incoming SCTP packet for this association to
the Private-Address. the Private-Address.
External Verification Tag: 4 bytes (unsigned integer) The External Verification Tag: 4 bytes (unsigned integer) The
Verification Tag that the host holding the External-Address has Verification Tag that the host holding the External-Address has
chosen for its communication. The VTag is a unique 32-bit tag chosen for its communication. The VTag is a unique 32-bit tag
skipping to change at page 12, line 5 skipping to change at page 10, line 48
5.3. Handling of Internal Port Number and Verification Tag Collisions 5.3. Handling of Internal Port Number and Verification Tag Collisions
Consider the case where two hosts in the Private-Address space want Consider the case where two hosts in the Private-Address space want
to set up an SCTP association with the same server running on the to set up an SCTP association with the same server running on the
same host in the Internet. This means that the External-Port and the same host in the Internet. This means that the External-Port and the
External-Address are the same. If they both choose the same External-Address are the same. If they both choose the same
Internal-Port and Internal-VTag, the NAT box cannot distinguish Internal-Port and Internal-VTag, the NAT box cannot distinguish
between incoming packets anymore. But this is very unlikely. The between incoming packets anymore. But this is very unlikely. The
Internal-VTags are chosen at random and if the Internal-Ports are Internal-VTags are chosen at random and if the Internal-Ports are
also chosen from the ephemeral port range at random this gives a 46- also chosen from the ephemeral port range at random this gives a
bit random number which has to match. In the TCP like NAPT case the 46-bit random number which has to match. In the TCP like NAPT case
NAT box can control the 16-bit Natted Port and therefor avoid the NAT box can control the 16-bit Natted Port and therefor avoid
collisions deterministically. collisions deterministically.
The same can happen when an INIT-ACK chunk or an ASCONF chunk is The same can happen when an INIT-ACK chunk or an ASCONF chunk is
processed by the NAT. processed by the NAT.
However, in this unlikely event the NAT box MUST send an ABORT chunk However, in this unlikely event the NAT box MUST send an ABORT chunk
with the M-bit set if the collision is triggered by an INIT or INIT- with the M-bit set if the collision is triggered by an INIT or INIT-
ACK chunk or send an ERROR chunk with the M-bit set if the collision ACK chunk or send an ERROR chunk with the M-bit set if the collision
is triggered by an ASCONF chunk. The M-bit is a new bit defined by is triggered by an ASCONF chunk. The M-bit is a new bit defined by
this document to express to SCTP that the source of this packet is a this document to express to SCTP that the source of this packet is a
skipping to change at page 15, line 24 skipping to change at page 14, line 17
ERROR chunk. ERROR chunk.
o If the association is attempting to add an address (i. e. o If the association is attempting to add an address (i. e.
following the procedures in Section 5.6) then the endpoint MUST- following the procedures in Section 5.6) then the endpoint MUST-
NOT consider the address part of the association and SHOULD make NOT consider the address part of the association and SHOULD make
no further attempt to add the address (i. e. cancel any ASCONF no further attempt to add the address (i. e. cancel any ASCONF
timers and remove any record of the path), since the NAT has a timers and remove any record of the path), since the NAT has a
VTag collision and the association cannot easily create a new VTag VTag collision and the association cannot easily create a new VTag
(as it would if the error occurred when sending an INIT). (as it would if the error occurred when sending an INIT).
o If the endpoint has no other path, i. e. the procedure was o If the endpoint has no other path, i. e. the procedure was
executed due to missing a state in the NAT, then the endpoint MUST executed due to missing a state in the NAT, then the endpoint MUST
abort the association. This would occur only if the local NAT abort the association. This would occur only if the local NAT
restarted and accepted a new association before attempting to restarted and accepted a new association before attempting to
repair the missing state (Note that this is no different than what repair the missing state (Note that this is no different than what
happens to all TCP connections when a NAT looses its state). happens to all TCP connections when a NAT looses its state).
5.6. Multi-Point Traversal Considerations 5.6. Multi-Point Traversal Considerations
If a multi-homed SCTP endpoint behind a NAT connects to a peer, it If a multi-homed SCTP endpoint behind a NAT connects to a peer, it
SHOULD first set up the association single-homed with only one SHOULD first set up the association single-homed with only one
skipping to change at page 19, line 4 skipping to change at page 17, line 44
The document does not add any additional security considerations to The document does not add any additional security considerations to
the ones given in [RFC4960], [RFC4895], and [RFC5061]. the ones given in [RFC4960], [RFC4895], and [RFC5061].
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Jason But, Bryan Ford, David Hayes, Alfred The authors wish to thank Jason But, Bryan Ford, David Hayes, Alfred
Hines, Henning Peters, Timo Voelker, Dan Wing, and Qiaobing Xie for Hines, Henning Peters, Timo Voelker, Dan Wing, and Qiaobing Xie for
their invaluable comments. their invaluable comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
RFC 793, September 1981. 793, 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.
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for the Stream Control Transmission "Authenticated Chunks for the Stream Control Transmission
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
RFC 4960, September 2007. 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
September 2007. 2007.
[RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission [RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission
Protocol (SCTP) Chunk Flags Registration", RFC 6096, Protocol (SCTP) Chunk Flags Registration", RFC 6096,
January 2011. January 2011.
10.2. Informative References 10.2. Informative References
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses",
BCP 153, RFC 5735, January 2010.
[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.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153, RFC
6890, April 2013.
[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-07 (work in progress), draft-ietf-behave-sctpnat-08 (work in progress), February
October 2012. 2013.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Adara Networks Adara Networks
Chapin, SC 29036 Chapin, SC 29036
US US
Email: randall@lakerest.net Email: randall@lakerest.net
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
Irene Ruengeler Irene Ruengeler
Muenster University of Applied Sciences Muenster University of Applied Sciences
 End of changes. 25 change blocks. 
69 lines changed or deleted 71 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/