MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.) Internet-Draft INRIA Expires: August 28, 2008 February 25, 2008 Address Autoconfiguration for MANET: Terminology and Problem Statement draft-ietf-autoconf-statement-04 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 August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Baccelli (Ed.) Expires August 28, 2008 [Page 1]
Internet-Draft MANET Autoconf Problem Statement February 2008 Abstract This document states the problems pertaining to automatic IPv6 address configuration and prefix allocation in MANETs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. MANET Categories . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Subordinate MANET . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Scenarios of Subordinate MANETs . . . . . . . . . . . 6 3.2. Autonomous MANET . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Scenarios of Autonomous MANETs . . . . . . . . . . . . 7 4. MANET Autoconfiguration Goals . . . . . . . . . . . . . . . . 8 5. Applicability of standard configuration solutions . . . . . . 9 5.1. Applicability of DHCP . . . . . . . . . . . . . . . . . . 9 5.1.1. Issues with DHCP Fundamental Assumptions . . . . . . . 9 5.1.2. What DHCP Can and Cannot Do in MANETs . . . . . . . . 10 5.2. Applicability of SLAAC/NDP . . . . . . . . . . . . . . . . 10 5.2.1. Issues with SLAAC/NDP Fundamental Assumptions . . . . 10 5.2.2. What SLAAC/NDP Can and Cannot Do in MANETs . . . . . . 11 5.3. Applicability of DHCP-PD . . . . . . . . . . . . . . . . . 11 5.3.1. Issues with DHCP-PD Fundamental Assumptions . . . . . 11 5.3.2. What DHCP-PD Can and Cannot Do in MANETs . . . . . . . 11 6. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Solutions Requirements . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 20 Editor's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Baccelli (Ed.) Expires August 28, 2008 [Page 2]
Internet-Draft MANET Autoconf Problem Statement February 2008 1. Introduction As defined in [1], a MANET is a network composed of MANET routers, each of which has at least one MANET interface. This document states the goals of autoconfiguration mechanism(s) for MANETs, with respect to the necessary parameters for basic IP identification. Specifically, this document thus states the requirements for: - autoconfiguring MANET interfaces with IPv6 addresses; - automatic allocation of IPv6 prefixes to MANET routers. Baccelli (Ed.) Expires August 28, 2008 [Page 3]
Internet-Draft MANET Autoconf Problem Statement February 2008 2. Terminology This document uses the terminology defined in [1], as well as the following terms : External Network - a network connected to the MANET, through an interface that is not part of this MANET. Subordinate MANET - a MANET, which is connected to one or more external network(s), and where such external network(s) are imposing an addressing hierarchy scheme on the MANET. Autonomous MANET - a MANET upon which no external network imposes an addressing hierarchy. Address autoconfiguration - the process of configuring an interface with a given address, using an automatic mechanism (contrary to manual configuration). Prefix allocation - the process of providing a router with authority over an aggregatable pool of addresses (i.e. a prefix), for the purpose of configuring its interfaces, or other nodes. Disjoint prefixes - two prefixes are said to be disjoint if and only if their respective address ranges do not overlap. Network merging - the process by which two or more previously disconnected MANETs get connected. Network partitioning - the process by which a MANET splits into two or more disconnected MANETs. Baccelli (Ed.) Expires August 28, 2008 [Page 4]
Internet-Draft MANET Autoconf Problem Statement February 2008 3. MANET Categories IP address autoconfiguration on MANET interfaces and prefix allocation for MANET routers may be used in a number of deployment scenarios. This section outlines the different types of scenarios that are to be addressed by solutions for MANET autoconfiguration. 3.1. Subordinate MANET A subordinate MANET, as shown in Fig. 1, is a MANET which is connected to at least one external network N that imposes a specific addressing hierarchy on the MANET. In a subordinate MANET, this addressing hierarchy yields the use of specific prefixes for communications between nodes in the MANET and nodes in or across network N. For instance, in Fig. 1, these prefixes need to be topologically correct, i.e. allocated from within a prefix p::, over which the point of attachment to network N has authority. '. / `. Network N / `. _,' `-.__ _,,' `'-.,._,,'' : Topologically correct prefix +-:-+ p:: with respect to network N |MNR| +-|-+ +-+ +---+ / /|\ \ +---+ | |...MNR--- .-. ---MNR| +-+ +---+ \ ,-( _)-. / +---+ .-(_ MANET )-. Other ( Communication ) Nodes `-(______)-' and \|/ \|/ Networks +-|-+ +-|-+ |MNR| \|/ |MNR| +-:-+ +-|-+ +-:-+ |MNR| : +-:-+ +-+ +-+ Figure 1: Subordinate MANET. Imposed address hierarchy by external network N. Baccelli (Ed.) Expires August 28, 2008 [Page 5]
Internet-Draft MANET Autoconf Problem Statement February 2008 3.1.1. Scenarios of Subordinate MANETs This section contains a non-exhaustive list of examples of MANETs falling in the subordinate category. A typical example of subordinate MANET is a MANET that is part of the Internet, which yields the use of topologically correct IP addresses in order to communicate over the Internet. For instance public wireless mesh networks, i.e. scattered fixed WLAN access routers participating in a MANET of mobile users, and acting as border routers. Another typical example is the coverage extension of a fixed wide- area wireless network, where one or more MANET router(s) are connected to the Internet through technologies such as UMTS or WiMAX. Vehicle communication networks connected to an external infrastructure may also be understood as an instance of subordinate MANET. 3.2. Autonomous MANET Autonomous MANETs are MANETs upon which no external network imposes an addressing hierarchy. This is shown in Fig. 2, as opposed to the subordinate MANET category described in Section 3.1. +---+ |MNR| +-|-+ +-+ +---+ / /|\ \ +---+ | |...MNR--- .-. ---MNR| +-+ +---+ \ ,-( _)-. / +---+ .-(_ MANET )-. Other ( Communication ) Nodes `-(______)-' and \|/ \|/ Networks +-|-+ +-|-+ |MNR| \|/ |MNR| +-:-+ +-|-+ +-:-+ |MNR| : +-:-+ +-+ +-+ Figure 2: Autonomous MANET. No subordination to an addressing scheme imposed by an external network. Baccelli (Ed.) Expires August 28, 2008 [Page 6]
Internet-Draft MANET Autoconf Problem Statement February 2008 3.2.1. Scenarios of Autonomous MANETs This section contains a non-exhaustive list of instances of MANETs falling in the autonomous category. Typical examples of autonomous MANETs are networks set-up in areas where infrastructure is unavailable or inappropriate. For instance, car-to-car communication for sharing traffic and safety-related information, on-site emergency communication among rescue team members for disaster recovery, file sharing in conference or class rooms. Baccelli (Ed.) Expires August 28, 2008 [Page 7]
Internet-Draft MANET Autoconf Problem Statement February 2008 4. MANET Autoconfiguration Goals The goals of AUTOCONF is to provide autoconfiguration mechanisms which allow each MANET router to: 1. configure IPv6 addresses that are unique within the MANET, on their MANET interface(s). 2. be allocated IPv6 prefixes that are disjoint from prefixes allocated to other routers within the MANET. 3. maintain, within the MANET, the uniqueness of configured addresses and the disjoint character of allocated prefixes (even in case of network merging). 4. be allocated topologically correct prefixes, in the subordinate MANET scenario. Baccelli (Ed.) Expires August 28, 2008 [Page 8]
Internet-Draft MANET Autoconf Problem Statement February 2008 5. Applicability of standard configuration solutions This section reviews the applicability of existing standard protocols for the purposes listed in Section 4. Note that MANET routers are assumed to also run these standard protocols as usual over non-MANET interfaces, if any. 5.1. Applicability of DHCP DHCP [4] enables automatic allocation of an IP address to a node by a DHCP server. A node requiring an IP address contacts a DHCP server and requests an address. The DHCP server will dynamically assign an address from a certain pool of addresses, and allocate a so called ''lease'' of that address to the client. The client can then use the address for a certain time. If the client wants to keep the address for a longer time, it has to prolong the lease. If the DHCP server is not on the same link as the DHCP client, it is possible to use one or more DHCP relay agent to forward the messages to a different subnet. 5.1.1. Issues with DHCP Fundamental Assumptions DHCP works on the basic assumption that every node in the MANET can directly communicate with either (i) the DHCP server, or (ii) a DHCP relay which can communicate with either the DHCP server or another relay. As described in [1], part (i) of this assumption is often wrong in a MANET, as each node may see a different set of neighboring MANET nodes. On the other hand, part (ii) of this assumption relies on the guarantee that the recursion will end at some point (by reaching the root, i.e. the DHCP server). Because of the dynamics in MANET topology and MANET membership described in [1], there is no such assurance in a MANET, as the DHCP server may be unreachable, or a loop may have appeared along the path. Moreover, DHCP works with the assumption that either (a) there is a unique DHCP server in the network, or (b) if there are several DHCP servers in the network, they are manually configured accordingly. Because of the dynamics in MANET membership described in [1], there is no such assurance in a MANET, as topology changes may produce a situation where several servers with conflicting configuration parameters (e.g. managing non-disjoint pools of local addresses) become part of the same MANET. Servers may thus require dynamic (re)configuration. Similarly, DHCP works with the assumption that should there be DHCP relays, they benefit from appropriate manual configuration. Because Baccelli (Ed.) Expires August 28, 2008 [Page 9]
Internet-Draft MANET Autoconf Problem Statement February 2008 of the dynamics in MANET membership and topology described in [1], there is no such assurance in a MANET. Configuration may not remain appropriate over time, and relays may thus require dynamic (re)configuration. 5.1.2. What DHCP Can and Cannot Do in MANETs DHCP "as is" could be used to some extent for address configuration purposes (goal 1, listed in Section 4). However DHCP's applicability in this context is limited. Indeed, if the topology is or becomes such that a MANET router does not have access to a DHCP server directly nor through a relay, DHCP is not operational. DHCP "as is" could also be used to some extent for uniqueness maintenance purposes (goal 3, listed in Section 4). However DHCP's applicability in this context is limited. Since different DHCP servers will not automatically check the disjoint character of the pools of addresses they provide leases from, if the topology is or becomes such that several DHCP servers with conflicting configuration lease addresses in the same MANET, there is no guarantee that configured addresses will indeed be unique. 5.2. Applicability of SLAAC/NDP Stateless Address Autoconfiguration (SLAAC [5]) enables automatic configuration of an IP address to a host without contacting any kind of server. A host first constructs a tentative IPv6 address by attaching its host identifier (in most cases its MAC address) to the well-known link-local prefix. It then operates duplicate address detection, that verifies that no other host on the link has the same address by broadcasting NDP messages [3]. If the address is not unique, the autoconfiguration process will abort. Upon a successful address uniqueness test, a host may request a prefix from any router on the link by an exchange of NDP messages. It will again attach its host identifier to that router prefix and repeats the address uniqueness test sequence. 5.2.1. Issues with SLAAC/NDP Fundamental Assumptions SLAAC relies on NDP signalling, which works on the basic assumption that each node in the MANET can communicate directly with every other node in the MANET, i.e. all the nodes are connected to a single multicast-enabled link. As described in [1], this assumption is often wrong in a MANET, as each node may see a different set of neighboring MANET nodes. Baccelli (Ed.) Expires August 28, 2008 [Page 10]
Internet-Draft MANET Autoconf Problem Statement February 2008 5.2.2. What SLAAC/NDP Can and Cannot Do in MANETs SLAAC "as is" could be used to some extent for address configuration and uniqueness maintenance purposes (goal 1 and 3, listed in Section 4), for instance when no DHCP server is available. However SLAAC's applicability in this context is limited, since NDP messages are not relayed beyond the ''link'' (or in MANET terms, beyond the first hop). If topology is or becomes such that the MANET is not contained in a single hop, there is no guarantee that the configured addresses will indeed be unique, since signalling will not reach all the concerned nodes. 5.3. Applicability of DHCP-PD DCHP-PD [17] is a DHCP option that enables automatic allocation of IPv6 prefixes to routers using DHCP. A router may request a prefix allocation from a DHCP server by sending a DHCP request including the Prefix Delegation option. The server may then delegate a sub-prefix (i.e. a subset of its address pool) to the router. The DHCP message containing the Prefix Delegation option may be relayed through one or more DHCP relays, as per [4]. 5.3.1. Issues with DHCP-PD Fundamental Assumptions DHCP-PD is based on DHCP, and thus encounters the fundamental issues described in Section 5.1.1, with respect to server reachability, and dynamic (re)configuration of servers and relays. 5.3.2. What DHCP-PD Can and Cannot Do in MANETs DHCP-PD "as is" could be used to some extent for prefix allocation purposes (goals 2 and 4 listed in Section 4) and for uniqueness maintenance purposes (goal 3, listed in Section 4). However DHCP- PD's applicability in this context is limited. If topology is or becomes such that the MANET router cannot communicate with a DHCP server, DHCP-PD is not operational. Moreover, if topology is or becomes such that several servers with conflicting configuration become part of the same MANET, there are no automatic (re)configuration mechanisms available in order for servers to dynamically adapt to the situation. Baccelli (Ed.) Expires August 28, 2008 [Page 11]
Internet-Draft MANET Autoconf Problem Statement February 2008 6. Problem Statement SLAAC, NDP, DHCP and DHCP-PD provide only a partial solution with respect to the goals listed in Section 4. As explained in Section 5.1, Section 5.2, and Section 5.3, existing protocols "as is" cannot deal with the specific dynamic, multi-hop and distributed nature of MANETs. Additional solutions are thus needed to complete the goals of MANET IPv6 autoconfiguration. 6.1. Solutions Requirements The following list presents the requirements for potential IPv6 address autoconfiguration solutions: R 01. Solutions must configure MANET interfaces with IPv6 addresses that are unique within the MANET. R 02. Solutions must configure routers within the same MANET with disjoint prefixes. R 03. Solution must work even without a MANET routing protocol. However, solutions may leverage the presence of routing protocols, for optimization purposes. R 04. Solutions must provide a mechanism to prevent and deal with address or prefix conflicts (due for instance to network merging, change in MANET membership, preconfiguration or misconfiguration). R 05. Solutions must be designed taking into account the particular characteristics of MANETs [1], including their multi-hop nature, and the potential asymetry of links. R 06. Solutions must achieve their goal(s) with low control overhead. R 07. Solutions must achieve their goal(s) with low delay or convergence time. R 08. Solutions must ensure backward compatibility with other standards defined by the IETF. R 09. Solutions must not require modifications of existing protocols on non-MANET interfaces and non-MANET routers. R 10. Solutions should address security threats considered in existing IPv6 autoconfiguration mechanisms. In addition, solutions should address potential MANET-specific threats (see Section 7). Baccelli (Ed.) Expires August 28, 2008 [Page 12]
Internet-Draft MANET Autoconf Problem Statement February 2008 R 11. Solutions should work in MANETs connected to an external network via multiple border routers, as well as in MANETs connected to multiple external networks. R 12. In the case of subordinate MANETs, solutions should have a minimal impact on the routing system of the external network(s) to which a MANET is connected. In particular, this includes the following: R 12.1. Solutions should not preclude prefix aggregation at the edge of the subordinate MANETs. R 13. Solutions should support transitioning from one MANET scenario to another (e.g. from subordinate to autonomous or vice-versa). R 14. Solutions may be designed in a modular way, each module addressing a specific subset of the requirements or scenarios. Baccelli (Ed.) Expires August 28, 2008 [Page 13]
Internet-Draft MANET Autoconf Problem Statement February 2008 7. Security Considerations A significant security issue is that of maintaining the confidentiality and the integrity of some data being exchanged between communication end-points in the MANET (e.g. between a server and a client). This task is equivalent to that of ensuring end-to- end security in other types of networks, and existing techniques are therefore applicable. An orthogonal issue with respect to securing MANET protocols is ensuring network integrity. So far, MANET protocols in general allow any node to participate in the network - the assumption being that all nodes are well-behaving and welcome. If that assumption fails, i.e. if the network may count malicious nodes, the integrity of the network may fail. Specific malicious behaviour include, but are not limited to, jamming (resulting in DoS), incorrect traffic generation (e.g. server, router or address spoofing), incorrect traffic relaying (e.g. "man in the middle"), or replay attacks. Most of these threats are already taken into account in RFC 3756, RFC 3971, and the security sections of RFC 4861 and RFC 3315. DoS attacks can highly penalize the operation of IP autoconfiguration solutions, through increasing the signalling overhead and hence harming the solutions' convergence time. "Man-in-the-middle" attacks can cause (i) interception of the IP autoconfiguration messages and hence operation failure, (ii) messages' modifications leading for example to changing assigned IP addresses or prefixes during their transfer and hence causing address or prefix conflicts, (iii) impersonation, which allows a non-legitimate MANET router to participate in the IP autoconfiguration process in place of a legitimate node, and may lead to DoS. On the other hand, IP spoofing can also lead to impersonation, whereby an IP address can be spoofed by a non-legitimate node during transfer. Existing security solutions usually protect network integrity through authentication guaranteed by a "higher" authority, trusted a priori, which typically issues the cryptographic keys used to authenticate. However, for instance in autonomous MANET scenarios, there may not be any "higher" authority, or if there is, it may not be trusted a priori by every node in the MANET. Encryption is thus essential to many existing security mechanisms. However it may affect convergence time or require a process that is too heavy in the context of MANETs, since a significant part of the nodes in a MANET may have limited resources. Another issue specific to MANETs is related to the potential selfishness behaviour of some MANET nodes, a.k.a. "the selfish node Baccelli (Ed.) Expires August 28, 2008 [Page 14]
Internet-Draft MANET Autoconf Problem Statement February 2008 problem". This behaviour can cause non-cooperation between MANET nodes during the IP autoconfiguration process, and hence affect the operation of autoconfiguration mechanisms. In the context of MANET IPv6 autoconfiguration, such MANET characteristics are to be considered in addition to general characteristics supported by existing IPv6 autoconfiguration solutions. Baccelli (Ed.) Expires August 28, 2008 [Page 15]
Internet-Draft MANET Autoconf Problem Statement February 2008 8. IANA Considerations This document does not specify IANA considerations. Baccelli (Ed.) Expires August 28, 2008 [Page 16]
Internet-Draft MANET Autoconf Problem Statement February 2008 9. References 9.1. Normative References [1] Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc Network Architecture", ID draft-ietf-autoconf-manetarch, February 2007. 9.2. Informative References [2] Macker, J. and S. Corson, "MANET Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, January 1999. [3] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IPv6", RFC 4861, September 2007. [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6", RFC 3315, July 2003. [5] Narten, T., Thomson, S., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [6] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [7] Draves, R. and D. Thaler, "Default Router Preferences and More- Specific Routes", RFC 4191, 2005. [8] Moy, J., "OSPF version 2", RFC 2328, 1998. [9] Moy, J., Coltun, R., and D. Ferguson, "OSPF for IPv6", RFC 2740, 1999. [10] Chakeres, I., "Internet Assigned Numbers Authority (IANA) Allocations for the Mobile Ad hoc Networks (MANET) Working Group", ID draft-ietf-manet-iana, May 2007. [11] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 2001. [12] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, 2001. [13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, 2005. [14] Aura, T., "Cryptographically Generated Addresses (CGA)", Baccelli (Ed.) Expires August 28, 2008 [Page 17]
Internet-Draft MANET Autoconf Problem Statement February 2008 RFC 3972, 2005. [15] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, 2006. [16] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, 2005. [17] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6", RFC 3633, 2003. Baccelli (Ed.) Expires August 28, 2008 [Page 18]
Internet-Draft MANET Autoconf Problem Statement February 2008 Contributors Shubhranshu Singh, Samsung. Email: Shubranshu@gmail.com Kenichi Mase, Niigata University. Email: Mase@ie.niigata-u.ac.jp Simone Ruffino, Telecom Italia. Email: Simone.Ruffino@telecomitalia.it Carlos J. Bernardos, Universidad Carlos III de Madrid. Email: cjbc@it.uc3m.es Hassnaa Moustafa, France Telecom. Email: Hassnaa.Moustafa@orange-ftgroup.com Emmanuel Baccelli, INRIA. Email: Emmanuel.Baccelli@inria.fr Thomas Heide Clausen, LIX, Ecole Polytechnique. Email: T.Clausen@computer.org Baccelli (Ed.) Expires August 28, 2008 [Page 19]
Internet-Draft MANET Autoconf Problem Statement February 2008 Acknowledgements This document benefited from specific feedback, and helpful discussions with C. Adjih, T. Boot, C. Dearlove, U. Herberg, G. Montenegro, C. Perkins, A. Petrescu, P. Ruiz, P. Stupar, F. Templin, D. Thaler, R. Wakikawa, K. Weniger. Baccelli (Ed.) Expires August 28, 2008 [Page 20]
Internet-Draft MANET Autoconf Problem Statement February 2008 Editor's Address Emmanuel Baccelli INRIA Phone: +33 1 69 33 55 11 Email: Emmanuel.Baccelli@inria.fr Baccelli (Ed.) Expires August 28, 2008 [Page 21]
Internet-Draft MANET Autoconf Problem Statement February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Baccelli (Ed.) Expires August 28, 2008 [Page 22]
