One document matched: draft-coene-multi6-sctp-00.txt
Multihoming IPV6 Working group L. Coene
Internet-Draft Siemens
Expires: July 30, 2004 J. Loughney
Nokia
January 30, 2004
Multihoming: the SCTP solution
<draft-coene-multi6-sctp-00.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.
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]
| PAFTECH AB 2003-2026 | 2026-04-22 13:28:41 |