Multihoming IPV6 Working group L. Coene Internet-Draft Siemens Expires: July 30, 2004 J. Loughney Nokia January 30, 2004 Multihoming: the SCTP solution 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 July 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes the multhoming solution used in SCTP. It tries to answer the questions posed in "Things MULTI6 developers should think about" [1]. Coene & Loughney Expires July 30, 2004 [Page 1] Internet-Draft Multi6 SCTP solution January 2004 Table of Contents 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Answer to Questions . . . . . . . . . . . . . . . . . . . 4 2.1 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1 How does SCTP solve the multihoming problem . . . . . . . 4 2.1.2 Uniqueness . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Identifiers and locators . . . . . . . . . . . . . . . . . 5 2.2.1 Does SCTP provide a split between identifier and locator? . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2 What is the lifetime of a binding from locator to identifier? . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.3 How is the binding updated? . . . . . . . . . . . . . . . 5 2.3 On the Wire . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1 At what layer is SCTP applied to? . . . . . . . . . . . . 5 2.3.2 Why is this layer the correct one? . . . . . . . . . . . . 5 2.3.3 Does SCTP expand the size of a IP packet? . . . . . . . . 6 2.3.4 Does SCTP change the way fragmenting is handled? . . . . . 6 2.3.5 Are there any changes to ICMP error semantics? . . . . . . 6 2.4 Names, hosts, endpoints? . . . . . . . . . . . . . . . . . 6 2.4.1 Relation of SCTP to DNS . . . . . . . . . . . . . . . . . 6 2.4.2 Interaction of SCTP with 2-faced DNS. . . . . . . . . . . 6 2.4.3 Does SCTP require a centralized registration? . . . . . . 6 2.4.4 Has SCTP checked for DNS circular dependencies? . . . . . 6 2.4.5 What happens if the DNS server itself is multihomed? . . . 6 2.4.6 What application/API changes are needed? . . . . . . . . . 7 2.4.7 Is this backward compatible with IPv6? . . . . . . . . . . 7 2.4.8 Is this backward compatible with IPV4? . . . . . . . . . . 7 2.4.9 What are the interactions with other middleboxes? . . . . 7 2.4.10 Implications of SCTP for scoped addressing . . . . . . . . 7 2.4.11 Implications of SCTP with layer2? . . . . . . . . . . . . 7 2.4.12 SCTP and referrals? . . . . . . . . . . . . . . . . . . . 8 2.4.13 Legal stuff . . . . . . . . . . . . . . . . . . . . . . . 8 3. Security considerations . . . . . . . . . . . . . . . . . 9 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . 13 Coene & Loughney Expires July 30, 2004 [Page 2] Internet-Draft Multi6 SCTP solution January 2004 1. INTRODUCTION SCTP is a transport protocol which among its features offers support for multihoming. The mechanism is described in detail in "RFC2960" [2]. A more general description of its uses can be found in "RFC3257" [4] and "SCTP multihoming Issues" [3]. 1.1 Terminology The terms are commonly identified in related work "RFC2960" [2], "RFC3257" [4] and "SCTP multihoming Issues" [3] . Coene & Loughney Expires July 30, 2004 [Page 3] Internet-Draft Multi6 SCTP solution January 2004 2. Answer to Questions 2.1 Routing 2.1.1 How does SCTP solve the multihoming problem A general overview of the solution can be found in "SCTP multihoming Issues" [3] in paragraph 2.1. The detail message elments with their syntax and semantics can be found in "RFC2960" [2]. The present solution allows for the exchange of the multiple addresses of each endpoint at the start of the association. Once the association has been set up, then heartbeat messages are used to check the reachability of each address. If the reachability test fails(because the heartbeat went unanswered for X times(with X = 1..n)), then that particular address is deemed not reachable and will NOT be used to send data on. If the reachability test is successfull, then the address may be used to send data to. If changeover is requested(by the application or by SCTP itself), then this address will be used to send data on. No IP address can be added or deleted from to association once it has been setup. A extension to SCTP is in the works which allows a already active SCTP association to add or delete a IP address [5] to a association.(Thus new "paths" are added or removed). The association will use this addresses based on the reachability information obtained by the use of the SCTP heartbeat just as mentioned above. An additional extension allows to secure this sort of ADDDELIP msg exchange via the use of Purpose Built keys(PBK) [7]. If a more secure association is required, then TLS or IPSEC are recommended. 2.1.2 Uniqueness 2.1.2.1 Does SCTP address mobility? SCTP does NOT solve the "where is the endpoint?" problem. It assumes that the location of the mobile user is known, because it has a IP address(which is the locator). It will try to setup a association with that IP address and exchange IP addresses between the two endpoints of the association at the start of the association(as in RFC 2960) or during the association lifetime(ADDELIP) [5]. SCTP does solve the "handover" problem, namely the problem of moving the traffic through the association from one IP address to another IP address. The new address can be the result of a DHCP request by the lower layers, renumbering in IPv6... Coene & Loughney Expires July 30, 2004 [Page 4] Internet-Draft Multi6 SCTP solution January 2004 Mobility in SCTP is only a byproduct of putting in multihoming in SCTP. SCTP can be used for mobility if add or delete a IP address [5] is implemented. 2.2 Identifiers and locators 2.2.1 Does SCTP provide a split between identifier and locator? Not really. SCTP uses the IP address as the locator but the identifier is assumed to be implicit. SCTP do NOT exchange any identifier between the peer endpoints, only IP addresses are exchanged. The association ID used between the application and SCTP may be regarded as the identifier, but this identifier is completely local. SCTP allows endpoints to be addressed by multiple IP addresses, the concept of an SCTP endpoint is much broader than in TCP. In this way, a SCTP association can use multiple interfaces and multiple addresses for upper layer protocols. 2.2.2 What is the lifetime of a binding from locator to identifier? The lifetime of a binding from locator to identifier is equal to the lifetime of a SCTP association(RFC 2960) or less(in case of ADDELIP). 2.2.3 How is the binding updated? A control message(called a chunk in SCTP) is used to exchanged the IP addresses between the endpoints. It can be done at setup of the association(see RFC 2960) or during the lifetime of the association(see ADDELIP). 2.3 On the Wire 2.3.1 At what layer is SCTP applied to? It is a layer 4 solution(=transport layer). 2.3.2 Why is this layer the correct one? Every IP address corresponds to a single path through the network. Each path can have different delay, loss and so forth, characterstics. The congestion control algorithm depends on some of this info to perform its congestion control. Thus the transport layer has to measure this himself so that it internal variables are updated. Otherwise the info may be distributed and/or duplicated accross multiple layers. Therefore decisions about using or changing of path are taken by the transport layer. Coene & Loughney Expires July 30, 2004 [Page 5] Internet-Draft Multi6 SCTP solution January 2004 2.3.3 Does SCTP expand the size of a IP packet? SCTP contains its own header just as other transport protocols. It comes in the place of the header of other transport protcols. 2.3.4 Does SCTP change the way fragmenting is handled? No. It leaves IP fragementation alone and uses its own fragmenting and reassembly code. 2.3.5 Are there any changes to ICMP error semantics? No. 2.4 Names, hosts, endpoints? 2.4.1 Relation of SCTP to DNS SCTP has no direct interface to DNS. It however uses the result that come back from a DNS query by the application software on the host, to setup a association to the peer with the returned IP address. If DNS returns a non-reachable address, then SCTP will not be able to reach the peer. If the DNS returns a reachable address, then SCTP can start its association and figure out if the peer is multihomed via a approriate message exchange. It already knows for his own endpoint if it is multihomed, yes or no. 2.4.2 Interaction of SCTP with 2-faced DNS. SCTP has no direct interaction with DNS, so it does not need direct interaction with 2 faced DNS either. 2.4.3 Does SCTP require a centralized registration? NO. 2.4.4 Has SCTP checked for DNS circular dependencies? As SCTP does not rely on the DNS for any functionality of its multihoming solution, no dependecy exists on DNS and as a result, no circular dependencies are possible. 2.4.5 What happens if the DNS server itself is multihomed? No dependcy exits on the DNS, so DNS multihoming is invisible to SCTP in the host. If naturally the communcation between the DNS resolver and the DNS server itself uses SCTP then there is still no problem as only SCTP internal mechanism are used for doing the multihoming. Coene & Loughney Expires July 30, 2004 [Page 6] Internet-Draft Multi6 SCTP solution January 2004 2.4.6 What application/API changes are needed? The application software has to be ported on a socket api very similar to the already present socketapi of TCP. The application will use multihoming unknowingly as No specific API change is needed to activate multihoming on the own endpoint. If the application wishes to activily control the multihoming of the association, new socketapi [8] options exists to do that but then this must be considered as adding new features to applications, not porting old applications. It should be noted that SCTP is a connection-oriented, congestion control protocol. Therefore, traffic running over UDP is not considered at this time. A UDP style socket is present in SCTP but requires more changes to the application. UDP traffic can also use thepartial reliability feature of SCT [9] if required. 2.4.7 Is this backward compatible with IPv6? Yes, it is even backward compatible with IPv4. The SCTP association can be multihomed across a ipv4 and ipv6 network( meaning the single assocaition will use Ipv4 and Ipv6 address within the same association). 2.4.8 Is this backward compatible with IPV4? Yes. see also paragraph above. 2.4.9 What are the interactions with other middleboxes? Middleboxes which do not change or drop SCTP chunks, do not impact the multihoming. Only NAT boxes have to do their work in the INIT and INIT-ACK chunks as addresses are transported in those chunks. If ADDELIP is used, the the add and delete IP chunks must also be screwed around by the NAT box. The NAT box will very likely be the single point-of-failure in the association. 2.4.10 Implications of SCTP for scoped addressing If the address is reachable, the communication will get through. It is however suggested to use globally scoped addresses first and descend from there.It is suggested not to mix global, link or site scope addresses within a single association. 2.4.11 Implications of SCTP with layer2? None. Coene & Loughney Expires July 30, 2004 [Page 7] Internet-Draft Multi6 SCTP solution January 2004 2.4.12 SCTP and referrals? Not sure what is meant here.... If a referal is a new IP address, then the application can setup a new association via SCTP with the new endpoint and be multihomed again. 2.4.13 Legal stuff None. Coene & Loughney Expires July 30, 2004 [Page 8] Internet-Draft Multi6 SCTP solution January 2004 3. Security considerations SCTP has mechanisms for reducing the risk of blind denial-of-service attacks and/or masquerade attacks. If such measures are required by the applications, then it is advised to check the SCTP applicability statement "RFC3257" [4] for guidance on this issue. Additional work on securing the ADDELIP [5] via the use of Purpose Built keys(PBK) [6] in SCTP is going on. Coene & Loughney Expires July 30, 2004 [Page 9] Internet-Draft Multi6 SCTP solution January 2004 4. Acknowledgments The authors wish to thank x, Y, and many others for their invaluable comments. Coene & Loughney Expires July 30, 2004 [Page 10] Internet-Draft Multi6 SCTP solution January 2004 References [1] Lear, E., "Things MULTI6 Developers should think about", Draft in progress , December 2003. [2] 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. [3] Coene, L., "SCTP multihoming issues", Draft in progress , June 2003. [4] Coene, L., ""Stream Control Transmission Protocol Applicability statement"", RFC 3257, April 2002. [5] Stewart, R., Ramalho, M., Xie, Q., Tuxen, M., Rytina, I., Belinchon, M. and P. Conrad, ""Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration"", Draft in progress , September 2003. [6] Tuxen, M. and R. Stewart, ""Authenticated Chunks for Stream Control Transmission Protocol (SCTP)"", Draft in progress , October 2003. [7] Bradner, S., Mankin, Allison. and J. Schiller, "" A Framework for Purpose-Built Keys (PBK)"", Draft in progress , June 2003. [8] Stewart, R., Xie, Q., Yarroll, L., Wood, J., Poon, K., Fujita, K. and M. Tuxen, ""Sockets API Extensions for Stream Control Transmission Protocol (SCTP)"", Draft in progress , August 2003. [9] Stewart, R., Ramalho, M., Xie, Q., Tuxen, M. and P. Conrad, ""SCTP Partial Reliability Extension"", Draft in progress , January 2004. Authors' Addresses Lode Coene Siemens Atealaan 32 Herentals 2200 Belgium Phone: +32-14-252081 EMail: lode.coene@siemens.com Coene & Loughney Expires July 30, 2004 [Page 11] Internet-Draft Multi6 SCTP solution January 2004 John Loughney Nokia Itdmerenkatu 11-13 Espoo 00180 Finland Phone: +??????? EMail: john.loughney@nokia.com Coene & Loughney Expires July 30, 2004 [Page 12] Internet-Draft Multi6 SCTP solution January 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 assignees. 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 Coene & Loughney Expires July 30, 2004 [Page 13] Internet-Draft Multi6 SCTP solution January 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Coene & Loughney Expires July 30, 2004 [Page 14]