Individual Submission G. Huston Internet-Draft Telstra Expires: November 30, 2004 M. Wasserman ThingMagic June 2004 A Summary of Proposals to Support Multi-Homing for IPv6 draft-huston-multi6-proposals-00.txt 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 November 30, 2004. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This memo provides an summary of the proposals that have been made to address various aspects of multi-homing support for the IPv6 protocol suite. Document Revision Notes / Version Log Huston & Wasserman Expires November 30, 2004 [Page 1] Internet-Draft Multi6 Proposals June 2004 25 June 2004: initial draft based on Appendix A of draft-huston-multi6-architectures-00.txt Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . . . 3 3. Multihoming without IP Identifiers (NOID) . . . . . . . . . . 4 4. Common Endpoint Locator Pools (CELP) . . . . . . . . . . . . . 5 5. Weak Identifier Multihoming Protocol (WIMP) . . . . . . . . . 6 6. Host-Centric IPv6 Multihoming . . . . . . . . . . . . . . . . 7 7. Summaries of Selected ID/LOC Separation Documents . . . . . . 9 7.1 New or Updated Documents Since IETF58 . . . . . . . . . . 9 7.2 Older Documents that Remain Active/Interesting . . . . . . 12 7.3 Related Multi-Homing drafts, Status unknown . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 8.2 Informative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 17 Huston & Wasserman Expires November 30, 2004 [Page 2] Internet-Draft Multi6 Proposals June 2004 1. Introduction The notes on various approaches are non-exclusive, i.e. solutions not reviewed or mentioned here are not ruled out of discussion. Also the review comments are not comprehensive, and the selection reflects the time constraints of the contributors to this section than any qualitative judgment on any of the approaches. The author is desirous, in future revisions of this draft, in augmenting this selection of reviewed approaches. 2. Host Identity Protocol (HIP) HIP is an ID/Locator separation mechanism intended to solve a much wider problem space than site multi-homing. HIP uses cryptographic identifiers termed Host Identity Tags (HITs) at the application layer, which are mapped to locators (IP Addresses) by a HIP protocol stack layer that interfaces between the transport layer and IP internetwork layer. The essential characteristic of HIP is its use of opportunistic identity generation, as it uses a cryptographic host identifier as the basis of the persistent identity. The transport session can be agile across locators, or even across IP protocol versions, as the HIT is used to determine session integrity, allowing the hosts to determine what packets legitimately form part of the session. HIP is proposed as a new protocol element, located at layer 3.5 (i.e. above the internetwork IP layer and below the transport layer). The presentation to the transport layer uses 128 bit hash values (the HIT) in place of IP addresses, while the presentation to the internet layer uses conventional IP addresses. Being opportunistic and unstructured, the HIT space is not an efficient search space, nor can a HIT be used as a unique search key. HITs are part of an equivalence function, to allow each host to determine that an incoming packet is part of an established session. HITs cannot be used as an identity value in a conventional referral sense (HostA wants to tell HostB to talk to HostC). While an application could pass a HIT to a third-party (and legacy applications would unknowingly do so), the third party would have no way to map that HIT to a locator (an IP address) as HIP does not include any global HIT->Locator mapping mechanism. Summary: o New Protocol Stack Element o Layer 3.5 (Above IP, below Transport Huston & Wasserman Expires November 30, 2004 [Page 3] Internet-Draft Multi6 Proposals June 2004 o Unstructured, opportunistic identity values (non-referential) o DNS rendezvous o No Locator exchange protocol Current IETF Documents: o draft-moskowitz-hip-arch o draft-moskowitz-hip o draft-nikander-hip-mm o draft-nikander-esp-beet-mode 3. Multihoming without IP Identifiers (NOID) NOID proposes an approach for endpoint identifier and locator separation where the endpoint identifier space is drawn from the locator space. Instead of creating a new namespace for endpoint identifiers, the endpoint identifier may be chosen from the set of locators that can be used to reach a given endpoint. Until an event occurs that modifies the list of usable locators, the initial endpoint identifier value can serve as a locator. NOID uses next-header values in the IPv6 header to indicate whether a given packet should be processed by the NOID layer. At a conceptual level, NOID adds a layer to the middle of IP above most IP processing, but below IPSec, fragmentation and reassembly functions. NOID makes use of the global DNS as a mapping system between IDs and Locators. A node who wishes to communicate with another node can use the FQDN to get a list of possible locators (IP Addresses). That node will then choose one of the locators to use as an Application-level ID (AID). NOID offers some support for application referrals. If Host A passes an AID to Host B that is supposed to point to Host C, Host B should be able to do a reverse DNS lookup to map the AID to an FQDN and then use the FQDN to get the complete set of locators. However, for this to be effective, nodes would need to have both forward and reverse DNS entries. There might also be a need to dynamically update the DNS as a node becomes reachable or unreachable at certain locators. Summary: Huston & Wasserman Expires November 30, 2004 [Page 4] Internet-Draft Multi6 Proposals June 2004 o New Protocol Stack Element o Layer 3 (Inserted in the upper part of IP, below IPSEC and fragmentation / reassembly o Identity values based on locator set o DNS rendezvous o Identity peering protocol Current IETF Documents: o draft-nordmark-multi6-noid o draft-templin-isnoid 4. Common Endpoint Locator Pools (CELP) CELP explores the concept of sharing information about locator reachability between transport-layer "multi-addressing" mechanisms (such as SCTP and DCCP) and Internet-layer multi-addressing mechanisms, referred to in the draft as "wedge-layer approaches" (such as NOID). (This concept was originally discussed on the MULTI6 mailing list under the name 'SLAP'.) The motivation behind CELP is that multiple multi-addressing mechanisms may be used (by different applications or for different connections) on a single endpoint, and that it would beneficial for those mechanisms to share information about the reachability of the IP addresses in a given locator pool. If a transport-layer mechanism, such as SCTP, could share its knowledge regarding the reachability of a certain locator, it might be possible to minimize or eliminate Internet-layer control packets that are used to maintain that information at the Internet layer. In some ways, this is similar to IPv6 Neighbor Discovery's use of upper layer advice regarding neighbor reachability to avoid sending unnecessary ND packets. This document offers a definition of the term "endpoint" that refers to a locator pool that may have a smaller scope than an entire IP node (i.e. a given locator pool may only contain a subset of the locators available on an IP node). The CELP document is more of a consideration of approach than an actual proposal for a solution. It doesn't specify in detail how it would work with any particular transport-layer or Internet-layer Huston & Wasserman Expires November 30, 2004 [Page 5] Internet-Draft Multi6 Proposals June 2004 multiaddressing mechanisms. However, it is an approach that could be applied to many combinations of solutions. Summary: o Considerations relating to sharing locator reachability information across session instances. Current IETF Documents: o draft-crocker-celp 5. Weak Identifier Multihoming Protocol (WIMP) WIMP is an endpoint identifier / locator separation protocol that is heavily focused on mitigating the threats outlined in work in progress on security threats in multi-homing scenarios [draft-nordmark-multi6-threats-00.txt]. The WIMP approach uses divided secrets and hash chaining to ensure that new locators are supplied by the same node that supplied the original locator. WIMP uses a separate name space for 128-bit non-routable IDs that are never used in packets on the network. These IDs are locally generated for both local and remote nodes by hashing a nonce (for the initiator's endpoint identity) or the FQDN (for the responder's endpoint identity). (The approach assumes a requirement that all responders will have a FQDN.) The WIMP protocol introduces a WIMP layer that maps between IDs and locators based on internal state. The WIMP layer is conceptually located within the network layer, above most IP processing and below IPsec, fragmentation/reassembly and destination options, similar to NOID. Communication between two end-points requires establishment of a WIMP session. Once the session is established, it can be used for multiple simultaneous or sequential connections to the same end-point. During WIMP session establishment, WIMP introduces a separate header into the data packets, between the IP and TCP/UDP headers that contains information about the WIMP session. The WIMP session establishment packets can optionally be piggy-backed on data packets. WIMP does not introduce a separate header into all IPv6 packets. Instead, once a WIMP session is established, the IPv6 FlowID is used to hold an identifier for the WIMP host-pair context associated with a given packet. WIMP is intended to provide a solution to some of the security Huston & Wasserman Expires November 30, 2004 [Page 6] Internet-Draft Multi6 Proposals June 2004 concerns, particularly regarding connection hijacking, that have been raised for some other endpoint identity / locator separation mechanisms. Reviewers of WIMP have raised some questions of this approach, particularly concerning the use of an optional header while operating below IP fragmentation. The piggy-backing mechanism requires that the packets not be fragmented, but it doesn't explain how upper layers will become aware of the MTU limitations on those packets and/ or how this mechanism would interact with Path MTU discovery. Like HIP, WIMP makes no provision to handle application-level referrals and does not contain a mechanism for global endpoint identifier to locator mapping. It has also been pointed out that it is interesting to consider whether the WIMP approach to security, hash chaining, could be applied to other endpoint identity / locator separations mechanisms, such as NOID. Summary: o New Protocol Stack Element o Layer 3 (Inserted in the upper part of IP, below IPSEC and fragementation / reassembly o Identity values based on hash of FQDN o Identity peering protocol Current IETF Documents: o draft-ylitalo-multi6-wimp 6. Host-Centric IPv6 Multihoming Host-Centric Multihoming is, in some ways, the simplest way to address the IPv6 site multihoming problem. The concept is that every host in the multihomed site is configured with multiple prefixes that correspond to different service providers. Each host configures addresses within those prefixes and selects among those addresses when connecting to a remote host. This configuration is automated using Router Renumbering and IPv6 Address Autoconfiguration. However, this simple solution Layer 3 (inserted in the upper part of IP, below IPSEC and fragementation / reassembly has several practical limitations and drawbacks, and this draft attempt to address them. In particular, the Host-Centric Multihoming proposal attempts to address the "site exit issue". Hosts cannot control the exit path Huston & Wasserman Expires November 30, 2004 [Page 7] Internet-Draft Multi6 Proposals June 2004 that their packets will take from the local site, so hosts with multiple addresses may use a source IP address from one ISP on packets that end-up being routed through a different ISP. In many cases, the ISPs will run ingress filtering and will discard those packets. One solution to the site exit problem is to changes the ISP ingress filters to accept all of the source address prefixes that are used within the site. Other approaches are to perform source-based routing within the site, to deploy a single site-exit router or to structure the network so that all exit routers are connected to a single DMZ network that employs source-based routing. A virtual DMZ can be constructed by configuring a mesh of tunnels between all exit routers, tunneling packets to the correct exit router based on source address. Each of these solutions has operational drawbacks and/or introduces inefficiencies. This proposal suggests another solution to the site exit problem called "source address discovery". Based on Path MTU discovery, this mechanism involves adding extra information to the ICMP Destination Unreachable message that the packet was discarded due to an ingress filter. This extra information indicates what address prefix should be used to pass the ingress filter. Rather than adding a field to the ICMP message, this extra information is communicated via the source address that the route Layer 3 (Inserted in the upper part of IP, below IPSEC and fragementation / reassembly). It also proposes a "superior" alternative called "exit router discovery", which allows hosts to specify which exit router will be used for each packet. Instead of sending ICMP error messages when ingress filtering causes packets to be discarded, the exit router will send the equivalent of a redirect message and future packets with the same source/destination address pair will be tunneled to the indicated exit router. This mechanism involves tunneling to a site-exit anycast address that is derived from the sites' prefixes. The draft primary focuses on the specification of this "superior" approach, largely ignoring some pertinent questions such as: Will residential and enterprise-level IPv6 routers really support anycast routing? One important thing to note about the host-centric multihoming solution is that it doesn't appear to provide any ability for transport connections to survive a change in the topology that causes a host to become unreachable at an address that is currently used as a connection end-point. It also does not offer any support for legacy applications that do application-level referrals, requiring that a full set of locators be exchanged as part of the referral. Huston & Wasserman Expires November 30, 2004 [Page 8] Internet-Draft Multi6 Proposals June 2004 7. Summaries of Selected ID/LOC Separation Documents This section summarizes a set of selected ID/Loc separation documents. The selection includes documents that appear to be active, and this section provides a very short summary of each one. The first sub-section lists documents that are new or updated since IETF 58 and the second sub-section lists older documents that remain active. The documents in each sub-section are listed alphabetically by draft filename. 7.1 New or Updated Documents Since IETF58 o TLC-FM: Transport Layer Common Framework for Multihoming draft-arifumi-multi6-tlc-fm This draft proposes a transport-layer mechanism for ID /Locator mapping. There is a conceptual layer within the transport layer that provides support for common multihoming functions. It is compatible with the use of Mobile IPv6 (MIP6) to provide mobility support. In TLC-FM, like SCTP, the ID consists of a collection of locators that may be used to reach a given host. It employs transport-level clues (such as TCP retransmissions) to decide when to switch locators. For UDP connections, ICMP error messages or application-level hints are necessary. This mechanism is not well enough specified to fully evaluate it, but it doesn't appear to offer any support for application-level referrals. o Multi-Homing Tunnel Broker (MHTB) draft-bagnulo-multi6-mhtb This document defines an enhancement to RFC 3178, IPv6 Multihoming Support at Site Exit Routers, to reduce the administrative overhead of maintaining a configured tunnel for each multihoming association. However, this draft does not address another major drawback of the RFC 3178 approach, that it does not protect against the complete failure of one or more connected ISPs. o Framework for Common Endpoint Locator Pools (CELP) draft-crocker-celp Dave Crocker and Avri Doria's CELP draft, reviewed in the Huston & Wasserman Expires November 30, 2004 [Page 9] Internet-Draft Multi6 Proposals June 2004 previous section. o Multi-Homing: the SCTP Solution draft-coene-multi6-sctp This document does not form a complete proposal in that it consists of a number of answers to issues raised in the work-in-progress "Things MULTI6 Developers Should Think About" draft, and does not fully address how SCTP could be a complete approach for multi-homing. An interesting aspect of this approach is that it claims that SCTP is not an ID/Loc separation mechanism, although the state defined by the group of available IP addresses plays the role of an identity, and the locator is whichever address is currently being used for communication. SCTP also experiences the same complexities as other proposals (AKA NOID, CELP) that use a pool of locators as the ID -- How do you choose which locator to use? And how do you detect when a member of the pool becomes invalid for use as a locator? SCTP may provide some useful experiences and mechanisms that may apply to a class of possible solutions. o Host Identity Protocol (HIP) Rendezvous Mechanisms draft-eggert-hip-rendezvous-00.txt This is an overview draft that discusses the concept of HIP rendezvous mechanisms to improve the applicability of HIP for mobility and multihoming. This is a survey document that outlines the problem and discusses different type of solutions to the problem. o Host-Centric IPv6 Multihoming draft-huitema-multi6-hosts Draft by Christian Huitema and others, described above. o Things MULTI6 Developers Should Think About draft-lear-multi6-things-to-think-about Eliot Lear's efforts to collect a set of practical questions that should be considered for all MULTI6 protocols. Huston & Wasserman Expires November 30, 2004 [Page 10] Internet-Draft Multi6 Proposals June 2004 o Host Identity Protocol (HIP) draft-moskowitz-hip This is the base protocol specification for HIP. Along with the HIP architecture, these documents form the basis of the HIP work. o Consideration on HIP Based IPv6 Multi-Homing draft-nikander-multi6-hip Pekka Nikander's document that submits HIP as a solution for the MULTI6 problem space. o 8+8 Addressing for IPv6 End to End Multihoming draft-ohta-multi6-8plus8 o Threats Relating to Transport Layer Protocols Handling Multiple Addresses draft-ohta-multi6-threats o Multihoming Using IPv6 Addressing Derived from AS Numbers draft-savola-multi6-asn-pi This draft provides a mechanism for organizations that have been assigned a 16-bit AS number to use that number to auto-generate a globally routable, provider-independent address prefix. o Problem Statement: HIP Operation over Network Address Translators draft-stiemerling-hip-nat Summarizes the problems with running HIP and IPsec-based data transmission across NATs. o Operational Approach to Achieve IPv6 Multihomed Network draft-toyama-multi6-operational-site-multihoming This document proposes to support site multihoming in IPv6 by assigning additional /32 prefixes and AS numbers to "groups" of providers who will provide multihomed /48 prefixes to their mutual customers. Huston & Wasserman Expires November 30, 2004 [Page 11] Internet-Draft Multi6 Proposals June 2004 It is currently unclear to the reviewer how/if this proposal would work and/or scale since it seems to involve two different providers advertising the same /32 and the same AS number into the default free zone. It requires some type of peering "to share prefix assignments" between ISPs, and the diagram shows some type of connection between the ISPs, but I don't know what the details of that connection are. It also has the potential to more quickly exhaust the AS number space and to result in a substantially larger number of routes in default free routers, since the number of "groups" could scale exponentially with the number of providers. o Crypto Based Host Identifiers (CBHI) draft-van-beijnum-multi6-cbhi This draft defines a crytographic mechanism for generating host identifiers. It is intended for use with other protocols that require host identifiers, such as ODT (see below). o On Demand Tunneling for Multihoming (ODT) draft-van-beijnum-multi6-odt This draft discusses an automatic tunnelling-based solution for multihoming. o Weak Identifier Multihoming Protocol (WIMP) draft-ylitalo-multi6-wimp WIMP proposal, described above. 7.2 Older Documents that Remain Active/Interesting o RFC 3582: Goals for IPv6 Site-Multihoming Architectures o Choices for Multiaddressing draft-crocker-mast-analysis o What's In a Name: Thoughts from the NSRG draft-irtf-nsrg-report Huston & Wasserman Expires November 30, 2004 [Page 12] Internet-Draft Multi6 Proposals June 2004 o A Roadmap for Multihoming in IPv6 draft-kurtis-multi6-roadmap o Host Identity Protocol (HIP) Architecture draft-moskowitz-hip-arch-05.txt o End-Host Mobility and Multi-Homing with Host Identity Protocol (HIP) draft-nikander-hip-mm o Threats Relating to IPv6 Multihoming Solutions draft-nordmark-multi6-threats-00.txt o Multihoming without IP Identifiers (NOID) draft-nordmark-noid Erik Nordmark's NOID specification, described above. 7.3 Related Multi-Homing drafts, Status unknown This is a list of ID/Loc separation and/or MULTI6 documents, listed alphabetically by draft name. o Extension Header for Site-Multi-homing Support draft-bagnulo-multi6-mhexthdr o Application of the MIPv6 Protocol to the Multi-Homing Problem draft-bagnulo-multi6-mnm o Multiple Address Service for Transport (MAST): An Extended Proposal draft-crocker-mast-proposal o NAROS : Host-Centric IPv6 Multihoming with Traffic Engineering draft-de-launois-multi6-naros o Application and Use of the IPv6 Provider Independent Global Unicast Format Huston & Wasserman Expires November 30, 2004 [Page 13] Internet-Draft Multi6 Proposals June 2004 draft-hain-ipv6-pi-addr-use o Simple Dual Homing Experiment draft-huitema-multi6-experiment-00.txt o Host-Centric IPv6 Multihoming draft-huitema-multi6-hosts o IPv4 Multihoming draft-ietf-multi6-v4-multihoming This documents how multi-homing is supported at present in the IPv4 protocol domain. o Multihoming in IPv6 by Multiple Announcement of Longer Prefixes draft-kurtis-multihoming-longprefix o Multihoming using 64-bit Crypto-based IDs draft-nordmark-multi6-cb64 o Strong Identity Multihoming using 128-bit Identifiers (SIM/ CBID128) draft-nordmark-multi6-sim o IPv6 Address Assignment and Route Selection for End-to-End Multihoming draft-ohira-assign-select-e2e-multihome o Hierarchical IPv6 Subnet ID Autoconfiguration for Multi-Address Model Multi-Link Multihoming Site draft-ohira-multi6-multilink-auto-prefix-assign o Hierarchical IPv6 Subnet ID Autoconfiguration for Multi-Address Model Multi-Link Multihoming Site draft-ohira-multi6-multilink-auto-prefix-assign o The Architecture of End to End Multihoming draft-ohta-e2e-multihoming-05.txt Huston & Wasserman Expires November 30, 2004 [Page 14] o 8+8 Addressing for IPv6 End to End Multihoming draft-ohta-multi6-8plus8-00.txt o Threats Relating to Transport Layer Protocols Handling Multiple Addresses draft-ohta-multi6-threats-00.txt o Multihomed ISPs and Policy Control draft-ohta-multihomed-isps-00.txt o GAPI: A Geographically Aggregatable Provider Independent Address Space to Support Multihoming in IPv6 draft-py-multi6-gapi o Multi Homing Translation Protocol (MHTP draft-py-multi6-mhtp-01.txt o Multihoming Using IPv6 Addressing Derived from AS Numbers draft-savola-multi6-asn-pi-01.txt o IPv6 Site Multihoming: Now What? draft-savola-multi6-nowwhat o Operation of NOID Multihoming Protocol on ISATAP Nodes draft-templin-isnoid o LIN6: A Solution to Multihoming and Mobility in IPv6 draft-teraoka-multi6-lin6 o Operational Approach to achieve IPv6 multihomed network draft-toyama-multi6-operational-site-multihoming-00.txt o Two Prefixes in One Address draft-van-beijnum-multi6-2pi1a-00.txt o Crypto Based Host Identifiers draft-van-beijnum-multi6-cbhi-00.txt Huston & Wasserman Expires November 30, 2004 [Page 15] Internet-Draft Multi6 Proposals June 2004 o Provider-Internal Aggregation based on Geography to Support Multihoming in IPv6 draft-van-beijnum-multi6-isp-int-aggr-01.txt o On Demand Tunneling For Multihoming draft-van-beijnum-multi6-odt-00.txt 8. References 8.1 Normative References 8.2 Informative References Authors' Addresses Geoff Huston Telstra Margaret Wasserman ThingMagic Huston & Wasserman Expires November 30, 2004 [Page 16] Internet-Draft Multi6 Proposals June 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. Huston & Wasserman Expires November 30, 2004 [Page 17]