Multihoming IPV6 Working group L. Coene Internet-Draft Siemens Expires: January 16, 2005 J. Loughney Nokia July 18, 2004 Multihoming: the SCTP solution Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each 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. 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 January 16, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes the multhoming solution used in SCTP. It compares the SCTP solution with the goals set out in "Goals for IPv6 Site-Multihoming Architectures" [11]. The document also tries to answer the questions posed in "Things MULTI6 developers should think about" [1]. Coene & Loughney Expires January 16, 2005 [Page 1] Internet-Draft Multi6 SCTP solution July 2004 Table of Contents 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. SCTP and Multi6 Goals(RFC3582) . . . . . . . . . . . . . . . 5 2.1 Capabilities of IPv4 Multihoming . . . . . . . . . . . . . 5 2.1.1 Redundancy . . . . . . . . . . . . . . . . . . . . . . 5 2.1.2 Load Sharing . . . . . . . . . . . . . . . . . . . . . 5 2.1.3 Performance . . . . . . . . . . . . . . . . . . . . . 5 2.1.4 Policy . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.5 Simplicity . . . . . . . . . . . . . . . . . . . . . . 5 2.1.6 Transport Layer Survivability . . . . . . . . . . . . 5 2.1.7 Impact on DNS . . . . . . . . . . . . . . . . . . . . 6 2.1.8 Packet filtering . . . . . . . . . . . . . . . . . . . 6 2.2 Additional Requirements . . . . . . . . . . . . . . . . . 6 2.2.1 Scalability . . . . . . . . . . . . . . . . . . . . . 6 2.2.2 Impact on routers . . . . . . . . . . . . . . . . . . 6 2.2.3 Impact on Hosts . . . . . . . . . . . . . . . . . . . 6 2.2.4 Interaction between Hosts and the routing system . . . 6 2.2.5 Operation and Management . . . . . . . . . . . . . . . 6 2.2.6 Cooperation between Transit Providers . . . . . . . . 7 2.2.7 Multiple solutions . . . . . . . . . . . . . . . . . . 7 3. Answer to Multi6 solution Questions . . . . . . . . . . . . 8 3.1 On the wire behaviour . . . . . . . . . . . . . . . . . . 8 3.1.1 How does SCTP solve the multihoming problem . . . . . 8 3.1.2 At what layer is SCTP applied to? . . . . . . . . . . 8 3.1.3 Why is this layer the correct one? . . . . . . . . . . 8 3.1.4 Does SCTP address mobility? . . . . . . . . . . . . . 9 3.1.5 Does SCTP expand the size of a IP packet? . . . . . . 9 3.1.6 Does SCTP add additional latency? . . . . . . . . . . 9 3.1.7 Can SCTP negotiate the multihoming capabilities end-to-end during a connection? . . . . . . . . . . . 9 3.1.8 Does SCTP change the way fragmenting is handled? . . . 9 3.1.9 Implications of SCTP with layer2? . . . . . . . . . . 9 3.2 Identifiers and locators . . . . . . . . . . . . . . . . . 9 3.2.1 Uniqueness . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2 Does SCTP provide a split between identifier and locator? . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.3 What is the lifetime of a binding from locator to identifier? . . . . . . . . . . . . . . . . . . . . . 10 3.2.4 How is the binding updated? . . . . . . . . . . . . . 10 3.2.5 How does the host know its identity? . . . . . . . . . 10 3.2.6 Can a host have multiple identities? . . . . . . . . . 10 3.2.7 Mapping between locators and identifiers. . . . . . . 10 3.2.8 Does SCTP create an alternative DNS-like service? . . 10 3.2.9 Authentication & authorisation . . . . . . . . . . . . 11 3.2.10 Is the mechanism hierarchical? . . . . . . . . . . . 11 3.2.11 Middlebox interactions. . . . . . . . . . . . . . . 11 Coene & Loughney Expires January 16, 2005 [Page 2] Internet-Draft Multi6 SCTP solution July 2004 3.2.12 Implications of SCTP for scoped addressing . . . . . 11 3.3 Routing System interactions . . . . . . . . . . . . . . . 11 3.3.1 Does SCTP change existing aggregation methods? . . . . 11 3.3.2 SCTP and new name space aggregation? . . . . . . . . . 11 3.3.3 Are there any changes to ICMP error semantics? . . . . 11 3.4 Names service interactions . . . . . . . . . . . . . . . . 11 3.4.1 Relation of SCTP to DNS . . . . . . . . . . . . . . . 11 3.4.2 Interaction of SCTP with 2-faced DNS. . . . . . . . . 12 3.4.3 Does SCTP require a centralized registration? . . . . 12 3.4.4 Has SCTP checked for DNS circular dependencies? . . . 12 3.4.5 What happens if the DNS server itself is multihomed? . 12 3.4.6 What additional load will be placed on DNS servers? . 12 3.4.7 Any upstream provider support required? . . . . . . . 12 3.4.8 How do you debug connectivity? . . . . . . . . . . . . 12 3.5 Application concerns and backwards compatibility . . . . . 12 3.5.1 What application/API changes are needed? . . . . . . . 12 3.5.2 Is this backward compatible with IPv6? . . . . . . . . 13 3.5.3 Is this backward compatible with IPV4? . . . . . . . . 13 3.5.4 Can IPv4 devices take advantage of this solution? . . 13 3.5.5 What is the impact of SCTP on different types of sites? . . . . . . . . . . . . . . . . . . . . . . . . 13 3.5.6 What are the interactions with other middleboxes? . . 13 3.5.7 SCTP and referrals? . . . . . . . . . . . . . . . . . 13 4. Legal concerns . . . . . . . . . . . . . . . . . . . . . . . 15 5. Security considerations . . . . . . . . . . . . . . . . . . 16 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . 19 Coene & Loughney Expires January 16, 2005 [Page 3] Internet-Draft Multi6 SCTP solution July 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 January 16, 2005 [Page 4] Internet-Draft Multi6 SCTP solution July 2004 2. SCTP and Multi6 Goals(RFC3582) This chapter compare the features of SCTP with the goals set forth in "Goals for IPv6 Site-Multihoming Architectures" [11]. 2.1 Capabilities of IPv4 Multihoming 2.1.1 Redundancy If paths belonging to a single SCTP association are distinct through the network, SCTP will retain connectivity in case of physical, logical link, routing protocol, transit provider or Exchange failure. 2.1.2 Load Sharing Loadsharing is at present not implemented in SCTP. However applications may try to loadshare their traffic over the different paths by changing the primary path(= primary address) for each user data send to SCTP. This area is for further study. 2.1.3 Performance The endpoints using SCTP multihoming may be using the paths within the SCTP association on the performance of the paths through the network. This can be based on RTO, the long term congestion of a path, throughput, etc.. 2.1.4 Policy No support for policy in SCTP multihoming. 2.1.5 Simplicity The SCTP solution is simple in that it only impact endpoints which want to actualy use it, that it does not impact software anywhere else in the network. Given at least 2 addresses and cable and SCTP will do the job. 2.1.6 Transport Layer Survivability The SCTP multihoming solution is a transport layer solution. It checks every path within the association and changes to a different working path(=rehoming) if at any point during the lifetime of the association, a certain path fails. The association remains in service if at least a single path remains in service. The path change is transparent to the layers above SCTP. Coene & Loughney Expires January 16, 2005 [Page 5] Internet-Draft Multi6 SCTP solution July 2004 2.1.7 Impact on DNS The SCTP multihoming solution does not depend on DNS for its operation. It requires only a single IP address of the remote peer. 2.1.8 Packet filtering Packet filitering will work without any additions. Only packets with incorrect source address(= source IP address used in packet is NOT the address of the interface on which the packet is sent) may be discarded by the packet filtering. 2.2 Additional Requirements 2.2.1 Scalability The scalability of the SCTP solution depends on getting multiple addresses for the 2 endpoints. The 2 endpoints are the only ones to keep state about the different paths between the endpoint, so the solution will scale up very easely when adding new endpoints. The number of paths avialable to a endpoint is equal to the number of IP addresses assigned to the endpoint. 2.2.2 Impact on routers None 2.2.3 Impact on Hosts Host needs to be fitted with multiple IP addresses and should be using SCTP to take advantage of the multihoming. 2.2.4 Interaction between Hosts and the routing system The interaction needed between the host and the gateway router is described in "SCTP multihoming Issues" [3]. The rest of the routing system is not involved. 2.2.5 Operation and Management Monitoring of the SCTP multihoming is possible as SCTP uses multiple addresses, so monitoring based on addresses should be possible. The configuration needed for SCTP is restricted to provide the SCTP software and provisioning multiple addresses and a correct routing table on the host. Coene & Loughney Expires January 16, 2005 [Page 6] Internet-Draft Multi6 SCTP solution July 2004 2.2.6 Cooperation between Transit Providers None required. 2.2.7 Multiple solutions SCTP is a solution in itself. It does not prevent other solutions to work on th esame problem. If a solution works on the underlying layer of SCTP, SCTP will view itself as being singled homed, albeit the underlying solution is actually multihomed. Solutions defined in other transport protocols cannot be used by SCTP. Coene & Loughney Expires January 16, 2005 [Page 7] Internet-Draft Multi6 SCTP solution July 2004 3. Answer to Multi6 solution Questions 3.1 On the wire behaviour 3.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. 3.1.2 At what layer is SCTP applied to? It is a layer 4 solution(=transport layer). 3.1.3 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 January 16, 2005 [Page 8] Internet-Draft Multi6 SCTP solution July 2004 3.1.4 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... 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. 3.1.5 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. 3.1.6 Does SCTP add additional latency? No. 3.1.7 Can SCTP negotiate the multihoming capabilities end-to-end during a connection? Yes, see add or delete a IP address [5]. 3.1.8 Does SCTP change the way fragmenting is handled? No. It leaves IP fragementation alone and uses its own fragmenting and reassembly code. 3.1.9 Implications of SCTP with layer2? None. 3.2 Identifiers and locators 3.2.1 Uniqueness Not needed. Coene & Loughney Expires January 16, 2005 [Page 9] Internet-Draft Multi6 SCTP solution July 2004 3.2.2 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. 3.2.3 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). 3.2.4 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). 3.2.5 How does the host know its identity? The hosts determines which IP addresses it is going to use with the association, thus forming its identity implicit. The easiest way is to bind to all present interfaces, but the application above SCTP can decide to use all or part of the addresses present in the host. 3.2.6 Can a host have multiple identities? The host can have multiple identifiers, by having distinct sets of addresses for each of the identifiers. 3.2.7 Mapping between locators and identifiers. The mapping is done within SCTP and it is really implementation dependant. The identity itself goes never over the wire. 3.2.8 Does SCTP create an alternative DNS-like service? No Coene & Loughney Expires January 16, 2005 [Page 10] Internet-Draft Multi6 SCTP solution July 2004 3.2.9 Authentication & authorisation SCTP uses Purpose Built keys to authenticate the bindings. See add or delete a IP address [5] , Authenticated Chunks for Stream Control Transmission Protocol (SCTP) [6] and Purpose built keys [7].. 3.2.10 Is the mechanism hierarchical? No. 3.2.11 Middlebox interactions. Middleboxes are NOT part of the SCTP solution. If middleboxes have to rewrite information in the packets(esspecially in SCTP), they have to be updated for SCTP. Middelboxes will in general limit the use of multihoming via SCTP, because all traffic(=all paths) have to pass throught the middlebox, thus creating a single point of failure. For further information see "SCTP multihoming Issues" [3]. 3.2.12 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. 3.3 Routing System interactions 3.3.1 Does SCTP change existing aggregation methods? No. 3.3.2 SCTP and new name space aggregation? Not needed. SCTP does NOT introduce a new naming space, thus no aggregation of a new name space is needed. 3.3.3 Are there any changes to ICMP error semantics? No. 3.4 Names service interactions 3.4.1 Relation of SCTP to DNS SCTP has no direct interface to DNS. It however uses the result that Coene & Loughney Expires January 16, 2005 [Page 11] Internet-Draft Multi6 SCTP solution July 2004 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. 3.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. 3.4.3 Does SCTP require a centralized registration? NO. 3.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. 3.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. 3.4.6 What additional load will be placed on DNS servers? None. 3.4.7 Any upstream provider support required? None. 3.4.8 How do you debug connectivity? No present day tools need to be enhanced. 3.5 Application concerns and backwards compatibility 3.5.1 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 Coene & Loughney Expires January 16, 2005 [Page 12] Internet-Draft Multi6 SCTP solution July 2004 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. 3.5.2 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). No change is require to present IPv6 code. 3.5.3 Is this backward compatible with IPV4? Yes. see also paragraph above. 3.5.4 Can IPv4 devices take advantage of this solution? Yes, see also paragraphs above. 3.5.5 What is the impact of SCTP on different types of sites? None. SCTP does not need to know how big the sites should be. It only depends on having IP addresses and being informed by the IP layer in its own host of new or retracted IP addresses(example: Ad-hoc sites). Other hosts or routers are not involved. 3.5.6 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. 3.5.7 SCTP and referrals? If a referal is a new IP address, then the application can setup a Coene & Loughney Expires January 16, 2005 [Page 13] Internet-Draft Multi6 SCTP solution July 2004 new association via SCTP with the new endpoint and be multihomed again( if the new endpoint is also multihomed). Coene & Loughney Expires January 16, 2005 [Page 14] Internet-Draft Multi6 SCTP solution July 2004 4. Legal concerns None. Coene & Loughney Expires January 16, 2005 [Page 15] Internet-Draft Multi6 SCTP solution July 2004 5. 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 January 16, 2005 [Page 16] Internet-Draft Multi6 SCTP solution July 2004 6. Acknowledgments The authors wish to thank x, Y, and many others for their invaluable comments. 7 References [1] Lear, E., "Things MULTI6 Developers should think about", Draft in progress , May 2004. [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. [10] Stewart, R., Tuxen, M. and G. Camarillo, ""Stream Control Transmission Protocol (SCTP) Security Threats"", Draft in progress , April 2004. [11] Abley, J., Black, B. and V. Gill, ""Goals for IPv6 Site-Multihoming Architectures "", RFC 3582, August 2003. Coene & Loughney Expires January 16, 2005 [Page 17] Internet-Draft Multi6 SCTP solution July 2004 Authors' Addresses Lode Coene Siemens Atealaan 32 Herentals 2200 Belgium Phone: +32-14-252081 EMail: lode.coene@siemens.com John Loughney Nokia Itdmerenkatu 11-13 Espoo 00180 Finland Phone: +??????? EMail: john.loughney@nokia.com Coene & Loughney Expires January 16, 2005 [Page 18] Internet-Draft Multi6 SCTP solution July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Coene & Loughney Expires January 16, 2005 [Page 19]