MANET Autoconfiguration (AUTOCONF) C. Bernardos Internet-Draft M. Calderon Intended status: Informational I. Soto Expires: May 6, 2009 UC3M November 2, 2008 Requirements for IP Autoconfiguration Mechanisms in Backbone Wireless Mesh Network scenarios draft-bernardos-autoconf-backbone-mesh-reqs-01 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 May 6, 2009. Abstract This Internet Draft presents the multi-hop Backbone Wireless Mesh Network scenario, summarising its basic characteristics and describing the requirements and desired properties of an IP Autoconfiguration mechanism aimed at being used in this kind of networks. Once that the AUTOCONF WG has almost finalised the documents that describe the general architecture of MANETs and the IP autoconfiguration problem statement in MANETs, the WG is expected to start working on solutions. This document describes an ad-hoc Bernardos, et al. Expires May 6, 2009 [Page 1] Internet-Draft AUTOCONF Mesh Requirements November 2008 scenario that is getting a lot of attention from both telecommunication operators and end-users: Backbone/infrastructure Wireless Mesh Networking. This document identifies and explains the requirements posed by this particular scenario to an IP autoconfiguration mechanism. The goal is to help the AUTOCONF WG identify the requirements that need to be taken into account when designing IP autoconfiguration solution(s) suitable for this Wireless Mesh environment. Table of Contents 1. Introduction and motivation . . . . . . . . . . . . . . . . . 3 2. The Wireless Mesh networking scenario . . . . . . . . . . . . 3 3. IP autoconf requirements posed by the Backbone WMN scenario . 6 3.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Mobility type . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Address uniqueness . . . . . . . . . . . . . . . . . . . . 7 3.4. Merging support . . . . . . . . . . . . . . . . . . . . . 8 3.5. Partitioning support . . . . . . . . . . . . . . . . . . . 8 3.6. Prefix delegation support . . . . . . . . . . . . . . . . 8 3.7. Protocol overhead . . . . . . . . . . . . . . . . . . . . 9 3.8. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 9 3.9. Convergence time . . . . . . . . . . . . . . . . . . . . . 9 3.10. Scalability . . . . . . . . . . . . . . . . . . . . . . . 10 3.11. Address space utilisation . . . . . . . . . . . . . . . . 10 3.12. Distributed/Centralised approach . . . . . . . . . . . . . 10 3.13. Trust and security . . . . . . . . . . . . . . . . . . . . 10 3.14. Integration with standard IPv6 nodes . . . . . . . . . . . 11 3.15. Gateway involvement . . . . . . . . . . . . . . . . . . . 11 3.16. Routing protocol dependency . . . . . . . . . . . . . . . 11 3.17. Multiple interfaces support . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Bernardos, et al. Expires May 6, 2009 [Page 2] Internet-Draft AUTOCONF Mesh Requirements November 2008 1. Introduction and motivation The multi-hop nature of ad-hoc networks and its lack of a single multicast-capable link for signalling prevents current IP address autoconfiguration related protocol specifications (such as RFCs 2461, 2462, etc.) to be used as-is in ad-hoc networks. Some limitations of these existing solutions are stated in [1] and they mainly concern: the lack of multi-hop support, the lack of dynamic topology support, the lack of network merging support and the lack of network partitioning support. The main purpose of the AUTOCONF WG is to standardise mechanisms to be used by ad-hoc nodes for configuring unique local and/or globally routable IPv6 addresses. The ad-hoc nodes under consideration are, once configured, expected to be able to support multi-hop communication by running MANET routing protocols as developed by the IETF MANET WG. Once that the AUTOCONF WG has almost finalised the documents that describe the general architecture of MANETs [2] and the IP autoconfiguration problem statement in MANETS [1], the WG is chartered to start working on the standardisation of IP autoconfiguration solutions. In this context, this document reviews and describes a particular ad-hoc scenario that is getting a lot of attention from both telecommunication operators and end-users: Backbone/Infrastructure Wireless Mesh Networking. This document identifies and explains the requirements posed by this particular scenario to an IP autoconfiguration mechanism. The goal is to help the AUTOCONF WG identify the requirements that need to be taken into account when designing IP autoconfiguration solution(s) suitable for the Wireless Mesh environment. 2. The Wireless Mesh networking scenario Wireless networks are evolving to provide better services with lower deployment costs. Ad-hoc networking as shown itself as one promising technology in many applicability scenarios. The ad-hoc term is highly overloaded nowadays and it usually comprises many different network architectures, with disparate characteristics and requirements. As an example, today we can find several instances of ad-hoc networks: Mobile Ad-hoc Networks (MANETs), sensor networks, Vehicular Ad-hoc Networks (VANETs), Wireless Mesh Networks (WMNs), etc. All of them share their multi-hop, unmanaged and decentralised nature, but also present very important differences. In this document, we pay attention to Wireless Mesh Networks, as one particular type of ad-hoc network that today is gaining momentum, mainly due to the interest from both end-users and telcos. Bernardos, et al. Expires May 6, 2009 [Page 3] Internet-Draft AUTOCONF Mesh Requirements November 2008 In a Wireless Mesh Network [3], nodes are comprised of mesh routers and mesh clients. Each node operates not only as a host, but also as a router, forwarding packets on behalf of other nodes that are not within direct wireless reachability of their destinations. WMNs are dynamically self-organised and self-configured, with their nodes automatically setting-up and maintaining mesh connectivity among themselves. WMNs are considered to be a very promising technology for a broad number of applications, such as community and neighbourhood networks, building automation, emergency networks, broadband home networking, carrier backhaul solutions, etc. A number of variants of WMNs exist today, basically differing from the intended end-use and the mobility of their nodes. As an example, a well known classification of WMNs distinguishes among the following types: o Infrastructure/Backbone WMNs. Basically, this type of WMN is composed of wireless mesh routers providing an infrastructure for clients to connect to them. One of the possible applications of this type of WMNs is to serve as a carrier backhaul for a telecommunications operator, providing backbone for conventional clients. While mesh-based solutions can be used both in temporary and permanent scenarios, their usage is particularly advantageous in situations where the network infrastructure is only needed for short time periods. In these situations, the deployment of a backhaul infrastructure based on current solutions requires a very high investment which is usually uneconomical for such a short duration; a mesh-based solution provides a much more cost effective way of satisfying this short-term demand. A good example of such a temporary scenario that can greatly benefit from a mesh-based solution is the London 2012 Olympic Games. Besides this kind of "planned wireless mesh deployment", we may consider also an additional and very interesting example of application of backbone WMN: the Neighbourhood/Community Networks, which can be considered as an example of "unplanned wireless mesh deployment". o Client WMNs. This type of WMNs provides peer-to-peer networks among client devices. Therefore, in this architecture, the client nodes are the ones constituting the actual network to perform routing, configuration and service provisioning to customers. This type of networks does not require mesh routers. Compared to the previous type of WMNs, this imposes more requirements on the end-users, since they must perform additional functions such as routing and self-configuration. Examples of client WMNs include: meeting networks, file sharing networks, entertainment networks for gaming, etc. o Hybrid WMNs. This architecture is actually the combination of the previous two ones (Infrastructure and Client WMNs), in which mesh clients can access the network both through mesh routers and directly through other clients. Bernardos, et al. Expires May 6, 2009 [Page 4] Internet-Draft AUTOCONF Mesh Requirements November 2008 ------------------------- -( )- -( )- ( ) ( Internet ) ( ) -( )- -( )- -+----------+----------+- / | \ / | \ / | \ ----+---- ----+---- ----+---- | WMN R +.-.-.-+ WMN R +.-.-.-+ WMN R | ----+---- ---+-+--- ----+---- . . . . \ / \ / . . . . \ / \ / --+---+-- --+---+-- | WMN R +.-.-.-.+ WMN R | -+----+-- ----+---- * * * * * * * * * * * ----+----- * * | Client | ----+----- -----+---- ---------- ! Client | | Client | ---------- ---------- ----------------------------- | WMN R: Mesh Router | | Client: IPv6 Client | ----------------------------- Figure 1: Backbone WMN scenario Since Infrastructure/Backbone WMNs are a very relevant and common type of WMN -- which is receiving a lot of attention today --, that differs from general MANET scenarios, this document will focus on this type of WMN (Figure 1). While a Backbone WMN share many common characteristics with classical ad-hoc networks, we may highlight the following key differences: o Low/null node mobility. Mesh routers will usually present minimal (if any) mobility. Changes in the network topology will be mainly caused by variations in the wireless radio link characteristics and by WMN routers being switched on/off (that is, joining/leaving Bernardos, et al. Expires May 6, 2009 [Page 5] Internet-Draft AUTOCONF Mesh Requirements November 2008 the network). o Infrastructure-connected. While we can differentiate between standalone and connected when considering generic ad-hoc networks, WMNs are expected to be always connected to the Internet. Backbone WMNs (or parts of them) could be temporarily disconnected, but only because some kind of trouble, and therefore the standalone mode of operation does not need to be necessarily considered. o Multiple gateway nature. Since Backbone WMNs are characterised for its Internet connectivity, they will likely require to benefit from deploying multiple Border Routers/Internet gateways to provide attached nodes with Internet connectivity. o Compatibility with existing wireless networks, Internet protocols and legacy nodes. Backbone WMNs are expected to provide connectivity to non ad-hoc/legacy clients. Therefore, existing IPv6 nodes should be able to attach to a Backbone WMN (using an unmodified wireless/wired access protocol) and gain Internet connectivity through it. o Scalability. Although it is difficult to predict and it will be mostly dependant on the particular deployment, Backbone WMNs may be composed of up to hundreds (even thousands) of devices and, therefore, special attention should be paid to the scalability of the protocols designed to work in Backbone WMNs. o Low power-consumption constraints. Mesh routers usually will not have any strong constraint on power consumption. o Multiple types of access. While generally speaking ad-hoc networking technologies do not impose any restriction on the technologies deployed within the network, backbone WMNs will likely benefit from disparate heterogeneous wireless and wired access technologies to efficiently provide services to end-users. 3. IP autoconf requirements posed by the Backbone WMN scenario This section describes in more detail the requirements that the Backbone WMN scenario poses on the design of an IP autoconfiguration solution aimed at working in this kind of environment. This analysis is based on the main characteristics that define Backbone WMNs (described in Section 2). To perform this analysis, we make use of the evaluation considerations defined in [4], by assessing each evaluation consideration from the point of view of a solution targeting Backbone Wireless Mesh Network scenarios. 3.1. Scenarios This characteristic concerns the multi-hop network environment. In this context, two possible scenarios of ad-hoc networks are identified in [1]: Standalone MANETs and Connected MANETs. WMNs are Bernardos, et al. Expires May 6, 2009 [Page 6] Internet-Draft AUTOCONF Mesh Requirements November 2008 expected to be connected to the Internet. This means that the IP autoconfiguration solution will have to deal with the issue of getting global IPv6 addresses that allow nodes to get Internet connectivity. Since Backbone WMNs are expected to be always connected to the infrastructure (i.e. the Internet), an IP autoconfiguration solution aimed at working in Backbone WMNs must provide support for Connected MANETs, whereas support for standalone operation is not required. This is a critical difference from the general ad-hoc/MANET scenario -- in which supporting Standalone MANETs is usually required -- and might have a noticeable impact on the solution space for this kind of environments, since solutions may assume that the infrastructure is always reachable and benefit from that fact (e.g., availability of servers). 3.2. Mobility type This characteristic concerns the nodes behaviour in multi-hop network. In fact, nodes' mobility type depends on the application type. Backbone WMNs are composed of wireless mesh routers, characterised by presenting very low (if any) mobility. Typically, in a Backbone WMN scenario, mesh routers are located at fixed positions (being these locations also very stable over the time), and therefore a low topology dynamism is expected. Most topological changes would be originated by the degradation of radio link conditions and by the switching on/off of wireless mesh routers. 3.3. Address uniqueness The Address Uniqueness characteristic concerns two points: i) Duplicate Address Avoidance, and ii) Non-unique Address Detection. Duplicate Address Avoidance is a mandatory characteristic in any autoconfiguration mechanism. It consists in making all autoconfiguration mechanisms' functionalities configure addresses only after their uniqueness have been verified. On the other hand, Non-unique Address Detection is the process used to detect address collisions -- that may appear during the normal life-time of the network -- and resolve them. A solution designed aimed at working in these scenarios must ensure that the IP addresses configured in the mesh routers are unique (therefore, support for Duplicated Address Avoidance is mandatory). Although it is not very likely that several nodes would turn using duplicated addresses during the normal operation of a Backbone WMN, it is interesting to provide also Non-unique Address Detection, in Bernardos, et al. Expires May 6, 2009 [Page 7] Internet-Draft AUTOCONF Mesh Requirements November 2008 order to avoid potential disruptions in the IP connectivity due to address conflicts. 3.4. Merging support This characteristic basically deals with the ability of an autoconfiguration mechanism to detect network merging and the functionalities that are required in order to avoid IP address conflicts and connectivity problems in case several networks merge. To illustrate an example of merging in Backbone WMNs, we might think of a community network formed by several neighbours of a 10-stories building. In this scenario, depending on the availability of the neighbours' routers, it is possible that several isolated WMNs networks are formed (e.g. a WMN cloud formed by routers on 1st to 5th floor and another one formed by routers on 7th to 10th floor). These isolated networks may merge if a router on the 6th floor is switched on. However, given the connected nature of Backbone WMNs (every mesh router needs to be provided with a globally unique IPv6 address), it is very unlikely that after such a merging, an IPv6 address collision happens. Therefore, an IP autoconfiguration solution aimed at working in Backbone WMNs does not require to provide support for handling network merging. 3.5. Partitioning support An IP autoconfiguration mechanism may present the ability to detect network partitioning and provide functionalities to avoid connectivity problems in such a case. The same reasoning used in the previous section also applies here. Only temporal, sporadic disconnections -- caused by some kind of trouble -- are expected in backbone networks. Therefore, an IP autoconfiguration solution aimed at working in Backbone WMNs is not expected to provide support for handling network partitioning. 3.6. Prefix delegation support An IP autoconfiguration mechanism may support the delegation of IPv6 prefixes to the connected nodes, so they can use these prefixes for further delegation to "traditional" or legacy attached nodes. Since Backbone WMNs are expected to provide legacy clients with IP and Internet connectivity, supporting the delegation of IPv6 prefixes to the mesh routers is a very interesting feature (although it is not the only possibility to assist legacy clients gaining IP Bernardos, et al. Expires May 6, 2009 [Page 8] Internet-Draft AUTOCONF Mesh Requirements November 2008 connectivity). Therefore, an IP autoconfiguration solution aimed at working in Backbone WMNs should support IPv6 prefix delegation. 3.7. Protocol overhead This characteristic concerns the additional signalling required by the IP autoconfiguration mechanism. Such signalling is considered as protocol overhead that might have a significant performance impact. This characteristic might have an impact on the convergence time, on the scalability of the autoconfiguration mechanism and on the power consumption. Backbone WMNs are expected not to be power nor resource constrained and they will not typically suffer from very low and poor radio link interconnections. Therefore, although the protocol overhead should always be minimised as much as possible, this is not a very critical issue in this kind of environments. 3.8. Robustness One important characteristic/property of an autoconf mechanism is its robustness. Given the particular multi-hop characteristics of ad-hoc scenarios, it might be important to analyse the underlying assumptions that an IP autoconfiguration mechanism might make. IP autoconfiguration mechanism aimed at working in Backbone WMNs should be robust in terms of resiliency to sporadic transmission problems (wireless links are unreliable). However, typical radio and stability conditions in Backbone WMNs will be not much worse than in a single-hop networking scenario, and therefore the use of additional dedicated mechanisms is not expected. 3.9. Convergence time Another important characteristic, that can be related to the robustness as well, is the convergence time of an autoconf solution. Depending on the scenario and/or the application, we may define the convergence time as the time required by a single node to get a usable (and unique) IPv6 address or as the time required by the whole network to have all its nodes configured with correct addresses. Given the level of stability of Backbone WMNs (topological changes are mainly caused by radio link degradation and wireless mesh switching on/off), convergence time is not a critical issue. It is expected that only during bootstrapping many nodes will be configuring an IP address simultaneously, and the time that this "power-up" takes is not considered a concern. Bernardos, et al. Expires May 6, 2009 [Page 9] Internet-Draft AUTOCONF Mesh Requirements November 2008 3.10. Scalability An important issue to deal with during autoconfiguration mechanisms design is the scalability of mechanisms to different networks sizes. An autoconfiguration mechanism is not scalable, if its performance degrades significantly when the network size increases. The MANET Architecture I-D [2] defines as Small a MANET composed of 2-30 peer MANET routers, Moderate a MANET composed of 30-100 peer MANET routers, Large a MANET composed of 100-1000 peer MANET routers, and Very Large those MANETs larger than 1000 peer MANET routers. Given the application scenarios that usually involve Backbone WMNs, an IP autoconfiguration solution aimed at working in these kind of environments should scale in such a way that it works in Large (hundreds to thousands nodes) Backbone WMNs deployments. 3.11. Address space utilisation This characteristic basically analyses how an autoconf solution makes use of the available address space. An IP autoconfiguration solution aimed at working in WMNs should make an efficient use of the IP address space available, given its connected nature and its potentially large size. 3.12. Distributed/Centralised approach There are different possible approaches that an IP autoconfiguration mechanism might follow to provide IP addresses to all the nodes of an ad-hoc network, from the deployment a centralised server that is in charge of the IP address configuration (e.g., DHCPv6) to sharing the IP address configuration task among all the participant nodes. The Backbone WMN scenario does not impose itself any constraint/ requirement on the particular type of solution to be used (centralised or distributed). However, given the connected nature and reasonable topological stability of Backbone WMNs, the use of centralised solutions is not as discouraged as in a general MANET environments. Therefore, approaches that make use of centralised servers located at the infrastructure can be considered. 3.13. Trust and security Security is a critical issue in any communication protocol. In the design of autoconfiguration mechanisms, attacks in ad hoc multi-hop environments should be considered. Given the typical application scenarios of WMNs, it might be even possible to assume the existence of trust relationships between each communicating pair of nodes that Bernardos, et al. Expires May 6, 2009 [Page 10] Internet-Draft AUTOCONF Mesh Requirements November 2008 are involved in the autoconfiguration process. An IP autoconfiguration solution aimed at working in Backbone WMNs should be provided with a level of security similar to today's fixed Internet. Because of the connected nature and taking into account the potential application scenarios that are being considered today for Backbone WMNs, it could be assumed the existence of trust relationships (or mechanisms enabling its establishment on-demand) between the participant nodes. 3.14. Integration with standard IPv6 nodes Certain autoconf mechanisms may allow/be compatible to support IPv6 nodes to get addresses using standard mechanisms defined in IPv6, while others may be totally incompatible with today's IPv6 nodes, therefore preventing these nodes to inter-operate with these autoconf solutions, unless the IPv6 nodes are properly modified to support them. Enabling the connectivity of legacy clients is a key characteristic of a Backbone WMN, Therefore an IP autoconfiguration solution aimed at working in this kind of environments must be compatible with standard IPv6 nodes, allowing them to attach and get IP connectivity through the WMN. 3.15. Gateway involvement Internet gateways (also known as MANET Border Routers) are responsible of providing nodes with the connectivity to the fixed infrastructure. Additionally, these gateways might also have a role/ involvement in the IP address configuration procedure (e.g., in some solutions, the gateway might only be responsible of forwarding packets to the infrastructure, while in other solutions it may also be involved in the task of providing nodes with addresses/prefixes). An IP autoconfiguration solution aimed at working in Backbone WMNs does not impose any particular role to the Internet Gateways in the IP address configuration process. Again, given the always-connected nature of this kind of WMNs, a particular solution may become simpler when collocating the gateway and IP address functionalities on the same entities. 3.16. Routing protocol dependency An IP autoconfiguration mechanism may depend on a particular routing protocol in order to work properly or may need some specific information from the routing protocol stack, whereas another autoconfiguration mechanism may be completely independent of the Bernardos, et al. Expires May 6, 2009 [Page 11] Internet-Draft AUTOCONF Mesh Requirements November 2008 routing protocol used in the network. Potentially, it is preferred to keep the IP autoconfiguration solution as much independent as possible from the MANET routing protocol used in the network. However, since Backbone WMN scenarios usually involve relatively closed user groups (e.g., community networks) or domains administered by a single entity (e.g., backhaul operator networks), the MANET routing protocol dependency is not an issue as critical as in generic ad-hoc scenarios. 3.17. Multiple interfaces support One characteristic that might have an impact on the IP autoconfiguration mechanism is the number of interfaces that should be provided with IP addresses. Although from a conceptual point of view solutions should not be affected by this, if we look at the solution space, this could have an impact on the IP autoconfiguration mechanism. Wireless mesh routers will typically have more than one single physical interface. Therefore, an IP autoconfiguration solution aimed at working in a backbone WMN should support the operation on multiple-interfaced mesh routers, being able to provide IP addresses to more than one single interface. 4. Security Considerations None. 5. IANA Considerations This document has no actions for IANA. 6. Acknowledgements Patrick Stupar provided text for an earlier version of this draft. This work has been partially supported by the Spanish Government under the POSEIDON (TSI2006-12507-C03-01) project. This work has also been partially supported by the EU through the ICT FP7 European Project CARMEN (INFSO-ICT-214994). Apart from this, the European Commission has no responsibility for the content of this Internet-Draft. The information in this document is provided as is and no guarantee or warranty is given that the information is fit for Bernardos, et al. Expires May 6, 2009 [Page 12] Internet-Draft AUTOCONF Mesh Requirements November 2008 any particular purpose. The user thereof uses the information at its sole risk and liability. 7. References 7.1. Normative References [1] Baccelli, E., Mase, K., Ruffino, S., and S. Singh, "Address Autoconfiguration for MANET: Terminology and Problem Statement", draft-ietf-autoconf-statement-04 (work in progress), February 2008. [2] Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc Network Architecture", draft-ietf-autoconf-manetarch-07 (work in progress), November 2007. 7.2. Informative References [3] Akyildiz, I., Wang, X., and W. Wang, "Wireless mesh networks: a survey", Computer Networks, vol. 47, no. 4, March 2005, pp. 445- 487 , 2005. [4] Moustafa, H., Bernardos, C., and M. Calderon, "Evaluation Considerations for IP Autoconfiguration Mechanisms in MANETs", draft-bernardos-autoconf-evaluation-considerations-03 (work in progress), November 2008. Appendix A. Change Log Changes from -00 to -01: o New release to keep the document alive. o Update of some references. Authors' Addresses Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es Bernardos, et al. Expires May 6, 2009 [Page 13] Internet-Draft AUTOCONF Mesh Requirements November 2008 Maria Calderon Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 8780 Email: maria@it.uc3m.es Ignacio Soto Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 5974 Email: isoto@it.uc3m.es Bernardos, et al. Expires May 6, 2009 [Page 14] Internet-Draft AUTOCONF Mesh Requirements November 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. Bernardos, et al. Expires May 6, 2009 [Page 15]