idnits 2.17.1 draft-stewart-tsvwg-sctpipv6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 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. 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == 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 a Security Considerations section. ** 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 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC2460], [RFC2960]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == 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). -- 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. R. Stewart 2 INTERNET-DRAFT S. Deering 3 Cisco 5 expires in six months April 10,2002 7 IPv6 addressing and Stream Control Transmission Protocol 8 10 Status of This Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of [RFC2026]. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 The list of current Internet-Drafts can be accessed at 19 http://www.ietf.org/ietf/1id-abstracts.txt 21 The list of Internet-Draft Shadow Directories can be accessed at 22 http://www.ietf.org/shadow.html. 24 Abstract 26 Stream Control Transmission Protocol [RFC2960] provides transparent 27 multi-homing to its upper layer users. This multi-homing is 28 accomplished through the passing of address parameters in the 29 initial setup message used by SCTP. In an IPv4 network all addresses 30 are passed with no consideration for their scope and routeablility. 31 In a IPv6 network special considerations MUST be made to properly 32 bring up associations between SCTP endpoints that have IPv6 33 [RFC2460] addresses bound within their association. This document 34 defines those considerations and enumerates general rules 35 that an SCTP endpoint MUST use in formulating both the INIT and 36 INIT-ACK chunks. 38 Table Of Contents 40 1. Introduction 42 Stream Control Transmission Protocol [RFC2960] provides transparent 43 multi-homing to its upper layer users. This multi-homing is 44 accomplished through the passing of address parameters in the 45 initial setup message used by SCTP. In an IPv4 network all addresses 46 are passed with no consideration for their scope and routeablility. 47 In a IPv6 network special considerations MUST be made to properly 48 bring up associations between SCTP endpoints that have IPv6 50 [RFC2460] addresses bound within their association. This document 51 defines those considerations and enumerates general rules 52 that an SCTP endpoint MUST use in formulating both the INIT and 53 INIT-ACK chunks. 55 The emphasis in the rules laid out in this document are to prevent 56 an SCTP endpoint from listing an IPv6 address that is outside of its 57 routeable scope to a peer endpoint. This will prevent black-hole 58 conditions that may cause the unexpected failure of SCTP associations. 60 2. Conventions 62 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 63 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 64 they appear in this document, are to be interpreted as described in 65 [RFC2119]. 67 3. Special rules for IPv6 address scoping 69 When the ULP requests establishment of an SCTP association to a 70 IPv6 destination address, the following considerations apply: 72 - the requested destination address will be accompanied 73 by a locally-significant "zone identifier" [scoped-addr-arch]. 75 - the source address in the initial IPv6 packet (the packet 76 carrying the INIT) MUST be an address belonging to the 77 specified destination zone. 79 - the INIT chunk MUST include all of, and only, the initiator's bound 80 addresses belonging to the destination zone and all larger, 81 encompassing zones, with the optional exception of the source address. 83 The receiver of an INIT will identify the relevant zone by the 84 scope of the source address and the arrival interface. In 85 choosing addresses to place in the INIT-ACK the following 86 considerations apply: 88 - the receiver of the INIT will use the locally-significant 89 "zone identifier" [scoped-addr-arch] to scope the addresses 90 listed in the INIT-ACK. 92 - the source address in the initial IPv6 packet (the packet 93 carrying the INIT-ACK) MUST be an address belonging to the 94 destination zone. 96 - the INIT-ACK chunk MUST include all of, and only, the initiator's 97 bound addresses belonging to the destination zone and all larger, 98 encompassing zones, with the optional exception of the source address. 100 4. Authors addresses 101 Randall R. Stewart 102 24 Burning Bush Trail. 103 Crystal Lake, IL 60012 104 USA 105 Phone: +1 815 477 2127 106 EMail: rrs@cisco.com 108 Stephen E. Deering 109 Cisco Systems, Inc. 110 170 West Tasman Drive 111 San Jose, CA 95134-1706 112 USA 114 Phone: +1 408 527 8213 115 Fax: +1 408 527 8254 116 EMail: deering@cisco.com 118 5. References 120 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 121 3", BCP 9, RFC 2026, October 1996. 123 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 124 Requirement Levels", BCP 14, RFC 2119, March 1997. 126 [RFC2460] S. Deering, R. Hinden, "Internet Protocol, 127 Version 6 (IPv6) Specification." December 1998. 129 [RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, 130 H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, 131 and, V. Paxson, "Stream Control Transmission Protocol," RFC 132 2960, October 2000. 134 [scoped-addr-arch] S. Deering, B. Haberman, T Jinmei, E Nordmark, 135 A Onoe, B Zill, "IPv6 Scoped Address Architecture", 136 Work In Progress, November 2001.