Network Working Group R. Stewart Internet-Draft Cisco Systems, Inc. Expires: November 14, 2002 M. Tuexen Siemens AG May 16, 2002 Stream Control Transmission Protocol (SCTP) IPv4 Address Scoping draft-stewart-tsvwg-sctp-ipv4-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 14, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Stream Control Transmission Protocol RFC2960 [5] provides transparent multi-homing to its upper layer users. This multi-homing is accomplished through the passing of address parameters in the initial setup message used by SCTP. In an IPv4 network addresses SHOULD NOT be passed without consideration of their routeablility. This document defines considerations and enumerates general rules that an SCTP endpoint MUST use in formulating both the INIT and INIT-ACK chunks when including IPv4 addresses. Stewart & Tuexen Expires November 14, 2002 [Page 1] Internet-Draft SCTP IPv4 Address Scoping May 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. IPv4 address scoping . . . . . . . . . . . . . . . . . . . . . 5 3.1 Classification of IPV4 addresses . . . . . . . . . . . . . . . 5 3.2 Black-hole scenario . . . . . . . . . . . . . . . . . . . . . 5 3.3 Address handling for INIT chunks . . . . . . . . . . . . . . . 5 3.4 Address handling for INIT-ACK chunks . . . . . . . . . . . . . 6 4. Security considerations . . . . . . . . . . . . . . . . . . . 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 Stewart & Tuexen Expires November 14, 2002 [Page 2] Internet-Draft SCTP IPv4 Address Scoping May 2002 1. Introduction Stream Control Transmission Protocol RFC2960 [5] provides transparent multi-homing to its upper layer users. This multi-homing is accomplished through the passing of address parameters in the initial setup message used by SCTP. In an IPv4 network addresses SHOULD NOT be passed without consideration of their routeablility. This document defines considerations and enumerates general rules that an SCTP endpoint MUST use in formulating both the INIT and INIT-ACK chunks when including IPv4 addresses. The emphasis in the rules laid out in this document are to prevent an SCTP endpoint from listing an IPv4 address that is not routeable to a peer endpoint. This will minimize black-hole conditions that may cause the unexpected failure of SCTP associations. Stewart & Tuexen Expires November 14, 2002 [Page 3] Internet-Draft SCTP IPv4 Address Scoping May 2002 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [4]. Stewart & Tuexen Expires November 14, 2002 [Page 4] Internet-Draft SCTP IPv4 Address Scoping May 2002 3. IPv4 address scoping 3.1 Classification of IPV4 addresses Several blocks of IP-addresses have been assigned by IANA for special use. See IANA-SPECIAL-IPV4 [1] for further details. In this document the IPv4 addresses are divided into several different levels: Level 0: Addresses unusable with SCTP: 0.0.0.0/8, 224.0.0.0/4, 198.18.0.0/24, 192.88.99.0/24. Level 1: Loopback addresses: 127.0.0.0/8. Level 2: Link-local addresses: 169.254.0.0/16. Level 3: Private addresses: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/ 16. Level 4: Global addresses. Addresses of Level 0 MUST not be used o as a source address of a SCTP packet. o as a destination address of a SCTP packet. o within an address parameter of an INIT, INIT-ACK chunk. 3.2 Black-hole scenario A black-hole condition is where some other host is using the same address. In a IPv4 network this COULD happen if an INIT was sent to a global address that listed private addresses. If the peer also has a separate private based addressing it MAY send a heartbeat to an internal peer using the address listed. This causes the internal peer to send an ABORT thus destroying the association. The rules given in the next two sections for address handling will minimize the risk of having a black-hole condition. 3.3 Address handling for INIT chunks When the ULP requests establishment of an SCTP association to a IPv4 destination address, the following considerations apply: Stewart & Tuexen Expires November 14, 2002 [Page 5] Internet-Draft SCTP IPv4 Address Scoping May 2002 o Let L be the level of the requested destination address. Therefore L > 0 holds. o The sender of the INIT chunk SHOULD include all of its addresses with level greater than or equal to L in the outgoing INIT chunk. o The sender of the INIT chunk SHOULD NOT include all of its addresses with level smaller than L in the outgoing INIT chunk. Note that by listing both private and global addresses to a peer that does NOT have any global address the peer may find the senders global address unreachable. This is not a problem however since it would NOT cause a black-hole condition. 3.4 Address handling for INIT-ACK chunks The receiver of an INIT will identify the relevant address level by examining the source address of the SCTP packet. In choosing addresses to place in the INIT-ACK the following considerations apply: o Let L be the level of the received source address of the INIT chunk. Therefore L > 0 holds. o The sender of the INIT-ACK chunk SHOULD include all of its addresses with level greater than or equal to L in the outgoing INIT-ACK chunk. o The sender of the INIT-ACK chunk SHOULD NOT include all of its addresses with level smaller than L in the outgoing INIT-ACK chunk. Note that it is possible that a sender of an INIT incorrectly places addresses within its INIT. To protect against this the receiver of the INIT SHOULD examine carefully each address. If the level of an address listed is less than the level of the received source address, the address SHOULD be discarded and not put into the cookie parameter. Stewart & Tuexen Expires November 14, 2002 [Page 6] Internet-Draft SCTP IPv4 Address Scoping May 2002 4. Security considerations This document does not add any security risks other than those already found in RFC2960 [5] Stewart & Tuexen Expires November 14, 2002 [Page 7] Internet-Draft SCTP IPv4 Address Scoping May 2002 References [1] IANA, I., "Special-Use IPv4 Addresses", draft-iana-special-ipv4- 03 (work in progress), April 2002. [2] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. Authors' Addresses Randall R. Stewart Cisco Systems, Inc. 8725 West Higgins Road Suite 300 Chicago, IL 60631 USA Phone: +1-815-477-2127 EMail: rrs@cisco.com Michael Tuexen Siemens AG ICN WN CC SE 7 D-81359 Munich Germany Phone: +49 89 722 47210 EMail: Michael.Tuexen@icn.siemens.de Stewart & Tuexen Expires November 14, 2002 [Page 8] Internet-Draft SCTP IPv4 Address Scoping May 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Stewart & Tuexen Expires November 14, 2002 [Page 9]