doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc6084.txt b/doc/rfc/rfc6084.txt
new file mode 100644
index 0000000..c3b8a05
--- /dev/null
+++ b/doc/rfc/rfc6084.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                             X. Fu
+Request for Comments: 6084                                   C. Dickmann
+Category: Experimental                          University of Goettingen
+ISSN: 2070-1721                                             J. Crowcroft
+                                                 University of Cambridge
+                                                            January 2011
+
+
+              General Internet Signaling Transport (GIST)
+            over Stream Control Transmission Protocol (SCTP)
+              and Datagram Transport Layer Security (DTLS)
+
+Abstract
+
+   The General Internet Signaling Transport (GIST) protocol currently
+   uses TCP or Transport Layer Security (TLS) over TCP for Connection
+   mode operation.  This document describes the usage of GIST over the
+   Stream Control Transmission Protocol (SCTP) and Datagram Transport
+   Layer Security (DTLS).
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for examination, experimental implementation, and
+   evaluation.
+
+   This document defines an Experimental Protocol for the Internet
+   community.  This document is a product of the Internet Engineering
+   Task Force (IETF).  It represents the consensus of the IETF
+   community.  It has received public review and has been approved for
+   publication by the Internet Engineering Steering Group (IESG).  Not
+   all documents approved by the IESG are a candidate for any level of
+   Internet Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6084.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+
+
+
+Fu, et al.                    Experimental                      [Page 1]
+
+RFC 6084                 GIST over SCTP and DTLS            January 2011
+
+
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Terminology and Abbreviations  . . . . . . . . . . . . . . . .  4
+   3.  GIST over SCTP . . . . . . . . . . . . . . . . . . . . . . . .  5
+     3.1.  Message Association Setup  . . . . . . . . . . . . . . . .  5
+       3.1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . .  5
+       3.1.2.  Protocol-Definition: Forwards-SCTP . . . . . . . . . .  5
+     3.2.  Effect on GIST State Maintenance . . . . . . . . . . . . .  6
+     3.3.  PR-SCTP Support  . . . . . . . . . . . . . . . . . . . . .  6
+     3.4.  API between GIST and NSLP  . . . . . . . . . . . . . . . .  7
+   4.  Bit-Level Formats  . . . . . . . . . . . . . . . . . . . . . .  7
+     4.1.  MA-Protocol-Options  . . . . . . . . . . . . . . . . . . .  7
+   5.  Application of GIST over SCTP  . . . . . . . . . . . . . . . .  8
+     5.1.  Multihoming Support of SCTP  . . . . . . . . . . . . . . .  8
+     5.2.  Streaming Support in SCTP  . . . . . . . . . . . . . . . .  8
+   6.  NAT Traversal Issue  . . . . . . . . . . . . . . . . . . . . .  8
+   7.  Use of DTLS with GIST  . . . . . . . . . . . . . . . . . . . .  9
+   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
+   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
+     11.2. Informative References . . . . . . . . . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+Fu, et al.                    Experimental                      [Page 2]
+
+RFC 6084                 GIST over SCTP and DTLS            January 2011
+
+
+1.  Introduction
+
+   This document describes the usage of the General Internet Signaling
+   Transport (GIST) protocol [1] and Datagram Transport Layer Security
+   (DTLS) [2].
+
+   GIST, in its initial specification for Connection mode (C-mode)
+   operation, runs on top of a byte-stream-oriented transport protocol
+   providing a reliable, in-sequence delivery, i.e., using the
+   Transmission Control Protocol (TCP) [9] for signaling message
+   transport.  However, some Next Steps in Signaling (NSIS) Signaling
+   Layer Protocol (NSLP) [10] context information has a definite
+   lifetime; therefore, the GIST transport protocol could benefit from
+   flexible retransmission, so stale NSLP messages that are held up by
+   congestion can be dropped.  Together with the head-of-line blocking
+   and multihoming issues with TCP, these considerations argue that
+   implementations of GIST should support SCTP as an optional transport
+   protocol for GIST.  Like TCP, SCTP supports reliability, congestion
+   control, and fragmentation.  Unlike TCP, SCTP provides a number of
+   functions that are desirable for signaling transport, such as
+   multiple streams and multiple IP addresses for path failure recovery.
+   Furthermore, SCTP offers an advantage of message-oriented transport
+   instead of using the byte-stream-oriented TCP where the framing
+   mechanisms must be provided separately.  In addition, its Partial
+   Reliability extension (PR-SCTP) [3] supports partial retransmission
+   based on a programmable retransmission timer.  Furthermore, DTLS
+   provides a viable solution for securing SCTP [4], which allows SCTP
+   to use almost all of its transport features and its extensions.
+
+   This document defines the use of SCTP as the underlying transport
+   protocol for GIST and the use of DTLS as a security mechanism for
+   protecting GIST Messaging Associations and discusses the implications
+   on GIST state maintenance and API between GIST and NSLPs.
+   Furthermore, this document describes how GIST is transported over
+   SCTP and used by NSLPs in order to exploit the additional
+   capabilities offered by SCTP to deliver GIST C-mode messages more
+   effectively.  More specifically:
+
+   o  How to use the multiple streams feature of SCTP.
+
+   o  How to use the PR-SCTP extension of SCTP.
+
+   o  How to take advantage of the multihoming support of SCTP.
+
+   GIST over SCTP as described in this document does not require any
+   changes to the high-level operation and structure of GIST.  However,
+   adding new transport options requires additional interface code and
+   configuration support to allow applications to exploit the additional
+
+
+
+Fu, et al.                    Experimental                      [Page 3]
+
+RFC 6084                 GIST over SCTP and DTLS            January 2011
+
+
+   transport when appropriate.  In addition, SCTP implementations to
+   transport GIST MUST support the optional feature of fragmentation of
+   SCTP user messages.
+
+   Additionally, this document also specifies how to establish GIST
+   security using DTLS for use in combination with, e.g., SCTP and UDP.
+
+2.  Terminology and Abbreviations
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [5].  Other
+   terminologies and abbreviations used in this document are taken from
+   related specifications ([1], [2], [3], [6]):
+
+   o  SCTP - Stream Control Transmission Protocol
+
+   o  PR-SCTP - SCTP Partial Reliability Extension
+
+   o  MRM - Message Routing Method
+
+   o  MRI - Message Routing Information
+
+   o  SCD - Stack-Configuration-Data
+
+   o  Messaging Association (MA) - A single connection between two
+      explicitly identified GIST adjacent peers, i.e., between a given
+      signaling source and destination address.  A messaging association
+      may use a transport protocol; if security protection is required,
+      it may use a specific network layer security association, or use a
+      transport layer security association internally.  A messaging
+      association is bidirectional: signaling messages can be sent over
+      it in either direction, referring to flows of either direction.
+
+   o  SCTP Association - A protocol relationship between SCTP endpoints,
+      composed of the two SCTP endpoints and protocol state information.
+      An association can be uniquely identified by the transport
+      addresses used by the endpoints in the association.  Two SCTP
+      endpoints MUST NOT have more than one SCTP association between
+      them at any given time.
+
+   o  Stream - A unidirectional logical channel established from one to
+      another associated SCTP endpoint, within which all user messages
+      are delivered in sequence except for those submitted to the
+      unordered delivery service.
+
+
+
+
+
+
+Fu, et al.                    Experimental                      [Page 4]
+
+RFC 6084                 GIST over SCTP and DTLS            January 2011
+
+
+3.  GIST over SCTP
+
+   This section defines a new MA-Protocol-ID type, "Forwards-SCTP", for
+   using SCTP as the GIST transport protocol.  The use of DTLS in GIST
+   is defined in Section 7.
+
+3.1.  Message Association Setup
+
+3.1.1.  Overview
+
+   The basic GIST protocol specification defines two possible protocols
+   to be used in Messaging Associations, namely Forwards-TCP and TLS.
+   This information is a main part of the Stack Configuration Data (SCD)
+   [1].  This section adds Forwards-SCTP (value 3) as another possible
+   protocol option.  In Forwards-SCTP, analog to Forwards-TCP,
+   connections between peers are opened in the forwards direction, from
+   the querying node, towards the responder.
+
+3.1.2.  Protocol-Definition: Forwards-SCTP
+
+   The MA-Protocol-ID "Forwards-SCTP" denotes a basic use of SCTP
+   between peers.  Support for this protocol is OPTIONAL.  If this
+   protocol is offered, MA-protocol-options data MUST also be carried in
+   the SCD object.  The MA-protocol-options field formats are:
+
+   o  in a Query: no information apart from the field header.
+
+   o  in a Response: 2-byte port number at which the connection will be
+      accepted, followed by 2 pad bytes.
+
+   The connection is opened in the forwards direction, from the querying
+   node towards the responder.  The querying node MAY use any source
+   address and source port.  The destination for establishing the
+   message association MUST be derived from information in the Response:
+   the address from the interface-address in the Network-Layer-
+   Information object and the port from the SCD object as described
+   above.
+
+   Associations using Forwards-SCTP can carry messages with the transfer
+   attribute Reliable=True.  If an error occurs on the SCTP connection
+   such as a reset, as can be reported by an SCTP socket API
+   notification [11], GIST MUST report this to NSLPs as discussed in
+   Section 4.1.2 of [1].  For the multihoming scenario, when a
+   destination address of a GIST-over-SCTP peer encounters a change, the
+   SCTP API will notify GIST about the availability of different SCTP
+   endpoint addresses and the possible change of the primary path.
+
+
+
+
+
+Fu, et al.                    Experimental                      [Page 5]
+
+RFC 6084                 GIST over SCTP and DTLS            January 2011
+
+
+3.2.  Effect on GIST State Maintenance
+
+   As SCTP provides additional functionality over TCP, this section
+   discusses the implications of using GIST over SCTP on GIST state
+   maintenance.
+
+   While SCTP defines unidirectional streams, for the purpose of this
+   document, the concept of a bidirectional stream is used.
+   Implementations MUST establish both downstream and upstream
+   (unidirectional) SCTP streams and use the same stream identifier in
+   both directions.  Thus, the two unidirectional streams (in opposite
+   directions) form a bidirectional stream.
+
+   Due to the multi-streaming support of SCTP, it is possible to use
+   different SCTP streams for different resources (e.g., different NSLP
+   sessions), rather than maintaining all messages along the same
+   transport connection/association in a correlated fashion as TCP
+   (which imposes strict (re)ordering and reliability per transport
+   level).  However, there are limitations to the use of multi-
+   streaming.  When an SCTP implementation is used for GIST transport,
+   all GIST messages for a particular session MUST be sent over the same
+   SCTP stream to assure the NSLP assumption of in-order delivery.
+   Multiple sessions MAY share the same SCTP stream based on local
+   policy.
+
+   The GIST concept of Messaging Association re-use is not affected by
+   this document or the use of SCTP.  All rules defined in the GIST
+   specification remain valid in the context of GIST over SCTP.
+
+3.3.  PR-SCTP Support
+
+   A variant of SCTP, PR-SCTP [3] provides a "timed reliability"
+   service, which would be particularly useful for delivering GIST
+   Connection mode messages.  It allows the user to specify, on a per-
+   message basis, the rules governing how persistent the transport
+   service should be in attempting to send the message to the receiver.
+   Because of the chunk bundling function of SCTP, reliable and
+   partially reliable messages can be multiplexed over a single PR-SCTP
+   association.  Therefore, an SCTP implementation for GIST transport
+   SHOULD attempt to establish a PR-SCTP association using "timed
+   reliability" service instead of a standard SCTP association, if
+   available, to support more flexible transport features for potential
+   needs of different NSLPs.
+
+   When using a normally reliable session (as opposed to a partially
+   reliable session), if a node has sent the first transmission before
+   the lifetime expires, then the message MUST be sent as a normal
+   reliable message.  During episodes of congestion, this is
+
+
+
+Fu, et al.                    Experimental                      [Page 6]
+
+RFC 6084                 GIST over SCTP and DTLS            January 2011
+
+
+   particularly unfortunate, as retransmission wastes bandwidth that
+   could have been used for other (non-lifetime expired) messages.  The
+   "timed reliability" service in PR-SCTP eliminates this issue and is
+   hence RECOMMENDED to be used for GIST over PR-SCTP.
+
+3.4.  API between GIST and NSLP
+
+   The GIST specification defines an abstract API between GIST and
+   NSLPs.  While this document does not change the API itself, the
+   semantics of some parameters have slightly different interpretations
+   in the context of SCTP.  This section only lists those primitives and
+   parameters that need special consideration when used in the context
+   of SCTP.  The relevant primitives from [1] are as follows:
+
+   o  The Timeout parameter in API "SendMessage": According to [1], this
+      parameter represents the "length of time GIST should attempt to
+      send this message before indicating an error".  When used with
+      PR-SCTP, this parameter is used as the timeout for the "timed
+      reliability" service of PR-SCTP.
+
+   o  "NetworkNotification": According to [1], this primitive "is passed
+      from GIST to a signalling application.  It indicates that a
+      network event of possible interest to the signalling application
+      occurred".  Here, if SCTP detects a failure of the primary path,
+      GIST SHOULD also indicate this event to the NSLP by calling this
+      primitive with Network-Notification-Type "Routing Status Change".
+      This notification should be done even if SCTP was able to retain
+      an open connection to the peer due to its multihoming
+      capabilities.
+
+4.  Bit-Level Formats
+
+4.1.  MA-Protocol-Options
+
+   This section provides the bit-level format for the MA-protocol-
+   options field that is used for SCTP protocol in the Stack-
+   Configuration-Data object of GIST.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   :       SCTP port number        |         Reserved              :
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   SCTP port number  = Port number at which the responder will accept
+                       SCTP connections
+
+   The SCTP port number is only supplied if sent by the responder.
+
+
+
+Fu, et al.                    Experimental                      [Page 7]
+
+RFC 6084                 GIST over SCTP and DTLS            January 2011
+
+
+5.  Application of GIST over SCTP
+
+5.1.  Multihoming Support of SCTP
+
+   In general, the multihoming support of SCTP can be used to improve
+   fault-tolerance in case of a path or link failure.  Thus, GIST over
+   SCTP would be able to deliver NSLP messages between peers even if the
+   primary path is not working anymore.  However, for the Message
+   Routing Methods (MRMs) defined in the basic GIST specification, such
+   a feature is only of limited use.  The default MRM is path-coupled,
+   which means that if the primary path is failing for the SCTP
+   association, it most likely is also failing for the IP traffic that
+   is signaled for.  Thus, GIST would need to perform a refresh to the
+   NSIS nodes to the alternative path anyway to cope with the route
+   change.  When the two endpoints of a multihomed SCTP association (but
+   none of the intermediate nodes between them) support NSIS, GIST over
+   SCTP provides a robust means for GIST to deliver NSLP messages even
+   when the primary path fails but at least one alternative path between
+   these (NSIS-enabled) endpoints of the multihomed path is available.
+   Additionally, the use of the multihoming support of SCTP provides
+   GIST and the NSLP with another source to detect route changes.
+   Furthermore, for the time between detection of the route change and
+   recovering from it, the alternative path offered by SCTP can be used
+   by the NSLP to make the transition more smoothly.  Finally, future
+   MRMs might have different properties and therefore benefit from
+   multihoming more broadly.
+
+5.2.  Streaming Support in SCTP
+
+   Streaming support in SCTP is advantageous for GIST.  It allows better
+   parallel processing, in particular by avoiding the head-of-line
+   blocking issue in TCP.  Since a single GIST MA may be reused by
+   multiple sessions, using TCP as the transport for GIST signaling
+   messages belonging to different sessions may be blocked if another
+   message is dropped.  In the case of SCTP, this can be avoided, as
+   different sessions having different requirements can belong to
+   different streams; thus, a message loss or reordering in a stream
+   will only affect the delivery of messages within that particular
+   stream, and not any other streams.
+
+6.  NAT Traversal Issue
+
+   NAT traversal for GIST over SCTP will follow Section 7.2 of [1] and
+   the GIST extensibility capabilities defined in [12].  This
+   specification does not define NAT traversal procedures for GIST over
+   SCTP, although an approach for SCTP NAT traversal is described in
+   [13].
+
+
+
+
+Fu, et al.                    Experimental                      [Page 8]
+
+RFC 6084                 GIST over SCTP and DTLS            January 2011
+
+
+7.  Use of DTLS with GIST
+
+   This section specifies a new MA-Protocol-ID "DTLS" (value 4) for the
+   use of DTLS in GIST, which denotes a basic use of datagram transport
+   layer channel security, initially in conjunction with GIST over SCTP.
+   It provides server (i.e., GIST transport receiver) authentication and
+   integrity (as long as the NULL ciphersuite is not selected during
+   ciphersuite negotiation), as well as optionally replay protection for
+   control packets.  The use of DTLS for securing GIST over SCTP allows
+   GIST to take the advantage of features provided by SCTP and its
+   extensions.  The usage of DTLS for GIST over SCTP is similar to TLS
+   for GIST as specified in [1], where a stack-proposal containing both
+   MA-Protocol-IDs for SCTP and DTLS during the GIST handshake phase.
+
+   The usage of DTLS [2] for securing GIST over datagram transport
+   protocols MUST be implemented and SHOULD be used.
+
+   GIST message associations using DTLS may carry messages with transfer
+   attributes requesting confidentiality or integrity protection.  The
+   specific DTLS version will be negotiated within the DTLS layer
+   itself, but implementations MUST NOT negotiate to protocol versions
+   prior to DTLS v1.0 and MUST use the highest protocol version
+   supported by both peers.  NULL authentication and integrity ciphers
+   MUST NOT be negotiated for GIST nodes supporting DTLS.  For
+   confidentiality ciphers, nodes can negotiate the NULL ciphersuites.
+   The same rules for negotiating TLS ciphersuites as specified in
+   Section 5.7.3 of [1] apply.
+
+   DTLS renegotiation [7] may cause problems for applications such that
+   connection security parameters can change without the application
+   knowing it.  Hence, it is RECOMMENDED that renegotiation be disabled
+   for GIST over DTLS.
+
+   No MA-protocol-options field is required for DTLS.  The configuration
+   information for the transport protocol over which DTLS is running
+   (e.g., SCTP port number) is provided by the MA-protocol-options for
+   that protocol.
+
+8.  Security Considerations
+
+   The security considerations of [1], [6], and [2] apply.
+   Additionally, although [4] does not support replay detection in DTLS
+   over SCTP, the SCTP replay protection mechanisms [6] [8] should be
+   able to protect NSIS messages transported using GIST over (DTLS over)
+   SCTP from replay attacks.
+
+
+
+
+
+
+Fu, et al.                    Experimental                      [Page 9]
+
+RFC 6084                 GIST over SCTP and DTLS            January 2011
+
+
+9.  IANA Considerations
+
+   According to this specification, IANA has registered the following
+   codepoints (MA-Protocol-IDs) in a registry created by [1]:
+
+     +---------------------+------------------------------------------+
+     | MA-Protocol-ID      | Protocol                                 |
+     +---------------------+------------------------------------------+
+     | 3                   | SCTP opened in the forwards direction    |
+     |                     |                                          |
+     | 4                   | DTLS initiated in the forwards direction |
+     +---------------------+------------------------------------------+
+
+   Note that MA-Protocol-ID "DTLS" is never used alone but always
+   coupled with a transport protocol specified in the stack proposal.
+
+10.  Acknowledgments
+
+   The authors would like to thank John Loughney, Jukka Manner, Magnus
+   Westerlund, Sean Turner, Lars Eggert, Jeffrey Hutzelman, Robert
+   Hancock, Andrew McDonald, Martin Stiemerling, Fang-Chun Kuo, Jan
+   Demter, Lauri Liuhto, Michael Tuexen, and Roland Bless for their
+   helpful suggestions.
+
+11.  References
+
+11.1.  Normative References
+
+   [1]   Schulzrinne, H. and R. Hancock, "GIST: General Internet
+         Signalling Transport", RFC 5971, October 2010.
+
+   [2]   Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+         Security", RFC 4347, April 2006.
+
+   [3]   Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad,
+         "Stream Control Transmission Protocol (SCTP) Partial
+         Reliability Extension", RFC 3758, May 2004.
+
+   [4]   Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
+         Transport Layer Security (DTLS) for Stream Control Transmission
+         Protocol (SCTP)", RFC 6083, January 2011.
+
+   [5]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [6]   Stewart, R., "Stream Control Transmission Protocol", RFC 4960,
+         September 2007.
+
+
+
+
+Fu, et al.                    Experimental                     [Page 10]
+
+RFC 6084                 GIST over SCTP and DTLS            January 2011
+
+
+   [7]   Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport
+         Layer Security (TLS) Renegotiation Indication Extension",
+         RFC 5746, February 2010.
+
+   [8]   Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
+         "Authenticated Chunks for the Stream Control Transmission
+         Protocol (SCTP)", RFC 4895, August 2007.
+
+11.2.  Informative References
+
+   [9]   Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
+         September 1981.
+
+   [10]  Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
+         Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 4080,
+         June 2005.
+
+   [11]  Stewart, R., Poon, K., Tuexen, M., Yasevich, V., and P. Lei,
+         "Sockets API Extensions for Stream Control Transmission
+         Protocol (SCTP)", Work in Progress, January 2011.
+
+   [12]  Manner, J., Bless, R., Loughney, J., and E. Davies, "Using and
+         Extending the NSIS Protocol Family", RFC 5978, October 2010.
+
+   [13]  Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control
+         Transmission Protocol (SCTP) Network Address Translation", Work
+         in Progress, December 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fu, et al.                    Experimental                     [Page 11]
+
+RFC 6084                 GIST over SCTP and DTLS            January 2011
+
+
+Authors' Addresses
+
+   Xiaoming Fu
+   University of Goettingen
+   Institute of Computer Science
+   Goldschmidtstr. 7
+   Goettingen  37077
+   Germany
+
+   EMail: fu@cs.uni-goettingen.de
+
+
+   Christian Dickmann
+   University of Goettingen
+   Institute of Computer Science
+   Goldschmidtstr. 7
+   Goettingen  37077
+   Germany
+
+   EMail: mail@christian-dickmann.de
+
+
+   Jon Crowcroft
+   University of Cambridge
+   Computer Laboratory
+   William Gates Building
+   15 JJ Thomson Avenue
+   Cambridge  CB3 0FD
+   UK
+
+   EMail: jon.crowcroft@cl.cam.ac.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fu, et al.                    Experimental                     [Page 12]
+