idnits 2.17.1 draft-ietf-sigtran-sctptunnel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 149: '...oint is multi-homed, the endpoint MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 81 has weird spacing: '... use of the r...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1981 (ref. '3') (Obsoleted by RFC 8201) -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Transport Working Group L. Ong 2 Internet-Draft Nortel Networks 3 draft-ietf-sigtran-sctptunnel-00.txt R. Stewart 4 March 2000 Q. Xie 5 Expires: August 2000 Motorola 7 Tunneling of SCTP over Single UDP Port 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. Internet-Drafts 13 are working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as "work 21 in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The Simple Control Transmission Protocol (SCTP) [1] provides a 32 standard method for transporting messages over IP, with features 33 such as multi-homing and multi-stream built into the protocol 34 for additional reliability and real-time delivery. This memo 35 defines a method for tunneling SCTP over a single UDP port in 36 order to simplify initial implementations. This memo is intended 37 to become an Experimental document and is not intended as a 38 standard of any kind. 40 Table of Contents 42 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 43 2. Brief background to the SCTP Protocol. . . . . . . . . . . 2 44 3. Interim Implementation over UDP. . . . . . . . . . . . . . 2 45 4. Use of Single UDP Port . . . . . . . . . . . . . . . . . . 2 46 5. Impacts on SCTP Protocol . . . . . . . . . . . . . . . . . 3 47 6. Possible applications . . . . . . . . . . . . . . . . . . 4 48 7. Implementation considerations . . . . . . . . . . . . . . 4 49 8. Security considerations . . . . . . . . . . . . . . . . . 4 50 9. References . . . . . . . . . . . . . . . . . . . . . . . . 5 51 10. Author's Addresses . . . . . . . . . . . . . . . . . . . . 5 53 1. Introduction 55 This memo describes the methods for tunneling of Simple Control Trans- 56 mission Protocol (SCTP) over UDP. Tunneling of SCTP can be done without 57 change to the protocol formats and basic procedures. Since SCTP provides 58 a means of de-multiplexing sessions using the SCTP source and destination 59 port numbers, only a single UDP port is necessary for tunneling. 61 2. Background 63 SCTP is designed to transport PSTN signaling messages over 64 IP networks, but is capable of broader applications. 66 SCTP is a reliable datagram transfer protocol operating on top of an 67 unreliable routed packet network such as IP. It offers the following 68 services to its users: 70 -- acknowledged error-free non-duplicated transfer of user data, 71 -- data segmentation to conform to discovered path MTU size, 72 -- sequenced delivery of user datagrams within multiple streams, 73 with an option for order-of-arrival delivery of individual 74 datagrams, 75 -- optional multiplexing of user messages into SCTP datagrams, and 76 -- network-level fault tolerance through supporting of multi-homing 77 at either or both ends of an association. 79 3. Interim Implementation over UDP 81 Implementation of SCTP directly over IP requires use of the raw_IP 82 socket interface and/or modification to the kernel. To allow more 83 rapid implementation and implementation on systems that do not at 84 this time support the raw_IP socket interface, this memo defines a 85 method of tunneling SCTP over a single registered UDP port number. 87 Tunneling of SCTP over UDP adds some unnecessary processing to the 88 protocol, including redundant source and destination port fields 89 and greater interprocess communication. It is therefore provided 90 only as an interim measure until implementation of SCTP over IP is 91 available. 93 4. Use of Single UDP Port 95 UDP port 9899 has been registered with IANA for SCTP Tunneling. 96 The use of a single port number still allows multiplexing of SCTP 97 sessions, using the SCTP's own source and destination port numbers. 98 At the same time, the use of a single registered port number allows 99 intermediate systems such as routers and firewalls to immediately 100 identify SCTP packets and provide any associated treatment that is 101 desired. 103 5. Impacts on SCTP Protocol 105 There are minimal impacts on SCTP fields and basic procedures from the 106 use of tunneling over UDP. In general SCTP functions such as 107 initiation, data transfer, congestion control and heartbeat operate 108 exactly as defined in the standard SCTP specification. 110 5.1 Impact on MTU discovery 112 SCTP requires the use of path MTU discovery [2] [3] . However many 113 operating systems do not allow a user to implement changes to the DF 114 bit (in the IP header) without opening a RAW IP socket. In some 115 operating systems facilities are available to allow a UDP user to 116 enable MTU discovery, these require some minor modification to the 117 SCTP procedures. 119 5.1.1 Where MTU discovery is NOT allowed 121 In cases where MTU discovery requires a RAW IP socket to implement, it 122 is expected that the UDP tunnel would NOT be capable of supporting 123 MTU discovery. This feature should remain disabled when implementing 124 on these systems. 126 5.1.2 Where MTU discovery IS allowed 128 In cases where a MTU discovery feature is enabled by a kernel 129 interface, the following modifications need to be made to the 130 SCTP path MTU discovery procedures: 132 1) Whenever the kernel reports an unreachable destination due to 133 an ICMP unreachable destination message. Within the message 134 a size value is passed to indicate the size of the largest MTU 135 value that the reporting network element can send. This size 136 must be reduced by the size of the UDP header before passing 137 it to the SCTP stack. 139 2) When a report is made and SCTP is unable to re-fragment the 140 datagram by changing the bundling, the UDP interface layer must 141 re-enable IP fragmentation by clearing the DF bit until the larger 142 datagram is retransmitted. Once the larger, datagram has been 143 retransmitted the IP fragmentation must be disabled. 145 5.2 Impact on Multi-homing 147 SCTP explicitly uses multi-homing to provide for fast recovery 148 from network error conditions (when the peer is multi-homed). In 149 cases where a tunneled endpoint is multi-homed, the endpoint MUST 150 bind all addresses to the reserved UDP port numbers. This will allow 151 the SCTP multi-homing to work seamlessly. 153 6. Possible Applications 155 Tunneled SCTP has the same range of applications as SCTP over IP, such 156 as transport of Signaling System 7, ISUP [4] or other telephony signaling 157 protocols. The only new consideration is that tunneled SCTP should 158 eventually be deprecated in favor of SCTP over IP for transport. 160 It must be noted that there is NO inter-operability between a tunneled 161 SCTP endpoint and a SCTP endpoint running directly on top of IP. This 162 provides a limitation that when one endpoint moves directly on 163 top of IP all endpoints it communicates with must also move at the 164 same time. 166 7. Implementation considerations 168 As discussed in section 5.2, a daemon providing tunneling of SCTP 169 MUST bind all addresses to the SCTP reserved port. Other considerations 170 such as: 172 A) How the application process(es) communicate with the SCTP tunneling 173 point. 175 B) How the tunneling point de-multiplexes the SCTP port number to 176 find the real endpoint to send a datagram to. 178 are beyond the scope of this document and are implementation specific. 180 8. Security Considerations 182 Tunneled SCTP is subject to the same security concerns as SCTP over IP. 183 However, the same security mechanisms can be used, i.e., application of 184 IPSEC to provide authentication and/or encryption of the transported 185 signaling and control information. In this case, IPSEC could be applied 186 as for any UDP stream, whereas for SCTP over IP, application to an 187 SCTP protocol type is required. 189 9. References 191 [1] Simple Control Transport Protocol , Mar. 2000, Work in Progress 194 [2] Mogul, J., and Deering, S., "Path MTU Discovery", RFC 1191, 195 November 1990. 197 [3] McCann, J., Deering, S., and Mogul, J., "Path MTU Discovery for 198 IP version 6", RFC 1981, August 1996. 200 [4] ITU-T Recommendations Q.761 to Q.767, 'Signalling System No.7 (SS7) 201 - ISDN User Part (ISUP)' 203 10. Author's Addresses 205 Lyndon Ong Tel: +1-408-495-5072 206 Nortel Networks EMail: long@nortelnetworks.com 207 4401 Great America Pkwy 208 Santa Clara, CA, USA 95054 210 Randall R. Stewart Tel: +1-847-632-7438 211 Motorola, Inc. EMail: rstewar1@email.mot.com 212 1501 W. Shure Drive, #2315 213 Arlington Heights, IL 60004 214 USA 216 Qiaobing Xie Tel: +1-847-632-3028 217 Motorola, Inc. EMail: qxie1@email.mot.com 218 1501 W. Shure Drive, #2309 219 Arlington Heights, IL 60004 220 USA 222 This draft expires in August 2000.