< draft-stewart-tsvwg-sctpipv6-00.txt		draft-stewart-tsvwg-sctpipv6-01.txt >
	Network Working Group R. R. Stewart		Network Working Group R. R. Stewart
	INTERNET-DRA S. Deering		INTERNET-DRAFT S. Deering
	Cisco		Cisco
	expires in six months June 1,2001		expires in six months April 10,2002
	IPv6 addressing and Stream Control Transmission Protocol		IPv6 addressing and Stream Control Transmission Protocol
	<draft-stewart-tsvwg-sctpipv6-00>		<draft-stewart-tsvwg-sctpipv6-01.txt>
	Status of This Memo		Status of This Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of [RFC2026]. Internet-Drafts are		all provisions of Section 10 of [RFC2026]. Internet-Drafts are
	working documents of the Internet Engineering Task Force (IETF), its		working documents of the Internet Engineering Task Force (IETF), its
	areas, and its working groups. Note that other groups may also		areas, and its working groups. Note that other groups may also
	distribute working documents as Internet-Drafts.		distribute working documents as Internet-Drafts.
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	skipping to change at line 49 ¶		skipping to change at page 2, line 4 ¶
	1. Introduction		1. Introduction
	Stream Control Transmission Protocol [RFC2960] provides transparent		Stream Control Transmission Protocol [RFC2960] provides transparent
	multi-homing to its upper layer users. This multi-homing is		multi-homing to its upper layer users. This multi-homing is
	accomplished through the passing of address parameters in the		accomplished through the passing of address parameters in the
	initial setup message used by SCTP. In an IPv4 network all addresses		initial setup message used by SCTP. In an IPv4 network all addresses
	are passed with no consideration for their scope and routeablility.		are passed with no consideration for their scope and routeablility.
	In a IPv6 network special considerations MUST be made to properly		In a IPv6 network special considerations MUST be made to properly
	bring up associations between SCTP endpoints that have IPv6		bring up associations between SCTP endpoints that have IPv6
	[RFC2460] addresses bound within their association. This document		[RFC2460] addresses bound within their association. This document
	defines those considerations and enumerates general rules		defines those considerations and enumerates general rules
	that an SCTP endpoint MUST use in formulating both the INIT and		that an SCTP endpoint MUST use in formulating both the INIT and
	INIT-ACK chunks.		INIT-ACK chunks.
	The emphasis in the rules laid out in this document are to prevent		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		an SCTP endpoint from listing an IPv6 address that is outside of its
	routeable scope to a peer endpoint. This will prevent black-hole		routeable scope to a peer endpoint. This will prevent black-hole
	conditions that may cause the unexpected failure of SCTP associations.		conditions that may cause the unexpected failure of SCTP associations.
	2. Conventions		2. Conventions
	The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,		The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
	SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when		SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
	they appear in this document, are to be interpreted as described in		they appear in this document, are to be interpreted as described in
	[RFC2119].		[RFC2119].
	3. Special rules for IPv6 address scoping		3. Special rules for IPv6 address scoping
	When selecting IPv6 addresses to include as parameters in the INIT		When the ULP requests establishment of an SCTP association to a
	chunk the following rules MUST be applied:		IPv6 destination address, the following considerations apply:
	A1) The INIT chunk SHOULD NOT include any IPv6 Link Local
	address parameters unless the source or destination address
	in the IPv6 header is a Link Local address.
	A2) If IPv6 Link Local address parameters are included in the
	INIT chunk, Link Local addresses that are NOT on the same
	physical Link as that of the destination or source
	IPv6 address (found in the IPv6 header) MUST NOT be included.
	A3) The INIT chunk SHOULD NOT include any IPv6 Site Local
	address parameters unless the source or destination address
	in the IPv6 header is a Site Local address.
	A4) If IPv6 Site Local addresses are included in the INIT chunk,
	Site Local address that are NOT on the same site MUST NOT
	be included.
	A5) If the destination and source address of the INIT is an		- the requested destination address will be accompanied
	IPv6 Global address then the sender SHOULD NOT include any		by a locally-significant "zone identifier" [scoped-addr-arch].
	Site Local or Link Local IPv6 address parameters in the
	INIT chunk.
	When responding to an INIT chunk and selecting IPv6 address		- the source address in the initial IPv6 packet (the packet
	parameters to be included in the INIT-ACK chunk, the following rules		carrying the INIT) MUST be an address belonging to the
	MUST be applied:		specified destination zone.
	B1) The INIT-ACK chunk SHOULD NOT include any IPv6 Link Local		- the INIT chunk MUST include all of, and only, the initiator's bound
	address parameters unless the source or destination address		addresses belonging to the destination zone and all larger,
	in the IPv6 header of the INIT chunk is a Link Local address.		encompassing zones, with the optional exception of the source address.
	B2) If IPv6 Link Local address parameters are included in the		The receiver of an INIT will identify the relevant zone by the
	INIT-ACK chunk, Link Local addresses that are NOT on the same		scope of the source address and the arrival interface. In
	physical Link as the source or destination address in the		choosing addresses to place in the INIT-ACK the following
	IPv6 header of the INIT chunk MUST NOT be included.		considerations apply:
	B3) The INIT-ACK chunk SHOULD NOT include any IPv6 Site Local		- the receiver of the INIT will use the locally-significant
	address parameters unless the source or destination address		"zone identifier" [scoped-addr-arch] to scope the addresses
	in the IPv6 header of the INIT chunk is a Site Local address.		listed in the INIT-ACK.
	B4) If IPv6 Site Local addresses are included in the INIT-ACK		- the source address in the initial IPv6 packet (the packet
	chunk, Site Local address that are NOT on the same site		carrying the INIT-ACK) MUST be an address belonging to the
	as the received INIT chunk MUST NOT be included.		destination zone.
	B5) If the destination and source address of the INIT is an		- the INIT-ACK chunk MUST include all of, and only, the initiator's
	IPv6 Global address then the sender SHOULD NOT include any		bound addresses belonging to the destination zone and all larger,
	Site Local or Link Local IPv6 address parameters in the		encompassing zones, with the optional exception of the source address.
	INIT-ACK chunk.
	4. Authors addresses		4. Authors addresses
	Randall R. Stewart		Randall R. Stewart
	24 Burning Bush Trail.		24 Burning Bush Trail.
	Crystal Lake, IL 60012		Crystal Lake, IL 60012
	USA		USA
	Phone: +1 815 477 2127		Phone: +1 815 477 2127
	EMail: rrs@cisco.com		EMail: rrs@cisco.com
	Stephen E. Deering		Stephen E. Deering
	Cisco Systems, Inc.		Cisco Systems, Inc.
	170 West Tasman Drive		170 West Tasman Drive
	skipping to change at line 153 ¶		skipping to change at page 3, line 36 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2460] S. Deering, R. Hinden, "Internet Protocol,		[RFC2460] S. Deering, R. Hinden, "Internet Protocol,
	Version 6 (IPv6) Specification." December 1998.		Version 6 (IPv6) Specification." December 1998.
	[RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp,		[RFC2960] R. R. Stewart, Q. Xie, K. Morneault, C. Sharp,
	H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang,		H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang,
	and, V. Paxson, "Stream Control Transmission Protocol," RFC		and, V. Paxson, "Stream Control Transmission Protocol," RFC
	2960, October 2000.		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.
End of changes. 15 change blocks.
	47 lines changed or deleted		28 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/