Network and Protocol Team M. Hoerdt Internet-Draft Q2S Expires: December 11, 2006 B. Hilt GRTC J-J. Pansiot LSIIT June 9, 2006 Simple join failure notification for PIM-SM multicast routing draft-hoerdt-pim-group-unreachable-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 11, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Currently, PIM-SM is the most widely deployed multicast routing protocol in the Internet. However in IPv6 this multicast protocol lacks a simple connectivity debugging tool, making it difficult to identify multicast routing problems. When a host wants to receive a multicast group or channel, if the corresponding PIM-Join message Hoerdt, et al. Expires December 11, 2006 [Page 1] Internet-Draft Multicast Group Unreachable June 2006 cannot be propagated in the network, nothing exists to inform the receiver or the network about this failure. We propose a simple error notification message based on ICMP/ICMP6 which is able to indicate where and why the error happened in the network without using a multicast traceroute mechanism. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol description . . . . . . . . . . . . . . . . . . . . . 3 2.1. Sending GU Messages . . . . . . . . . . . . . . . . . . . 4 2.2. Receiving/Forwarding GU Messages . . . . . . . . . . . . . 5 3. Message format . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Type and Code . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Checksum . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. L (The 'Last GU Record' bit) . . . . . . . . . . . . . . . 8 3.4. Reserved1 . . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Number of Group Records . . . . . . . . . . . . . . . . . 8 3.6. Router Address . . . . . . . . . . . . . . . . . . . . . . 9 3.7. Group Record . . . . . . . . . . . . . . . . . . . . . . . 9 3.8. Error Code . . . . . . . . . . . . . . . . . . . . . . . . 9 3.9. Reserved2 . . . . . . . . . . . . . . . . . . . . . . . . 9 3.10. Number of Unicast Address . . . . . . . . . . . . . . . . 10 3.11. Multicast Address . . . . . . . . . . . . . . . . . . . . 10 3.12. Unicast Address [i] . . . . . . . . . . . . . . . . . . . 10 4. GU Error codes . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Hoerdt, et al. Expires December 11, 2006 [Page 2] Internet-Draft Multicast Group Unreachable June 2006 1. Introduction With the current specification of PIM-SM [1], when a router cannot propagate a join message, nothing can be done to inform either receivers or downstream routers. Therefore a useless multicast tree is maintained from receivers to the point of failure, while receivers needlessly wait for multicast data. Such a failure may be due for example to a temporary routing problem (a source or RP is not currently reachable), a configuration problem (RP adressing, ...) or a user error (the source address of an SSM channel is not an existing address). The basic proposed idea is to send a downstream error message when a Join message propagation fails at some point in the network. This may occur towards a source (S) both for a PIM-SM[5] SSM channel or for a SPT tree for a PIM-SM[1] ASM group; This may also occur between the DR and the rendez-vous point (RP) for an ASM group. This error message, later on called Group Unreachable or GU, is carried over the ICMP/ICMP6[2][3] protocol. This draft specifies: - the rules used to send and propagate this message down the multicast tree. - the ICMP/GU message format. - the proposed error codes. The message is forwarded hop-by-hop by routers, it is not sent to the group address contained in the failing join. The rules to process this message by multicast hosts is not in the scope of this draft. This mechanism is simpler than a multicast traceroute but still very useful. It provides multicast listeners with a report including both problem location and problem description. It helps network administrators reporting the problem to the person responsible of the good operation of multicast routing for the indicated location. The proposed message could be used by diagnostic applications such as ssmping or asmping[6] to locate the point of failure in case of unreachability. Some user applications could also make use of it, for example to warn the user and/or to leave the corresponding group or channel. As this mechanism requires to be deployed on all multicast routers to operate properly, it requires standardisation. 2. Protocol description When a router R fails to send a Join message towards a rendez-vous point RP or a source S, it triggers the sending of an ICMP/ICMP6 Group Unreachability (GU) message. GU messages MAY aggregate Join failure reasons for several unreachable RP(s)/source(s). In order to locate the point of failure, the GU message contains the address of R. Hoerdt, et al. Expires December 11, 2006 [Page 3] Internet-Draft Multicast Group Unreachable June 2006 To inform all the downstream tree routers and hosts about a failure, a GU message is propagated hop-by-hop downstream the multicast tree concerned by the failure (the tree corresponding to the failing Join message). Along these trees, this information could be taken into account in order to reduce the cost of useless/problematic multicast branches. This is beyond the scope of this document. 2.1. Sending GU Messages GU messages are sent both when a failure occurs on an existing tree or when a new branch is under construction. In both cases, each failed Join message triggers the sending of a GU message. If the failure is due to a transient error such as a temporary routing problem, the router may choose to suppress the GU message. On interdomain links and routers, the number of maintained groups/ channels can be high. A single failure on those links may trigger a high number of GU messages sharing the same point of failure. To reduce the cost of the protocol in this case, GU messages sent on a link MAY aggregate unreachability information for several groups/ channels having receivers through this link. The GU message size is limited to the link MTU. If the number of groups/channels to aggregate exceeds this size, unreachability information is fragmented into multiple GU messages. To avoid the sending of a burst of GU messages, the messages should be rate limited. When a multicast router R is unable to send a group/channel Join message, it builds for each failed group/channel a Group Record containing its failure information like group/channel identification, error code, etc... (detailled format in Section 3). For each outgoing interface of at least one failing tree, the corresponding Group Records are gathered in the same GU Record. Then a GU message, possibly aggregating several GU records for this interface is built. The destination address of the GU messages using this interface MUST be All_Systems_on_this_Subnet group address (224.0.0.1) in IPv4, or ALL_NODES_ADDRESS group address (FF02::1) in IPv6. This ensures that all receivers for the failing group will received the GU message, together with all PIM Routers on the same interface. A further study could determine if the use of a specific multicast address would be more efficient. In this case the destination address would be All_Multicast_Reception_Hosts group address (224.0.0.X) in IPv4 and ALL_MULTI_REC_NODES group address (FF02::X) in IPv6 (X to be defined by IANA). Hoerdt, et al. Expires December 11, 2006 [Page 4] Internet-Draft Multicast Group Unreachable June 2006 2.2. Receiving/Forwarding GU Messages GU messages are forwarded hop-by-hop according to the TIB (Tree Information Base) maintained by the multicast routing protocol. When a router R receives a GU message on an interface: - If the source address of the received message is not the address of a PIM neighbor for the interface the GU message MUST be silently ignored. - If there is no group/channel in the GU message for which the receiving interface is the incoming interface, the message must be silently ignored. The GU message is forwarded on all interested interfaces after a possible trimming. An interface i is interested by the GU if and only if the GU contains a group or channel such that: (1) the GU was received by the incoming interface for this group/ channel (2) interface i is an outgoing interface for this group/channel. The GU sent through interface i is trimmed such that it contains only groups/channels satisfying conditions (1) and (2). (3) Channel unreachability information (concerned by specific source S and group G) is only forwarded hop-by-hop down to a shared tree (*,G) using TIB states if the bit R is set in the GU Record. RP unreachability information is propagated on the shared (*,G) tree without setting this bit. Normally, if a join (S,G) fails the GU is sent only down the (S,G) tree to the DRs (and eventually to the receivers). In some ASM cases a join (S,G) may fail between the RP and the FHR. In this case the GU will travel down to the RP, and if the RP has no outgoing interface for (S,G), the GU will stop there. The RP may choose to propagate the GU(S,G) message down the shared tree. If it do so, the RP MUST take care that this message can be distinguished from regular GU(S,G) messages. The R bit tells that. Note that such a message may help debug a problem between the RP and the source, but this problem may have no direct impact on receivers, if they reach the source by another route. This bit is set by the router propagating a GU(S,G) through the shared tree, and then this GU should be transparently forwarded hop- by-hop down to the shared tree. Several GU messages for the same interface, possibly originating from different routers MAY be aggregated in the same ICMP message. 3. Message format Hoerdt, et al. Expires December 11, 2006 [Page 5] Internet-Draft Multicast Group Unreachable June 2006 Join messages sent by a router summarize for a given interface the group(*,Gn)/channel(Sn,Gn) join state information. These messages are sent to maintain a connection towards the root of the tree (Rendez-vous Point or Source). To inform downstream tree members of a Join propagation failure, each group/channel which cannot be connected to its tree root will be included into a GU message. GU messages are a part of ICMP (in IPv4) or ICMP6 (in IPv6) messages. Over IPv4, GU messages are encapsulated in IPv4 datagrams with a protocol number of 1. Every GU message is sent with an IP Time-To- Live of 1. IPv4 GU message MUST only contain unreachability information about IPv4 addresses. Over IPv6, GU messages are encapsulated in IPv6 packets with a Next Header value of 58. An IPv6 GU messages MUST be sent with a link- local source address, and hop limit set to 1. IPv6 GU message MUST only contain unreachability information about IPv6 addresses. A GU message uses the common ICMP/ICMP6 structure. Each ICMP/GU messages can carry several GU records concerning each an error location (i.e. router interface). In the following text we use ICMP/GU to refer to ICMP/GU or ICMP6/GU messages. So, information specific to a protocol family (IPv4/IPv6) will be specified explicitely. A single Group Records informs about a single group address associated with a single problem notification. GU Records agregate Group Records with the same failing router address. GU messages agregate GU Records which MAY come from different router address. Respective figures 1,2 and 3 explicit the format for GU messages, GU Records and Group Records. New Type and Code values must be used to identify new ICMP/ICMP6 Group Unreachability (GU) messages. Type and Code values must be defined by IANA. This GU header can be common to several GU messages (until reaching MTU value). Each of them regarding failure on a specific router. GU Records on figure 2 have the format presented for 32 bits IPv4 addresses. When using IPv6, all addresses will have a size of 128 bits. Hoerdt, et al. Expires December 11, 2006 [Page 6] Internet-Draft Multicast Group Unreachable June 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . GU Record [1] . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . GU Record [2] . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . GU Record [N] . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 : GU Messages format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Reserved1 | Number of Group Records (M) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Group Record [1] . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | . . . | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Group Record [M] . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 : GU Record format Hoerdt, et al. Expires December 11, 2006 [Page 7] Internet-Draft Multicast Group Unreachable June 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R|S|Res|Err Cde| Reserved2 | Number of Unicast Address (N) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unicast Address [1] | +--- ---+ . . . +--- ---+ | Unicast Address [N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 : Group Record format 3.1. Type and Code Identifies the GU messages in the ICMP/ICMP6 messages family. 3.2. Checksum The checksum is the 16-bit one's complement of the one's complement sum of the whole ICMP/ICMP6 GU message (the entire IP payload). For computing the checksum, the Checksum field is set to zero. When receiving packets, the checksum must be verified before processing the message. 3.3. L (The 'Last GU Record' bit) When an ICMP/GU message carries several GU Records, flag L of the last GU Record MUST be set to 1. All intermediate GU Records MUST have flag L set to 0. If an ICMP/GU message carries a single GU Record, flag L of this record MUST be set to 1. 3.4. Reserved1 The Reserved1 field is reserved for future usage. It is set to zero on emission and ignored on reception. 3.5. Number of Group Records The Number of Group Records (M) specifies how many Group Records (information regarding unreachable group/channel) are present in the GU Record. Hoerdt, et al. Expires December 11, 2006 [Page 8] Internet-Draft Multicast Group Unreachable June 2006 3.6. Router Address The Router Address is used to identify the router on which the Join message propagation failure occurred. This address should be chosen among the routers addresses with the largest scope (ie public addresses for IPv4, global addresses for IPv6 if available). 3.7. Group Record Each Group Record of a GU Record contains information corresponding to a group/channel that could not be propagated in a Join message by the router designated by the Router Address (section Section 3.6). 3.8. Error Code The four fields R,S,Res,Err Cde (Error Code) pertains to the same global error code which gives an indication about the type of failure occuring during the Join message propagation. 3.8.1. R (The 'shaRed' tree bit) The R bit is set when a GU information triggered by a Join (S,G) must be propagated in the shared tree. It is typically used to propagated a failure related to the PIM-SM RP-SPT Switch. 3.8.2. S (The 'Source' or RP bit) The S bit indicates if the Join error is related to a forwarding error towards a Rendez-vous Point (S is set to 0) or towards a Source (S is set to 1). 3.8.3. Res These two bits are reserved for a future usage. They are set to zero on emission and ignored on reception. 3.8.4. Error Cde The Err Cde (Error Code) field is a code that defines a more precise error type if known. A first list of possible error Code values and their signification is given in Section 4. 3.9. Reserved2 The Reserved field is reserved for future usage. It is set to zero on emission and ignored on reception. Hoerdt, et al. Expires December 11, 2006 [Page 9] Internet-Draft Multicast Group Unreachable June 2006 3.10. Number of Unicast Address The Number of Unicast Address (N) field specifies how many unicast IPv4/IPv6 addresses (RP/Sources) are present in this Group Record. This allows to determine the size of the current Group Record 3.11. Multicast Address The Multicast Address field contains the IPv4/IPv6 multicast group address to which this Group Record pertains. 3.12. Unicast Address [i] The Unicast Address list is a vector of n IPv4/IPv6 unicast addresses, where n is the value in this record's Number of Unicast Addresses (N) field. The unicast addresses are either Rendez-vous Point or Source addresses depending on the S flag of this record. If the S bit is set to 0, this error occured in the ASM shared tree towards the RP. In this case Unicast Address [0] is the RP address contained in the failing Join message, while Unicast Address [1] is the RP address known for this group in this router or the NULL address if there is no local RP information for this group. If the S bit is set to 1, this error occured in an SSM or an ASM SPT tree. The list of Unicast Adresses is the list of failing sources for the same group, usually only one in the SSM case. 4. GU Error codes The error code indicates the reason of the failure incured by a Join message forwarded hop-by-hop towards a source (S), if bit S is set or a Rendez-vous Point (RP), if bit S is cleared. Code values and signification are proposed in the table below. They are only suggestions to future definition by IANA. Hoerdt, et al. Expires December 11, 2006 [Page 10] Internet-Draft Multicast Group Unreachable June 2006 S | Value | Name | Description ------------------------------------------------------------------- x | 0x1 | NO_MCAST_IF | The interface pointing to the nexthop | | | towards the source or the RP is not | | | enabled for multicast. ---|-------|----------------|-------------------------------------- x | 0x2 | NO_MCAST_NEIGH | The next hop towards the source or | | | the rendez-vous point is not a | | | multicast capable neighbor. ---|-------|----------------|-------------------------------------- x | 0x3 | NO_ROUTE | The router has no route for the | | | source or for the RP of the group. ---|-------|----------------|-------------------------------------- 0 | 0x4 | ERR_RP | The router cannot match a proper | | | Rendez-vous point for the desired | | | joined groupe. For instance, the RP | | | mentioned in the (*,G) part | | | of a Join message may be different | | | from the local RP information for | | | that group. ---|-------|----------------|-------------------------------------- x | 0x5 | SCOPED | The group or channel is subject to | | | administrative scoping at this hop. ---|-------|----------------|-------------------------------------- x | 0x6 | FILTERED | The group or channel is subject to | | | administrative filtering at this hop. ---|-------|----------------|-------------------------------------- 0 | 0x7 | NO_ASM_ADDR | The group address specified in an ASM | | | Join pertains to a SSM group address | | | for that router. ---|-------|----------------|-------------------------------------- x | 0xF | NOT_FWD | The router is not forwarding this | | | group/source for an unspecified | | | reason. ---|-------|----------------|-------------------------------------- Table 1 : GU error codes The x value indicates that the error code may be used for both values of S. 5. Security Consideration A GU message is an informational message. In this proposal it is only forwarded by routers and does not interact much more with them. With this proposal, an important number of non-existent trees could Hoerdt, et al. Expires December 11, 2006 [Page 11] Internet-Draft Multicast Group Unreachable June 2006 be joined by a set of malicious hosts in the network, possibly triggering a storm of GU messages and exausting the ressources available by trying to signal a malicious error case. This control plane attack is already possible without the GU message [4]. GU messages rate limitation MUST be available in order to minimize the additionnal cost on the network ressources in this kind of attack. The detailed usage of information carried by the GU message is out of the scope of this draft but Forged GU messages could be sent in non failing trees making the receivers believe that the multicast connection failed at some point in time. To prevent that, only GU messages from known neighbors SHOULD be accepted by routers propagating the unreachability information. 6. Acknowledgments The authors would like to thanks Stig Venaas and Jerome Durand for the early reviewing and comments on this work. 7. References 7.1. Normative References [1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", mar 2006. [2] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [3] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. 7.2. Informative References [4] Savola, P., Lethonen, R., and D. Meyer, "PIM-SM Multicast Routing Security Issues and Enhancements (draft-ietf-mboned-mroutesec-04.txt)", oct 2004. [5] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", jul 2003. [6] Venaas, S., "Source Specific and Any Source multicast ping (http://www.venaas.no/multicast/ssmping/)", apr 2005. Hoerdt, et al. Expires December 11, 2006 [Page 12] Internet-Draft Multicast Group Unreachable June 2006 Authors' Addresses Mickael Hoerdt Q2S E-216 Elektro-E Q2S Center of Excellence Trondheim NO-7491 NORWAY Phone: +47 73 55 02 67 Email: hoerdt@q2s.ntnu.no URI: http://www.q2s.ntnu.no/~hoerdt/ Benoit Hilt GRTC IUT de Colmar BP 50568 Colmar Cedex 68008 FRANCE Phone: +33 3 89 20 23 64 Email: benoit.hilt@uha.fr Jean-Jacques Pansiot LSIIT Universite Louis Pasteur Strasbourg Pole API, bureau C447 Boulevard Sebastien Brant Illkirch 67400 FRANCE Phone: +33 3 90 24 45 63 Email: pansiot@clarinet.u-strasbg.fr URI: http://clarinet.u-strasbg.fr/~pansiot/ Hoerdt, et al. Expires December 11, 2006 [Page 13] Internet-Draft Multicast Group Unreachable June 2006 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 (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. Hoerdt, et al. Expires December 11, 2006 [Page 14]