One document matched: draft-stewart-tsvwg-sctpipv6-01.txt

Differences from draft-stewart-tsvwg-sctpipv6-00.txt

Network Working Group                                     R. R. Stewart
INTERNET-DRAFT                                               S. Deering
                                                                  Cisco

expires in six months                                     April 10,2002



         IPv6 addressing and Stream Control Transmission Protocol 
                   <draft-stewart-tsvwg-sctpipv6-01.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.

    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.

Abstract

    Stream Control Transmission Protocol [RFC2960] 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 all addresses
    are passed with no consideration for their scope and routeablility.
    In a IPv6 network special considerations MUST be made to properly
    bring up associations between SCTP endpoints that have IPv6
    [RFC2460] addresses bound within their association.  This document
    defines those considerations and enumerates general rules
    that an SCTP endpoint MUST use in formulating both the INIT and
    INIT-ACK chunks.


Table Of Contents




1. Introduction


    Stream Control Transmission Protocol [RFC2960] 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 all addresses
    are passed with no consideration for their scope and routeablility.
    In a IPv6 network special considerations MUST be made to properly
    bring up associations between SCTP endpoints that have IPv6

Stewart, Deering                                                [Page 1]

Internet Draft            IPv6 addressing and SCTP            April 2002

    [RFC2460] addresses bound within their association.  This document
    defines those considerations and enumerates general rules
    that an SCTP endpoint MUST use in formulating both the INIT and
    INIT-ACK chunks.

    The emphasis in the rules laid out in this document are to prevent
    an SCTP endpoint from listing an IPv6 address that is outside of its
    routeable scope to a peer endpoint. This will prevent black-hole
    conditions that may cause the unexpected failure of SCTP associations.

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].


3. Special rules for IPv6 address scoping

    When the ULP requests establishment of an SCTP association to a
    IPv6 destination address, the following considerations apply:

    - the requested destination address will be accompanied
      by a locally-significant "zone identifier" [scoped-addr-arch].

    - the source address in the initial IPv6 packet (the packet
      carrying the INIT) MUST be an address belonging to the 
      specified destination zone.

    - the INIT chunk MUST include all of, and only, the initiator's bound
      addresses belonging to the destination zone and all larger,
      encompassing zones, with the optional exception of the source address.


    The receiver of an INIT will identify the relevant zone by the 
    scope of the source address and the arrival interface. In
    choosing addresses to place in the INIT-ACK the following 
    considerations apply:

    - the receiver of the INIT will use the locally-significant 
      "zone identifier" [scoped-addr-arch] to scope the addresses
      listed in the INIT-ACK.

    - the source address in the initial IPv6 packet (the packet
      carrying the INIT-ACK) MUST be an address belonging to the 
      destination zone. 

    - the INIT-ACK chunk MUST include all of, and only, the initiator's 
      bound addresses belonging to the destination zone and all larger,
      encompassing zones, with the optional exception of the source address.


4. Authors addresses

Stewart, Deering                                                [Page 2]

Internet Draft            IPv6 addressing and SCTP            April 2002



   Randall R. Stewart
   24 Burning Bush Trail.
   Crystal Lake, IL 60012
   USA
   Phone: +1 815 477 2127
   EMail: rrs@cisco.com

   Stephen E. Deering
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134-1706
   USA

   Phone: +1 408 527 8213
   Fax:   +1 408 527 8254
   EMail: deering@cisco.com


5. References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  S. Deering, R. Hinden, "Internet Protocol, 
              Version 6 (IPv6) Specification." December 1998.

   [RFC2960]  R. R. Stewart, Q. Xie, K. Morneault, C. Sharp,
              H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang,
              and, V. Paxson, "Stream Control Transmission Protocol," RFC
              2960, October 2000.

   [scoped-addr-arch] S. Deering, B. Haberman, T Jinmei, E Nordmark,
                      A Onoe, B Zill, "IPv6 Scoped Address Architecture",
                      Work In Progress, November 2001.
















Stewart, Deering                                                [Page 3]