draft-ietf-tsvwg-addip-sctp-09.txt   draft-ietf-tsvwg-addip-sctp-10.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft M. Ramalho Internet-Draft M. Ramalho
Expires: December 9, 2004 Cisco Systems, Inc. Expires: July 31, 2005 Cisco Systems, Inc.
Q. Xie Q. Xie
Motorola, Inc. Motorola, Inc.
M. Tuexen M. Tuexen
Univ. of Applied Sciences Muenster Univ. of Applied Sciences Muenster
P. Conrad P. Conrad
University of Delaware University of Delaware
June 10, 2004 January 28, 2005
Stream Control Transmission Protocol (SCTP) Dynamic Address Stream Control Transmission Protocol (SCTP) Dynamic Address
Reconfiguration Reconfiguration
draft-ietf-tsvwg-addip-sctp-09.txt draft-ietf-tsvwg-addip-sctp-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of Section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 9, 2004. This Internet-Draft will expire on July 31, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes extensions to the Stream Control Transmission This document describes extensions to the Stream Control Transmission
Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP Protocol (SCTP) [RFC2960] that provides a method to reconfigure IP
address information on an existing association. address information on an existing association.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Additional Chunks and Parameters . . . . . . . . . . . . . . . 5 3. Additional Chunks and Parameters . . . . . . . . . . . . . . . 6
3.1 New Chunk Types . . . . . . . . . . . . . . . . . . . . . 5 3.1 New Chunk Types . . . . . . . . . . . . . . . . . . . . . 6
3.1.1 Address Configuration Change Chunk (ASCONF) . . . . . 5 3.1.1 Address Configuration Change Chunk (ASCONF) . . . . . 6
3.1.2 Address Configuration Acknowledgment Chunk 3.1.2 Address Configuration Acknowledgment Chunk
(ASCONF-ACK) . . . . . . . . . . . . . . . . . . . . . 6 (ASCONF-ACK) . . . . . . . . . . . . . . . . . . . . . 7
3.2 New Parameter Types . . . . . . . . . . . . . . . . . . . 7 3.2 New Parameter Types . . . . . . . . . . . . . . . . . . . 8
3.2.1 Add IP Address . . . . . . . . . . . . . . . . . . . . 8 3.2.1 Add IP Address . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Delete IP Address . . . . . . . . . . . . . . . . . . 9 3.2.2 Delete IP Address . . . . . . . . . . . . . . . . . . 10
3.2.3 Error Cause Indication . . . . . . . . . . . . . . . . 10 3.2.3 Error Cause Indication . . . . . . . . . . . . . . . . 11
3.2.4 Set Primary IP Address . . . . . . . . . . . . . . . . 11 3.2.4 Set Primary IP Address . . . . . . . . . . . . . . . . 12
3.2.5 Success Indication . . . . . . . . . . . . . . . . . . 12 3.2.5 Success Indication . . . . . . . . . . . . . . . . . . 13
3.2.6 Adaptation Layer Indication . . . . . . . . . . . . . 12 3.2.6 Adaptation Layer Indication . . . . . . . . . . . . . 13
3.3 New Error Causes . . . . . . . . . . . . . . . . . . . . . 13 3.3 New Error Causes . . . . . . . . . . . . . . . . . . . . . 14
3.3.1 Error Cause: Request to Delete Last Remaining IP 3.3.1 Error Cause: Request to Delete Last Remaining IP
Address . . . . . . . . . . . . . . . . . . . . . . . 13 Address . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.2 Error Cause: Operation Refused Due to Resource 3.3.2 Error Cause: Operation Refused Due to Resource
Shortage . . . . . . . . . . . . . . . . . . . . . . . 14 Shortage . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.3 Error Cause: Request to Delete Source IP Address . . . 15 3.3.3 Error Cause: Request to Delete Source IP Address . . . 16
3.3.4 Error Cause: Association Aborted due to illegal 3.3.4 Error Cause: Association Aborted due to illegal
ASCONF-ACK . . . . . . . . . . . . . . . . . . . . . . 16 ASCONF-ACK . . . . . . . . . . . . . . . . . . . . . . 17
3.3.5 Error Cause: Request refused - no authorization. . . . 16 3.3.5 Error Cause: Request refused - no authorization. . . . 17
4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1 ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . 18 4.1 ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . 19
4.1.1 Congestion Control of ASCONF Chunks . . . . . . . . . 19 4.1.1 Congestion Control of ASCONF Chunks . . . . . . . . . 20
4.2 Upon reception of an ASCONF Chunk. . . . . . . . . . . . . 20 4.2 Upon reception of an ASCONF Chunk. . . . . . . . . . . . . 21
4.3 General rules for address manipulation . . . . . . . . . . 22 4.3 General rules for address manipulation . . . . . . . . . . 23
4.3.1 A special case for OOTB ABORT chunks . . . . . . . . . 25 4.3.1 A special case for OOTB ABORT chunks . . . . . . . . . 26
4.3.2 A special case for changing an address. . . . . . . . 25 4.3.2 A special case for changing an address. . . . . . . . 26
4.4 Setting of the primary address . . . . . . . . . . . . . . 26 4.4 Setting of the primary address . . . . . . . . . . . . . . 27
5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 28 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
A. Abstract Address Handling . . . . . . . . . . . . . . . . . . 31 A. Abstract Address Handling . . . . . . . . . . . . . . . . . . 32
A.1 General remarks . . . . . . . . . . . . . . . . . . . . . 31 A.1 General remarks . . . . . . . . . . . . . . . . . . . . . 32
A.2 Generalized endpoints . . . . . . . . . . . . . . . . . . 31 A.2 Generalized endpoints . . . . . . . . . . . . . . . . . . 32
A.3 Associations . . . . . . . . . . . . . . . . . . . . . . . 32 A.3 Associations . . . . . . . . . . . . . . . . . . . . . . . 33
A.4 Relationship with RFC 2960 . . . . . . . . . . . . . . . . 32 A.4 Relationship with RFC 2960 . . . . . . . . . . . . . . . . 33
A.5 Rules for address manipulation . . . . . . . . . . . . . . 33 A.5 Rules for address manipulation . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . 35
1. Introduction 1. Introduction
To extend the utility and application scenarios of SCTP, this To extend the utility and application scenarios of SCTP, this
document introduces optional extensions that provide SCTP with the document introduces optional extensions that provide SCTP with the
ability to: ability to:
1. reconfigure IP address information on an existing association. 1. reconfigure IP address information on an existing association.
2. set the remote primary path. 2. set the remote primary path.
3. exchange adaptation layer information during association setup. 3. exchange adaptation layer information during association setup.
These extensions enable SCTP to be utilized in the following These extensions enable SCTP to be utilized in the following
applications: applications:
1. For computational or networking platforms that allow addition/ 1. For computational or networking platforms that allow
removal of physical interface cards this feature can provide a addition/removal of physical interface cards this feature can
graceful method to add to the interfaces of an existing provide a graceful method to add to the interfaces of an existing
association. For IPv6 this feature allows renumbering of association. For IPv6 this feature allows renumbering of
existing associations. existing associations.
2. This provides a method for an endpoint to request that its peer 2. This provides a method for an endpoint to request that its peer
set its primary destination address. This can be useful when an set its primary destination address. This can be useful when an
address is about to be deleted, or when an endpoint has some address is about to be deleted, or when an endpoint has some
predetermined knowledge about which is the preferred address to predetermined knowledge about which is the preferred address to
receive SCTP packets upon. receive SCTP packets upon.
3. This feature can be used to extend the usability of SCTP without 3. This feature can be used to extend the usability of SCTP without
modifying it by allowing endpoints to exchange some information modifying it by allowing endpoints to exchange some information
during association setup. during association setup.
skipping to change at page 5, line 46 skipping to change at page 6, line 46
section 3.2, setting these upper bits in this manner will cause the section 3.2, setting these upper bits in this manner will cause the
receiver that does not understand this chunk to skip the chunk and receiver that does not understand this chunk to skip the chunk and
continue processing, but report in an Operation Error Chunk using the continue processing, but report in an Operation Error Chunk using the
'Unrecognized Chunk Type' cause of error. 'Unrecognized Chunk Type' cause of error.
3.1.1 Address Configuration Change Chunk (ASCONF) 3.1.1 Address Configuration Change Chunk (ASCONF)
This chunk is used to communicate to the remote endpoint one of the This chunk is used to communicate to the remote endpoint one of the
configuration change requests that MUST be acknowledged. The configuration change requests that MUST be acknowledged. The
information carried in the ASCONF Chunk uses the form of a information carried in the ASCONF Chunk uses the form of a
Type-Length-Value (TLV), as described in "3.2.1 Optional/ Type-Length-Value (TLV), as described in "3.2.1
Variable-length Parameter Format" in RFC2960 [6], for all variable Optional/Variable-length Parameter Format" in RFC2960 [6], for all
parameters. variable parameters.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xC1 | Chunk Flags | Chunk Length | | Type = 0xC1 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Serial Number | | Serial Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter | | Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 29, line 15 skipping to change at page 30, line 15
7. Acknowledgments 7. Acknowledgments
The authors wish to thank Jon Berger, Greg Kendall, Seok Koh, Peter The authors wish to thank Jon Berger, Greg Kendall, Seok Koh, Peter
Lei, John Loughney, Ivan Arias Rodriguez, Renee Revis, Marshall Rose, Lei, John Loughney, Ivan Arias Rodriguez, Renee Revis, Marshall Rose,
and Chip Sharp for their invaluable comments. and Chip Sharp for their invaluable comments.
The authors would also like to give special mention to Maria-Carmen The authors would also like to give special mention to Maria-Carmen
Belinchon and Ian Rytina for there early contributions to this Belinchon and Ian Rytina for there early contributions to this
document and their thoughtful comments. document and their thoughtful comments.
8 References 8. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP [1] Bradner, S., "The Internet Standards Process -- Revision 3",
9, RFC 2026, October 1996. BCP 9, RFC 2026, October 1996.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, [3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998. November 1998.
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
skipping to change at page 29, line 40 skipping to change at page 30, line 40
1999. 1999.
[6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
Authors' Addresses Authors' Addresses
Randall R. Stewart Randall R. Stewart
Cisco Systems, Inc. Cisco Systems, Inc.
8725 West Higgins Road 4875 Forest Drive
Suite 300 Suite 200
Chicago, IL 60631 Columbia, SC 29206
USA USA
Phone: +1-815-477-2127 Phone:
EMail: rrs@cisco.com Email: rrs@cisco.com
Michael A. Ramalho Michael A. Ramalho
Cisco Systems, Inc. Cisco Systems, Inc.
1802 Rue de la Porte 1802 Rue de la Porte
Wall Township, NJ 07719-3784 Wall Township, NJ 07719-3784
USA USA
Phone: +1.732.449.5762 Phone: +1.732.449.5762
EMail: mramalho@cisco.com Email: mramalho@cisco.com
Qiaobing Xie Qiaobing Xie
Motorola, Inc. Motorola, Inc.
1501 W. Shure Drive, #2309 1501 W. Shure Drive, #2309
Arlington Heights, IL 60004 Arlington Heights, IL 60004
USA USA
Phone: +1-847-632-3028 Phone: +1-847-632-3028
EMail: qxie1@email.mot.com Email: qxie1@email.mot.com
Michael Tuexen Michael Tuexen
Univ. of Applied Sciences Muenster Univ. of Applied Sciences Muenster
Stegerwaldstr. 39 Stegerwaldstr. 39
48565 Steinfurt 48565 Steinfurt
Germany Germany
EMail: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
Phillip T. Conrad Phillip T. Conrad
University of Delaware University of Delaware
Department of Computer and Information Sciences Department of Computer and Information Sciences
Newark, DE 19716 Newark, DE 19716
US US
Phone: +1 302 831 8622 Phone: +1 302 831 8622
EMail: conrad@acm.org Email: conrad@acm.org
URI: http://www.cis.udel.edu/~pconrad URI: http://www.cis.udel.edu/~pconrad
Appendix A. Abstract Address Handling Appendix A. Abstract Address Handling
A.1 General remarks A.1 General remarks
The following text provides a working definition of the endpoint The following text provides a working definition of the endpoint
notion to discuss address reconfiguration. It is not intended to notion to discuss address reconfiguration. It is not intended to
restrict implementations in any way, its goal is to provide as set of restrict implementations in any way, its goal is to provide as set of
definitions only. Using these definitions should make a discussion definitions only. Using these definitions should make a discussion
skipping to change at page 34, line 41 skipping to change at page 35, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/