MMUSIC Working Group E. Cooper Internet Draft P. Matthews Expires: December 2006 Avaya June 15, 2006 Eliminating Duplicate Connectivity Checks in ICE draft-matthews-mmusic-ice-eliminating-duplicates-00.txt Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 December 15, 2006. Abstract The ICE (Interactive Connectivity Establishment) protocol is designed to find the best possible transmission path between two endpoints in the presence of intervening NAT (Network Address Translation) boxes. It is a very versatile protocol, designed to operate in all possible network topologies. This versatility occasionally results in a large exchange of messages between the two endpoints. This document proposes a modification which reduces the amount of messaging ICE requires, without affecting the effectiveness of ICE. Cooper & Matthews Expires December 15, 2006 [Page 1] Internet-Draft Eliminating Duplicate Checks June 2006 This modification suppresses the transmission of Binding Requests from server-reflexive candidates. The result is increased efficiency due to the suppressed connectivity checks, leading to fewer overall messages and faster discovery of working paths. Conventions used in this document The terminology of this document follows that of [ICE-08]. In particular, the terms "candidate", "transport address", "native" vs. "remote", "peer-reflexive", "server-reflexive", and "local" are all used as per [ICE-08]. Table of Contents 1. Introduction...................................................3 2. Summary of Proposed Changes....................................4 3. Details of Proposed Changes....................................6 3.1. Candidate Pairs and State Machines........................6 3.2. Rx State Machine..........................................8 3.3. Tx State Machine..........................................9 3.3.1. Ordering the Tx State Machines......................10 3.4. Adding Candidates........................................11 3.4.1. Adding Native Candidates - Non Peer Reflexive.......11 3.4.2. Adding Native Candidates - Peer Reflexive...........11 3.4.3. Adding Remote Candidates - Non Peer Reflexive.......11 3.4.4. Adding Remote Candidates - Peer Reflexive...........12 3.5. Promoting Candidates.....................................12 3.6. Removing Candidates......................................12 3.7. Queuing Incoming Binding Requests for Later Processing...12 3.8. Processing Received Binding Requests.....................13 3.9. Processing Received Binding Responses....................14 4. Security Considerations.......................................15 5. IANA Considerations...........................................15 6. Acknowledgments...............................................15 7. References....................................................17 7.1. Normative References.....................................17 7.2. Informative References...................................17 Author's Addresses...............................................17 Intellectual Property Statement..................................17 Disclaimer of Validity...........................................18 Copyright Statement..............................................18 Acknowledgment...................................................18 Cooper & Matthews Expires December 15, 2006 [Page 2] Internet-Draft Eliminating Duplicate Checks June 2006 1. Introduction [ICE-08] pairs every native candidate with every remote candidate, and then checks for connectivity in each direction. When some of the candidates are server-reflexive candidates, this can lead to redundant checks. This is because, from a network topology point-of- view, sending a message from a server-reflexive candidate is the same as sending from the candidate from which it was derived. Thus messages sent from server-reflexive candidates do not discover new network paths. To understand this more clearly, consider the following network topology: ..Internet ....................... . . . +------+ . . |STUN | . . |Server| . . +------+ . . . . . . +--------+ +--------+ . .. | NAT NL | .............. | NAT NR | .. +--------+ +--------+ ---- ---- /\ /\ /L \ / R\ ---- ---- Here L and R are each behind a [BEHAVE-UDP] compliant NAT. Endpoints L and R both use a public STUN server, but this server does not support the STUN Relay usage. Thus L has two candidates: o L1 - a local candidate on L o L2 - a server-reflexive candidate for L discovered by sending a Binding Request to the STUN server from L1 Similarly, R has two candidates: R1 and R2. Cooper & Matthews Expires December 15, 2006 [Page 3] Internet-Draft Eliminating Duplicate Checks June 2006 Forming the candidate pairs and considering the connectivity checks required for each pair gives the following: Check from Check from Pair L to R Comment R to L Comment ==== ========== ======= ========== ======= (L1,R1) (L1 -> R1) (L1 <- R1) (L1,R2) (L1 -> R2) (L1 <- R2) Dup of L1<-R1 (L2,R1) (L2 -> R1) Dup of L1->R1 (L2 <- R1) (L2,R2) (L2 -> R2) Dup of L1->R2 (L2 <- R2) Dup of L2<-R1 As shown in the table, any check that originates from L2 is a duplicate of a check that originates from L1. Similarly checks originating from R2 are duplicates of R1's checks. In this example eliminating these duplicates reduces the total number of checks by 50%. Eliminating checks in this manner has two advantages: o It reduces the number of messages that need to be exchanged between endpoints; and o The remaining checks start earlier, because there are fewer 50msec delays between the start of successive checks. This results in faster identification of desirable paths. Compared with [ICE-08], the modification described here typically results in 25% - 50% fewer messages when multiple NATs are involved. Similarly, the highest-priority working candidate can be promoted to the m/c line 25% - 50% faster. Since the savings are a result of eliminating checks from server-reflexive candidates, the reductions are less significant when one of the endpoints has a public IP address. This document is intended only as a contribution to the discussion around [ICE-08], and is not intended to propose a new standard or extension to ICE. Rather, it is our hope that the ideas described in this draft might be incorporated into a future revision of ICE. 2. Summary of Proposed Changes This document defines a "base candidate" as any candidate that represents a unique sending point. Local candidates are base candidates, as are relay candidates, but server-reflexive and peer- reflexive candidates are not base candidates. Cooper & Matthews Expires December 15, 2006 [Page 4] Internet-Draft Eliminating Duplicate Checks June 2006 Connectivity checks only need to be sent from base candidates, as a check sent from a non-base candidate is equivalent to a check sent from the base candidate from which it was derived. In reformulating the procedures of [ICE-08] to send only from base candidates, we found it necessary to split the state machine of [ICE- 08] into separate receive (Rx) and transmit (Tx) state machines. Trying to express the modification _without_ this split leads to the following: o The state machine for a native non-base candidate must suppress the sending of Binding Requests; o The Tx side of the state machine for a native base candidate must somehow drive the Tx side of all state machines for all native non-base candidates derived from that base candidate; o The Rx side of all the state machines for a given native candidate must somehow be linked together, since the remote endpoint is only sending from remote base candidates. Consider the example of section 1. In that scenario, the only candidate pair that works is (L2, R2). Note that neither L2 nor R2 are base candidates. On node L, the state machine for (L2, R2) will not send packets (since L2 is not a base candidate), nor will it receive packets (since R will not send from the non-base candidate R2). Thus the Tx side of the state machine for the (L2, R2) pair must somehow be linked with the Tx side of the state machine for (L1, R2), while the Rx side of the state machine for the (L2, R2) pair must somehow be linked with the state machine for (L2, R1). In addition, when we considered how to order or promote candidate pairs when their state machines are tied together in this manner, it seemed evident to us that the simplest approach is to split the state machine of [ICE-08] into separate Rx and Tx state machines. Splitting the state machine into separate Rx and Tx state machines results in two other changes: First, the concept of a candidate pair is divided into an Rx candidate pair (representing a receiving path from a remote candidate to a native candidate) and a Tx candidate pair (representing a transmission path from a native (base) candidate to a remote candidate). Second, promotion of a candidate is based on its receiving status only, and not on its transmitting status. In other words, the Cooper & Matthews Expires December 15, 2006 [Page 5] Internet-Draft Eliminating Duplicate Checks June 2006 promotion of a candidate is driven solely by whether or not the remote endpoint has discovered a sending path to that candidate. This is consistent with the SDP rule that the m/c line specifies only the address at which an endpoint wishes to receive data. 3. Details of Proposed Changes 3.1. Candidate Pairs and State Machines The following figure shows the relationships between candidates, pairs and state machines on a single endpoint: CNC List +--------+ +--------+ CRC List +---------+ |Tx State| |Tx State| +---------+ | | | Machine| |Machine | | | | | +--------+ +--------+ | | | | \ / | | | | \ / | | +---------+ Tx Candidate \ / +---------+ | | Pair (Nc -> Rc) \ / | | | Native |--------------------------------------->| Remote | |Candidate| |Candidate| | (Nc) |<---------------------------------------| (Rc) | | | Rx Candidate / \ | | +---------+ Pair (Nc <- Rc) / \ +---------+ | | / \ | | | | / \ | | | | +--------+ +--------+ | | | | |Rx State| |Rx State| | | +---------+ | Machine| |Machine | +---------+ | | +--------+ +--------+ | | | | | | | | | | | | | | +---------+ +---------+ Each peer maintains a list of all the native and remote candidates. In this document, these are referred to as the Current Native Candidate (CNC) list and the Current Remote Candidate (CRC) list. Whenever a new candidate is added to one of these lists, the Tx and Rx candidate pairs are created. Each Tx candidate pair (Nc -> Rc) describes a unique outgoing path from the native candidate Nc to the remote candidate Rc. Similarly, an Rx candidate pair (Nc <- Rc) represents a unique incoming path. Each Tx candidate pair has a number of Tx state machines associated with it, one for each component in the candidate. For example, two Tx state machines are required when both RTP and RTCP are used. Similarly, each Rx Cooper & Matthews Expires December 15, 2006 [Page 6] Internet-Draft Eliminating Duplicate Checks June 2006 candidate pair has one Rx state machine for each component in the candidate. On each endpoint, an Rx candidate pair (Nc <- Rc) is created for every combination of a native candidate (Nc) with a remote candidate (Rc). By contrast, a Tx candidate pair (Nbc -> Rc) is only created for every combination of a native _base_ candidate (Nbc) with a remote candidate (Rc). Peer reflexive candidates are an exception to these rules. A remote peer reflexive candidate (Rprc) generates no Rx candidate pairs and only a single Tx candidate pair (Ngc -> Rprc), where Ngc is the native candidate involved in the generation of Rprc (see section 3.8. for details). Note that, in this special case, Ngc may not be a base candidate. Similarly, a native peer reflexive candidate (Nprc) generates a single Rx candidate pair (Nprc <- Rgc) and no Tx candidate pairs. Cooper & Matthews Expires December 15, 2006 [Page 7] Internet-Draft Eliminating Duplicate Checks June 2006 3.2. Rx State Machine The Rx state machine tracks the receipt of Binding Requests from the remote peer. Each Rx state machine monitors a single component of a native candidate. The state transition diagram for the Rx state machine is: Start | v +------------+ -- | Waiting | | +------------+ | | | | Rx Req | | ------ | | - | v 10s timeout | +------------+ ----------- | | Valid | - | +------------+ | | | | Rx ERROR | | -------- | | - | V | +------------+ -> | Invalid | +------------+ The Rx state machine starts out in the WAITING state. In this state, it is waiting for the first Binding Request to arrive. Once the Binding Request is received, the state machine transitions to the VALID state. Note that the Binding Response is sent as part of the processing of the Binding Request (see section 3.8. which happens before the Binding Request is passed to the Rx state machine. If no Binding Request arrives within 10 seconds, the state machine moves to the INVALID state, where it remains until it is destroyed. When the Rx state machine transitions to the VALID state, it signifies that a successful incoming path has been found from the remote endpoint. Once the Rx state machine is in the VALID state, it stays there until the state machine is destroyed as a result of a signaling message, or an error occurs. Cooper & Matthews Expires December 15, 2006 [Page 8] Internet-Draft Eliminating Duplicate Checks June 2006 3.3. Tx State Machine The Tx state machine probes a transmission path to the remote peer. It does this by sending Binding Requests and waiting for the corresponding Responses. Each Tx state machine probes a single component of a remote candidate. The state transition diagram for the Tx state machine is as follows: Start | v +-----------+ | Waiting | +-----------+ | | Rx PROCEED | ---------- Rx ERROR | Tx Req -------- v - +-----------+ ------------| Testing | | +-----------+ v | +-----------+ | Rx SUCCESS | Invalid | | ---------- +-----------+ | - ^ v | +-----------+ ------------| Valid |<- Rx ERROR +-----------+ | Timer Tr -------- | | -------- - --------- - The Tx state machine starts out in the WAITING state. In this state, it is waiting until it is allowed to proceed. (see section 3.3.1. When the Tx state machine transitions to the TESTING state it sends a Binding Request. This starts a little STUN state machine (not shown) associated with the Tx state machine which resends the Binding Request according to the exponential backoff procedure described in [STUNbis]. At this point, the Tx state machine can receive either: Cooper & Matthews Expires December 15, 2006 [Page 9] Internet-Draft Eliminating Duplicate Checks June 2006 o A SUCCESS event, indicating that a successful Response was received, OR o An ERROR event, indicating that either a fatal error response was received, or the retry limit was reached. The SUCCESS event causes the Tx state machine to transition to the VALID state, indicating that a successful outbound path to the remote endpoint has been found. In this state, the Tx state machine resends the Binding Request every Tr seconds. 3.3.1. Ordering the Tx State Machines As per [ICE-08], the bindings created by ICE in intervening NATs must be carefully rate-limited to ensure that the NAT is not overwhelmed when creating new mapping and filtering entries. To achieve this, most Tx state machines are initially placed on a 'pacing' queue. Every Ta milliseconds, one state machine is removed from the queue and started. A Tx state machine may be removed from the queue and started early if an incoming STUN Binding Request reveals that the intermediate NATs must already have the appropriate mapping and filtering entries. Since Tx state machines created for remote peer reflexive addresses are only created as a result of incoming binding requests, they always meet the above condition for early commencement. Tx state machines of this type always go directly to the TESTING state and bypass the 'pacing' queue. [ICE-08] defines some sophisticated rules for ordering state machines to ensure that both endpoints start their state machines in the same order. With the splitting of the state machines into the Rx and Tx state machines, having the same ordering on both endpoints is less important. Simpler ordering rules could be adopted. However, we stick with the [ICE-08] ordering rules to make direct comparison with [ICE-08] simple. Thus the ordering of Tx state machines follows the rules specified in [ICE-08]. Specifically, and endpoint first orders the Tx candidate pairs following the rules given in section 7.5 of [ICE-08], then sub- orders the Tx state machines by component number. One addition to the rules of section 7.5 of [ICE-08] required. When moving the Tx candidate pair (Nac -> Rac) to the top of the list, where Nac and Rac are the active candidates, it may be that there is no such Tx candidate pair because Nac is not a base candidate. In Cooper & Matthews Expires December 15, 2006 [Page 10] Internet-Draft Eliminating Duplicate Checks June 2006 that case, select the Tx candidate pair (Nbc -> Rac) where Nbc is the base candidate from which the active candidate Nac was derived. 3.4. Adding Candidates Adding a candidate to either the CNC or CRC list is a key ICE activity. Whenever this occurs, a number of Tx and Rx candidate pairs are built, which leads to the creation of the Tx and Rx state machines. The rules for creating candidate pairs and state machines are given below. 3.4.1. Adding Native Candidates - Non Peer Reflexive Whenever a (non-peer reflexive) native candidate is added to the CNC list a number of Rx candidate pairs are made. Specifically, an Rx candidate pair is created between the candidate and every remote candidate in the CRC. These pairs cause the creation of an Rx state machine for each pair of transport addresses with matching component IDs. In addition, if the newly added native candidate is a base candidate then a Tx candidate pair is created with every entry in the CRC. These Tx candidate pairs result in the creation of a Tx state machine for each pair of transport address with matching component IDs. 3.4.2. Adding Native Candidates - Peer Reflexive When adding a native peer reflexive candidate to the CNC list, the newly added native candidate is only matched with the remote generating candidate. As a result, only one Rx candidate pair is created. This creates an Rx state machine for each pair of transport addresses with matching component IDs. Peer reflexive candidates are not base candidates, so no Tx candidate pairs or Tx state machines are built. 3.4.3. Adding Remote Candidates - Non Peer Reflexive When adding a (non-peer reflexive) candidate to the CRC list, an Rx candidate pair is created with every candidate in the CNC list. These pairs result in the creation of an Rx state machine for each pair of transport addresses with matching component IDs. Tx candidate pairs are also created, but only for the base candidates in the CNC list. The Tx candidate pairs that are created result in Tx state machines for every pair of transport addresses with matching component IDs. Cooper & Matthews Expires December 15, 2006 [Page 11] Internet-Draft Eliminating Duplicate Checks June 2006 3.4.4. Adding Remote Candidates - Peer Reflexive A newly created remote peer reflexive candidate is matched only with the native generating candidate. This creates a single Tx candidate pair and subsequent Tx state machines for each pair of transport addresses with matching component IDs. No Rx candidate pairs or Rx state machines are created for remote peer reflexive transport addresses. 3.5. Promoting Candidates If a native candidate has at least one Rx candidate pair for which every associated Rx state machine is VALID, then the native candidate is eligible for promotion. Following [ICE-08]: o If the native candidate is currently the active candidate, then it is already specified in the m/c line. Nothing more needs to be done and no re-offer is triggered. o If the native candidate is the highest priority candidate, then the candidate is immediately promoted. o Otherwise, the timer Tws is started (if it is not already running). When the timer expires, the eligible candidate with the highest priority (q value) is promoted. As per [ICE-08], when a candidate is promoted the endpoint must encode the remote candidate into the 'a-remote-candidate' attribute. If there is more than one Rx candidate pair to choose from, the remote candidate with the highest priority is selected. 3.6. Removing Candidates A native candidate or remote candidate can be removed from one of the current lists of candidates for reasons described in section 7.11 of [ICE-08]. When this happens, all Rx and Tx candidate pairs and state machines related to that candidate are destroyed. 3.7. Queuing Incoming Binding Requests for Later Processing It is possible for an endpoint to receive a Binding Request where the native and/or remote candidate is not known, but will become known shortly. (Note: This situation also exists in [ICE-08]). For example, the remote candidate will not be known on the Offerer if a Binding Request from the Answerer arrives before the Answer itself. Cooper & Matthews Expires December 15, 2006 [Page 12] Internet-Draft Eliminating Duplicate Checks June 2006 To handle such cases efficiently, an endpoint does some initial processing of the incoming Binding Request, and then queues the Request until the native and/or remote candidate becomes known. Since it is possible for the candidate to never become known, the Binding Request must be discarded after some suitable time (say 100msec). Whenever a candidate is added to the CRC or CNC list, the queue is inspected (in message arrival order) for messages that can now be processed. 3.8. Processing Received Binding Requests This section describes, in bullet form, the processing when a Binding Request arrives on a socket: o Extract username and parse into " ':' ':' ':' ". If there is no username or the parse fails, then this is not an ICE connectivity check, but may be a STUN Binding Request for some other usage. o Look for a native candidate whose candidate id is a prefix of . Call this the . If none, discard packet. [This will happen if the native candidate is a peer-reflexive candidate. Doing the initial processing using the allows for faster discovery of working paths in the cases described in section 3.7. o Using the password associated with , check the message integrity of the packet. If it fails, discard packet. o Check packet for various other errors (e.g., out of range or not equal to ). If it fails, discard packet and (depending on the error) send an error response. o Extract the source transport address (SA) and destination transport address (DA) from the packet. o Send a Success Response. The DA of the Response is the SA of the Request, and the Response is sent on the socket that the request was received. Cooper & Matthews Expires December 15, 2006 [Page 13] Internet-Draft Eliminating Duplicate Checks June 2006 o Search for a Tx state machine whose remote candidate (component) address is equal to SA of the Request, and whose native candidate (component) address is equal to the DA from the Request. If such a Tx state machine is found: o If state == WAITING, remove it from the queue (which causes the Tx state machine to transition to the TESTING state and send a Binding Request). o If state == TESTING, retransmit the Request. o Otherwise, do nothing. [This Tx state machine is sending with the same SA and DA as the Response that was just sent. Since the endpoint just received a Request in the opposite direction, we know that all bindings and permissions are now in place and any previous Request that may been lost should now get through.] o If is not in list of current native candidates or if is not in list of current remote candidates, then queue the request until both candidates become known or until some wait time is exceeded. [See section 3.7. for why this is done]. o Generate an "Rx Req" event into the Rx state machine corresponding to (, , , ). o If the SA of the Request does not match the address of any component of any remote candidate in the list of current candidates, then we have learned a new remote peer-reflexive address. This address is associated with component of a remote candidate with id equal to " ". This new peer-reflexive candidate has the same number of components and the same q value as the candidate . Learning this new address may or may not complete the construction of this new remote candidate, since there may still be other component addresses to learn. If this new address does complete construction of the candidate, then add it to the remote candidate list. 3.9. Processing Received Binding Responses This section describes, in bullet form, the processing when a Binding Response arrives on a socket: Cooper & Matthews Expires December 15, 2006 [Page 14] Internet-Draft Eliminating Duplicate Checks June 2006 o Extract the transaction ID, locate the corresponding request, and determine the , , and of the Request, along with the Tx state machine that send the Request. If there is no such Request, or if the Tx state machine no longer exists, discard the packet. o Check the message integrity of the packet using the password associated with . If it fails, discard the packet. o If the Response is a non-fatal error response, then ignore it (let the Tx state machine retry) and discard the packet. o If the Response is a fatal error response, then send an ERROR event into the Tx state machine and discard the packet. o Else the Response is success response. Send a SUCCESS event into the Tx state machine. o If the mapped address from the packet does not match the transport address of any component of any native candidate in the list of native candidates, then we have learned a new native peer- reflexive address. The address is associated with component of a new native candidate with id equal to " ". This new peer- reflexive candidate has the same number of components and the same q value as the candidate . Learning this new address may or may not complete the construction of the candidate, since there may still be other component addresses to learn. If the new address does complete construction of the candidate, then add it to the native candidate list. 4. Security Considerations This document does not introduce any new security considerations beyond those introduced by [ICE-08]. 5. IANA Considerations This document does not introduce any IANA considerations. 6. Acknowledgments The authors would like to thank all those who read over a preliminary version of this document and gave comments, most particularly Alan Cooper & Matthews Expires December 15, 2006 [Page 15] Internet-Draft Eliminating Duplicate Checks June 2006 Johnston, Benny Rodrig, and Dan Romascanu of Avaya, and Guylain Lavoie of SIP stack vendor M5T. Cooper & Matthews Expires December 15, 2006 [Page 16] Internet-Draft Eliminating Duplicate Checks June 2006 7. References 7.1. Normative References [ICE-08] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic- ice-08, work in progress. [STUNbis] Rosenberg, J. et al, "Simple Traversal of UDP Through Network Address Translators (NAT) (STUN), draft-ietf- behave-rfc3489bis, work in progress. [BEHAVE-UDP] Audet, F. and Jennings, C., "NAT Behavioral Requirements for Unicast UDP", draft-ietf-behave-nat-udp, work in progress. 7.2. Informative References None Author's Addresses Eric Cooper Avaya 1135 Innovation Drive Ottawa, Ontario K2K 3G7 Canada Phone: 613-592-4343 x228 Email: ecooper@avaya.com Philip Matthews Avaya 1135 Innovation Drive Ottawa, Ontario K2K 3G7 Canada Phone: 613-592-4343 x224 Email: philip.matthews@magma.ca 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 Cooper & Matthews Expires December 15, 2006 [Page 17] Internet-Draft Eliminating Duplicate Checks June 2006 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 (2006). 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. Cooper & Matthews Expires December 15, 2006 [Page 18]