idnits 2.17.1 draft-stewart-tsvwg-sctp-ipv4-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: ---------------------------------------------------------------------------- == 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. ** The abstract seems to contain references ([5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Addresses of Level 0 MUST not be used -- 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.) -- The document date (May 16, 2002) is 8016 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 182, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 186, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-iana-special-ipv4-03 ** Downref: Normative reference to an Informational draft: draft-iana-special-ipv4 (ref. '1') ** Obsolete normative reference: RFC 2960 (ref. '5') (Obsoleted by RFC 4960) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Stewart 3 Internet-Draft Cisco Systems, Inc. 4 Expires: November 14, 2002 M. Tuexen 5 Siemens AG 6 May 16, 2002 8 Stream Control Transmission Protocol (SCTP) IPv4 Address Scoping 9 draft-stewart-tsvwg-sctp-ipv4-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 14, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 Stream Control Transmission Protocol RFC2960 [5] provides transparent 41 multi-homing to its upper layer users. This multi-homing is 42 accomplished through the passing of address parameters in the initial 43 setup message used by SCTP. In an IPv4 network addresses SHOULD NOT 44 be passed without consideration of their routeablility. This 45 document defines considerations and enumerates general rules that an 46 SCTP endpoint MUST use in formulating both the INIT and INIT-ACK 47 chunks when including IPv4 addresses. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. IPv4 address scoping . . . . . . . . . . . . . . . . . . . . . 5 54 3.1 Classification of IPV4 addresses . . . . . . . . . . . . . . . 5 55 3.2 Black-hole scenario . . . . . . . . . . . . . . . . . . . . . 5 56 3.3 Address handling for INIT chunks . . . . . . . . . . . . . . . 5 57 3.4 Address handling for INIT-ACK chunks . . . . . . . . . . . . . 6 58 4. Security considerations . . . . . . . . . . . . . . . . . . . 7 59 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 61 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 63 1. Introduction 65 Stream Control Transmission Protocol RFC2960 [5] provides transparent 66 multi-homing to its upper layer users. This multi-homing is 67 accomplished through the passing of address parameters in the initial 68 setup message used by SCTP. In an IPv4 network addresses SHOULD NOT 69 be passed without consideration of their routeablility. This 70 document defines considerations and enumerates general rules that an 71 SCTP endpoint MUST use in formulating both the INIT and INIT-ACK 72 chunks when including IPv4 addresses. 74 The emphasis in the rules laid out in this document are to prevent an 75 SCTP endpoint from listing an IPv4 address that is not routeable to a 76 peer endpoint. This will minimize black-hole conditions that may 77 cause the unexpected failure of SCTP associations. 79 2. Conventions 81 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 82 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 83 they appear in this document, are to be interpreted as described in 84 RFC2119 [4]. 86 3. IPv4 address scoping 88 3.1 Classification of IPV4 addresses 90 Several blocks of IP-addresses have been assigned by IANA for special 91 use. See IANA-SPECIAL-IPV4 [1] for further details. 93 In this document the IPv4 addresses are divided into several 94 different levels: 96 Level 0: Addresses unusable with SCTP: 0.0.0.0/8, 224.0.0.0/4, 97 198.18.0.0/24, 192.88.99.0/24. 99 Level 1: Loopback addresses: 127.0.0.0/8. 101 Level 2: Link-local addresses: 169.254.0.0/16. 103 Level 3: Private addresses: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/ 104 16. 106 Level 4: Global addresses. 108 Addresses of Level 0 MUST not be used 110 o as a source address of a SCTP packet. 112 o as a destination address of a SCTP packet. 114 o within an address parameter of an INIT, INIT-ACK chunk. 116 3.2 Black-hole scenario 118 A black-hole condition is where some other host is using the same 119 address. In a IPv4 network this COULD happen if an INIT was sent to 120 a global address that listed private addresses. If the peer also has 121 a separate private based addressing it MAY send a heartbeat to an 122 internal peer using the address listed. This causes the internal 123 peer to send an ABORT thus destroying the association. 125 The rules given in the next two sections for address handling will 126 minimize the risk of having a black-hole condition. 128 3.3 Address handling for INIT chunks 130 When the ULP requests establishment of an SCTP association to a IPv4 131 destination address, the following considerations apply: 133 o Let L be the level of the requested destination address. 134 Therefore L > 0 holds. 136 o The sender of the INIT chunk SHOULD include all of its addresses 137 with level greater than or equal to L in the outgoing INIT chunk. 139 o The sender of the INIT chunk SHOULD NOT include all of its 140 addresses with level smaller than L in the outgoing INIT chunk. 142 Note that by listing both private and global addresses to a peer that 143 does NOT have any global address the peer may find the senders global 144 address unreachable. This is not a problem however since it would 145 NOT cause a black-hole condition. 147 3.4 Address handling for INIT-ACK chunks 149 The receiver of an INIT will identify the relevant address level by 150 examining the source address of the SCTP packet. In choosing 151 addresses to place in the INIT-ACK the following considerations 152 apply: 154 o Let L be the level of the received source address of the INIT 155 chunk. Therefore L > 0 holds. 157 o The sender of the INIT-ACK chunk SHOULD include all of its 158 addresses with level greater than or equal to L in the outgoing 159 INIT-ACK chunk. 161 o The sender of the INIT-ACK chunk SHOULD NOT include all of its 162 addresses with level smaller than L in the outgoing INIT-ACK 163 chunk. 165 Note that it is possible that a sender of an INIT incorrectly places 166 addresses within its INIT. To protect against this the receiver of 167 the INIT SHOULD examine carefully each address. If the level of an 168 address listed is less than the level of the received source address, 169 the address SHOULD be discarded and not put into the cookie 170 parameter. 172 4. Security considerations 174 This document does not add any security risks other than those 175 already found in RFC2960 [5] 177 References 179 [1] IANA, I., "Special-Use IPv4 Addresses", draft-iana-special-ipv4- 180 03 (work in progress), April 2002. 182 [2] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. 183 Lear, "Address Allocation for Private Internets", BCP 5, RFC 184 1918, February 1996. 186 [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 187 9, RFC 2026, October 1996. 189 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 190 Levels", BCP 14, RFC 2119, March 1997. 192 [5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, 193 H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 194 "Stream Control Transmission Protocol", RFC 2960, October 2000. 196 Authors' Addresses 198 Randall R. Stewart 199 Cisco Systems, Inc. 200 8725 West Higgins Road 201 Suite 300 202 Chicago, IL 60631 203 USA 205 Phone: +1-815-477-2127 206 EMail: rrs@cisco.com 208 Michael Tuexen 209 Siemens AG 210 ICN WN CC SE 7 211 D-81359 Munich 212 Germany 214 Phone: +49 89 722 47210 215 EMail: Michael.Tuexen@icn.siemens.de 217 Full Copyright Statement 219 Copyright (C) The Internet Society (2002). All Rights Reserved. 221 This document and translations of it may be copied and furnished to 222 others, and derivative works that comment on or otherwise explain it 223 or assist in its implementation may be prepared, copied, published 224 and distributed, in whole or in part, without restriction of any 225 kind, provided that the above copyright notice and this paragraph are 226 included on all such copies and derivative works. However, this 227 document itself may not be modified in any way, such as by removing 228 the copyright notice or references to the Internet Society or other 229 Internet organizations, except as needed for the purpose of 230 developing Internet standards in which case the procedures for 231 copyrights defined in the Internet Standards process must be 232 followed, or as required to translate it into languages other than 233 English. 235 The limited permissions granted above are perpetual and will not be 236 revoked by the Internet Society or its successors or assigns. 238 This document and the information contained herein is provided on an 239 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 240 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 241 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 242 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 243 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 245 Acknowledgement 247 Funding for the RFC Editor function is currently provided by the 248 Internet Society.