idnits 2.17.00 (12 Aug 2021) /tmp/idnits49269/draft-bernardos-autoconf-backbone-mesh-reqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 660. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 666. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2, 2008) is 4941 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MANET Autoconfiguration (AUTOCONF) C. Bernardos 3 Internet-Draft M. Calderon 4 Intended status: Informational I. Soto 5 Expires: May 6, 2009 UC3M 6 November 2, 2008 8 Requirements for IP Autoconfiguration Mechanisms in Backbone Wireless 9 Mesh Network scenarios 10 draft-bernardos-autoconf-backbone-mesh-reqs-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 6, 2009. 37 Abstract 39 This Internet Draft presents the multi-hop Backbone Wireless Mesh 40 Network scenario, summarising its basic characteristics and 41 describing the requirements and desired properties of an IP 42 Autoconfiguration mechanism aimed at being used in this kind of 43 networks. 45 Once that the AUTOCONF WG has almost finalised the documents that 46 describe the general architecture of MANETs and the IP 47 autoconfiguration problem statement in MANETs, the WG is expected to 48 start working on solutions. This document describes an ad-hoc 49 scenario that is getting a lot of attention from both 50 telecommunication operators and end-users: Backbone/infrastructure 51 Wireless Mesh Networking. This document identifies and explains the 52 requirements posed by this particular scenario to an IP 53 autoconfiguration mechanism. The goal is to help the AUTOCONF WG 54 identify the requirements that need to be taken into account when 55 designing IP autoconfiguration solution(s) suitable for this Wireless 56 Mesh environment. 58 Table of Contents 60 1. Introduction and motivation . . . . . . . . . . . . . . . . . 3 61 2. The Wireless Mesh networking scenario . . . . . . . . . . . . 3 62 3. IP autoconf requirements posed by the Backbone WMN scenario . 6 63 3.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Mobility type . . . . . . . . . . . . . . . . . . . . . . 7 65 3.3. Address uniqueness . . . . . . . . . . . . . . . . . . . . 7 66 3.4. Merging support . . . . . . . . . . . . . . . . . . . . . 8 67 3.5. Partitioning support . . . . . . . . . . . . . . . . . . . 8 68 3.6. Prefix delegation support . . . . . . . . . . . . . . . . 8 69 3.7. Protocol overhead . . . . . . . . . . . . . . . . . . . . 9 70 3.8. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.9. Convergence time . . . . . . . . . . . . . . . . . . . . . 9 72 3.10. Scalability . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.11. Address space utilisation . . . . . . . . . . . . . . . . 10 74 3.12. Distributed/Centralised approach . . . . . . . . . . . . . 10 75 3.13. Trust and security . . . . . . . . . . . . . . . . . . . . 10 76 3.14. Integration with standard IPv6 nodes . . . . . . . . . . . 11 77 3.15. Gateway involvement . . . . . . . . . . . . . . . . . . . 11 78 3.16. Routing protocol dependency . . . . . . . . . . . . . . . 11 79 3.17. Multiple interfaces support . . . . . . . . . . . . . . . 12 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 88 Intellectual Property and Copyright Statements . . . . . . . . . . 15 90 1. Introduction and motivation 92 The multi-hop nature of ad-hoc networks and its lack of a single 93 multicast-capable link for signalling prevents current IP address 94 autoconfiguration related protocol specifications (such as RFCs 2461, 95 2462, etc.) to be used as-is in ad-hoc networks. Some limitations of 96 these existing solutions are stated in [1] and they mainly concern: 97 the lack of multi-hop support, the lack of dynamic topology support, 98 the lack of network merging support and the lack of network 99 partitioning support. 101 The main purpose of the AUTOCONF WG is to standardise mechanisms to 102 be used by ad-hoc nodes for configuring unique local and/or globally 103 routable IPv6 addresses. The ad-hoc nodes under consideration are, 104 once configured, expected to be able to support multi-hop 105 communication by running MANET routing protocols as developed by the 106 IETF MANET WG. 108 Once that the AUTOCONF WG has almost finalised the documents that 109 describe the general architecture of MANETs [2] and the IP 110 autoconfiguration problem statement in MANETS [1], the WG is 111 chartered to start working on the standardisation of IP 112 autoconfiguration solutions. In this context, this document reviews 113 and describes a particular ad-hoc scenario that is getting a lot of 114 attention from both telecommunication operators and end-users: 115 Backbone/Infrastructure Wireless Mesh Networking. This document 116 identifies and explains the requirements posed by this particular 117 scenario to an IP autoconfiguration mechanism. The goal is to help 118 the AUTOCONF WG identify the requirements that need to be taken into 119 account when designing IP autoconfiguration solution(s) suitable for 120 the Wireless Mesh environment. 122 2. The Wireless Mesh networking scenario 124 Wireless networks are evolving to provide better services with lower 125 deployment costs. Ad-hoc networking as shown itself as one promising 126 technology in many applicability scenarios. The ad-hoc term is 127 highly overloaded nowadays and it usually comprises many different 128 network architectures, with disparate characteristics and 129 requirements. As an example, today we can find several instances of 130 ad-hoc networks: Mobile Ad-hoc Networks (MANETs), sensor networks, 131 Vehicular Ad-hoc Networks (VANETs), Wireless Mesh Networks (WMNs), 132 etc. All of them share their multi-hop, unmanaged and decentralised 133 nature, but also present very important differences. In this 134 document, we pay attention to Wireless Mesh Networks, as one 135 particular type of ad-hoc network that today is gaining momentum, 136 mainly due to the interest from both end-users and telcos. 138 In a Wireless Mesh Network [3], nodes are comprised of mesh routers 139 and mesh clients. Each node operates not only as a host, but also as 140 a router, forwarding packets on behalf of other nodes that are not 141 within direct wireless reachability of their destinations. WMNs are 142 dynamically self-organised and self-configured, with their nodes 143 automatically setting-up and maintaining mesh connectivity among 144 themselves. WMNs are considered to be a very promising technology 145 for a broad number of applications, such as community and 146 neighbourhood networks, building automation, emergency networks, 147 broadband home networking, carrier backhaul solutions, etc. 149 A number of variants of WMNs exist today, basically differing from 150 the intended end-use and the mobility of their nodes. As an example, 151 a well known classification of WMNs distinguishes among the following 152 types: 153 o Infrastructure/Backbone WMNs. Basically, this type of WMN is 154 composed of wireless mesh routers providing an infrastructure for 155 clients to connect to them. One of the possible applications of 156 this type of WMNs is to serve as a carrier backhaul for a 157 telecommunications operator, providing backbone for conventional 158 clients. While mesh-based solutions can be used both in temporary 159 and permanent scenarios, their usage is particularly advantageous 160 in situations where the network infrastructure is only needed for 161 short time periods. In these situations, the deployment of a 162 backhaul infrastructure based on current solutions requires a very 163 high investment which is usually uneconomical for such a short 164 duration; a mesh-based solution provides a much more cost 165 effective way of satisfying this short-term demand. A good 166 example of such a temporary scenario that can greatly benefit from 167 a mesh-based solution is the London 2012 Olympic Games. Besides 168 this kind of "planned wireless mesh deployment", we may consider 169 also an additional and very interesting example of application of 170 backbone WMN: the Neighbourhood/Community Networks, which can be 171 considered as an example of "unplanned wireless mesh deployment". 172 o Client WMNs. This type of WMNs provides peer-to-peer networks 173 among client devices. Therefore, in this architecture, the client 174 nodes are the ones constituting the actual network to perform 175 routing, configuration and service provisioning to customers. 176 This type of networks does not require mesh routers. Compared to 177 the previous type of WMNs, this imposes more requirements on the 178 end-users, since they must perform additional functions such as 179 routing and self-configuration. Examples of client WMNs include: 180 meeting networks, file sharing networks, entertainment networks 181 for gaming, etc. 182 o Hybrid WMNs. This architecture is actually the combination of the 183 previous two ones (Infrastructure and Client WMNs), in which mesh 184 clients can access the network both through mesh routers and 185 directly through other clients. 187 ------------------------- 188 -( )- 189 -( )- 190 ( ) 191 ( Internet ) 192 ( ) 193 -( )- 194 -( )- 195 -+----------+----------+- 196 / | \ 197 / | \ 198 / | \ 199 ----+---- ----+---- ----+---- 200 | WMN R +.-.-.-+ WMN R +.-.-.-+ WMN R | 201 ----+---- ---+-+--- ----+---- 202 . . . . 203 \ / \ / 204 . . . . 205 \ / \ / 206 --+---+-- --+---+-- 207 | WMN R +.-.-.-.+ WMN R | 208 -+----+-- ----+---- 209 * * * 210 * * * 211 * * * 212 * * ----+----- 213 * * | Client | 214 ----+----- -----+---- ---------- 215 ! Client | | Client | 216 ---------- ---------- 217 ----------------------------- 218 | WMN R: Mesh Router | 219 | Client: IPv6 Client | 220 ----------------------------- 222 Figure 1: Backbone WMN scenario 224 Since Infrastructure/Backbone WMNs are a very relevant and common 225 type of WMN -- which is receiving a lot of attention today --, that 226 differs from general MANET scenarios, this document will focus on 227 this type of WMN (Figure 1). 229 While a Backbone WMN share many common characteristics with classical 230 ad-hoc networks, we may highlight the following key differences: 231 o Low/null node mobility. Mesh routers will usually present minimal 232 (if any) mobility. Changes in the network topology will be mainly 233 caused by variations in the wireless radio link characteristics 234 and by WMN routers being switched on/off (that is, joining/leaving 235 the network). 236 o Infrastructure-connected. While we can differentiate between 237 standalone and connected when considering generic ad-hoc networks, 238 WMNs are expected to be always connected to the Internet. 239 Backbone WMNs (or parts of them) could be temporarily 240 disconnected, but only because some kind of trouble, and therefore 241 the standalone mode of operation does not need to be necessarily 242 considered. 243 o Multiple gateway nature. Since Backbone WMNs are characterised 244 for its Internet connectivity, they will likely require to benefit 245 from deploying multiple Border Routers/Internet gateways to 246 provide attached nodes with Internet connectivity. 247 o Compatibility with existing wireless networks, Internet protocols 248 and legacy nodes. Backbone WMNs are expected to provide 249 connectivity to non ad-hoc/legacy clients. Therefore, existing 250 IPv6 nodes should be able to attach to a Backbone WMN (using an 251 unmodified wireless/wired access protocol) and gain Internet 252 connectivity through it. 253 o Scalability. Although it is difficult to predict and it will be 254 mostly dependant on the particular deployment, Backbone WMNs may 255 be composed of up to hundreds (even thousands) of devices and, 256 therefore, special attention should be paid to the scalability of 257 the protocols designed to work in Backbone WMNs. 258 o Low power-consumption constraints. Mesh routers usually will not 259 have any strong constraint on power consumption. 260 o Multiple types of access. While generally speaking ad-hoc 261 networking technologies do not impose any restriction on the 262 technologies deployed within the network, backbone WMNs will 263 likely benefit from disparate heterogeneous wireless and wired 264 access technologies to efficiently provide services to end-users. 266 3. IP autoconf requirements posed by the Backbone WMN scenario 268 This section describes in more detail the requirements that the 269 Backbone WMN scenario poses on the design of an IP autoconfiguration 270 solution aimed at working in this kind of environment. This analysis 271 is based on the main characteristics that define Backbone WMNs 272 (described in Section 2). To perform this analysis, we make use of 273 the evaluation considerations defined in [4], by assessing each 274 evaluation consideration from the point of view of a solution 275 targeting Backbone Wireless Mesh Network scenarios. 277 3.1. Scenarios 279 This characteristic concerns the multi-hop network environment. In 280 this context, two possible scenarios of ad-hoc networks are 281 identified in [1]: Standalone MANETs and Connected MANETs. WMNs are 282 expected to be connected to the Internet. This means that the IP 283 autoconfiguration solution will have to deal with the issue of 284 getting global IPv6 addresses that allow nodes to get Internet 285 connectivity. 287 Since Backbone WMNs are expected to be always connected to the 288 infrastructure (i.e. the Internet), an IP autoconfiguration solution 289 aimed at working in Backbone WMNs must provide support for Connected 290 MANETs, whereas support for standalone operation is not required. 291 This is a critical difference from the general ad-hoc/MANET scenario 292 -- in which supporting Standalone MANETs is usually required -- and 293 might have a noticeable impact on the solution space for this kind of 294 environments, since solutions may assume that the infrastructure is 295 always reachable and benefit from that fact (e.g., availability of 296 servers). 298 3.2. Mobility type 300 This characteristic concerns the nodes behaviour in multi-hop 301 network. In fact, nodes' mobility type depends on the application 302 type. 304 Backbone WMNs are composed of wireless mesh routers, characterised by 305 presenting very low (if any) mobility. Typically, in a Backbone WMN 306 scenario, mesh routers are located at fixed positions (being these 307 locations also very stable over the time), and therefore a low 308 topology dynamism is expected. Most topological changes would be 309 originated by the degradation of radio link conditions and by the 310 switching on/off of wireless mesh routers. 312 3.3. Address uniqueness 314 The Address Uniqueness characteristic concerns two points: i) 315 Duplicate Address Avoidance, and ii) Non-unique Address Detection. 316 Duplicate Address Avoidance is a mandatory characteristic in any 317 autoconfiguration mechanism. It consists in making all 318 autoconfiguration mechanisms' functionalities configure addresses 319 only after their uniqueness have been verified. On the other hand, 320 Non-unique Address Detection is the process used to detect address 321 collisions -- that may appear during the normal life-time of the 322 network -- and resolve them. 324 A solution designed aimed at working in these scenarios must ensure 325 that the IP addresses configured in the mesh routers are unique 326 (therefore, support for Duplicated Address Avoidance is mandatory). 327 Although it is not very likely that several nodes would turn using 328 duplicated addresses during the normal operation of a Backbone WMN, 329 it is interesting to provide also Non-unique Address Detection, in 330 order to avoid potential disruptions in the IP connectivity due to 331 address conflicts. 333 3.4. Merging support 335 This characteristic basically deals with the ability of an 336 autoconfiguration mechanism to detect network merging and the 337 functionalities that are required in order to avoid IP address 338 conflicts and connectivity problems in case several networks merge. 339 To illustrate an example of merging in Backbone WMNs, we might think 340 of a community network formed by several neighbours of a 10-stories 341 building. In this scenario, depending on the availability of the 342 neighbours' routers, it is possible that several isolated WMNs 343 networks are formed (e.g. a WMN cloud formed by routers on 1st to 5th 344 floor and another one formed by routers on 7th to 10th floor). These 345 isolated networks may merge if a router on the 6th floor is switched 346 on. However, given the connected nature of Backbone WMNs (every mesh 347 router needs to be provided with a globally unique IPv6 address), it 348 is very unlikely that after such a merging, an IPv6 address collision 349 happens. 351 Therefore, an IP autoconfiguration solution aimed at working in 352 Backbone WMNs does not require to provide support for handling 353 network merging. 355 3.5. Partitioning support 357 An IP autoconfiguration mechanism may present the ability to detect 358 network partitioning and provide functionalities to avoid 359 connectivity problems in such a case. The same reasoning used in the 360 previous section also applies here. Only temporal, sporadic 361 disconnections -- caused by some kind of trouble -- are expected in 362 backbone networks. 364 Therefore, an IP autoconfiguration solution aimed at working in 365 Backbone WMNs is not expected to provide support for handling network 366 partitioning. 368 3.6. Prefix delegation support 370 An IP autoconfiguration mechanism may support the delegation of IPv6 371 prefixes to the connected nodes, so they can use these prefixes for 372 further delegation to "traditional" or legacy attached nodes. 374 Since Backbone WMNs are expected to provide legacy clients with IP 375 and Internet connectivity, supporting the delegation of IPv6 prefixes 376 to the mesh routers is a very interesting feature (although it is not 377 the only possibility to assist legacy clients gaining IP 378 connectivity). Therefore, an IP autoconfiguration solution aimed at 379 working in Backbone WMNs should support IPv6 prefix delegation. 381 3.7. Protocol overhead 383 This characteristic concerns the additional signalling required by 384 the IP autoconfiguration mechanism. Such signalling is considered as 385 protocol overhead that might have a significant performance impact. 386 This characteristic might have an impact on the convergence time, on 387 the scalability of the autoconfiguration mechanism and on the power 388 consumption. 390 Backbone WMNs are expected not to be power nor resource constrained 391 and they will not typically suffer from very low and poor radio link 392 interconnections. Therefore, although the protocol overhead should 393 always be minimised as much as possible, this is not a very critical 394 issue in this kind of environments. 396 3.8. Robustness 398 One important characteristic/property of an autoconf mechanism is its 399 robustness. Given the particular multi-hop characteristics of ad-hoc 400 scenarios, it might be important to analyse the underlying 401 assumptions that an IP autoconfiguration mechanism might make. 403 IP autoconfiguration mechanism aimed at working in Backbone WMNs 404 should be robust in terms of resiliency to sporadic transmission 405 problems (wireless links are unreliable). However, typical radio and 406 stability conditions in Backbone WMNs will be not much worse than in 407 a single-hop networking scenario, and therefore the use of additional 408 dedicated mechanisms is not expected. 410 3.9. Convergence time 412 Another important characteristic, that can be related to the 413 robustness as well, is the convergence time of an autoconf solution. 414 Depending on the scenario and/or the application, we may define the 415 convergence time as the time required by a single node to get a 416 usable (and unique) IPv6 address or as the time required by the whole 417 network to have all its nodes configured with correct addresses. 419 Given the level of stability of Backbone WMNs (topological changes 420 are mainly caused by radio link degradation and wireless mesh 421 switching on/off), convergence time is not a critical issue. It is 422 expected that only during bootstrapping many nodes will be 423 configuring an IP address simultaneously, and the time that this 424 "power-up" takes is not considered a concern. 426 3.10. Scalability 428 An important issue to deal with during autoconfiguration mechanisms 429 design is the scalability of mechanisms to different networks sizes. 430 An autoconfiguration mechanism is not scalable, if its performance 431 degrades significantly when the network size increases. The MANET 432 Architecture I-D [2] defines as Small a MANET composed of 2-30 peer 433 MANET routers, Moderate a MANET composed of 30-100 peer MANET 434 routers, Large a MANET composed of 100-1000 peer MANET routers, and 435 Very Large those MANETs larger than 1000 peer MANET routers. 437 Given the application scenarios that usually involve Backbone WMNs, 438 an IP autoconfiguration solution aimed at working in these kind of 439 environments should scale in such a way that it works in Large 440 (hundreds to thousands nodes) Backbone WMNs deployments. 442 3.11. Address space utilisation 444 This characteristic basically analyses how an autoconf solution makes 445 use of the available address space. 447 An IP autoconfiguration solution aimed at working in WMNs should make 448 an efficient use of the IP address space available, given its 449 connected nature and its potentially large size. 451 3.12. Distributed/Centralised approach 453 There are different possible approaches that an IP autoconfiguration 454 mechanism might follow to provide IP addresses to all the nodes of an 455 ad-hoc network, from the deployment a centralised server that is in 456 charge of the IP address configuration (e.g., DHCPv6) to sharing the 457 IP address configuration task among all the participant nodes. 459 The Backbone WMN scenario does not impose itself any constraint/ 460 requirement on the particular type of solution to be used 461 (centralised or distributed). However, given the connected nature 462 and reasonable topological stability of Backbone WMNs, the use of 463 centralised solutions is not as discouraged as in a general MANET 464 environments. Therefore, approaches that make use of centralised 465 servers located at the infrastructure can be considered. 467 3.13. Trust and security 469 Security is a critical issue in any communication protocol. In the 470 design of autoconfiguration mechanisms, attacks in ad hoc multi-hop 471 environments should be considered. Given the typical application 472 scenarios of WMNs, it might be even possible to assume the existence 473 of trust relationships between each communicating pair of nodes that 474 are involved in the autoconfiguration process. 476 An IP autoconfiguration solution aimed at working in Backbone WMNs 477 should be provided with a level of security similar to today's fixed 478 Internet. Because of the connected nature and taking into account 479 the potential application scenarios that are being considered today 480 for Backbone WMNs, it could be assumed the existence of trust 481 relationships (or mechanisms enabling its establishment on-demand) 482 between the participant nodes. 484 3.14. Integration with standard IPv6 nodes 486 Certain autoconf mechanisms may allow/be compatible to support IPv6 487 nodes to get addresses using standard mechanisms defined in IPv6, 488 while others may be totally incompatible with today's IPv6 nodes, 489 therefore preventing these nodes to inter-operate with these autoconf 490 solutions, unless the IPv6 nodes are properly modified to support 491 them. 493 Enabling the connectivity of legacy clients is a key characteristic 494 of a Backbone WMN, Therefore an IP autoconfiguration solution aimed 495 at working in this kind of environments must be compatible with 496 standard IPv6 nodes, allowing them to attach and get IP connectivity 497 through the WMN. 499 3.15. Gateway involvement 501 Internet gateways (also known as MANET Border Routers) are 502 responsible of providing nodes with the connectivity to the fixed 503 infrastructure. Additionally, these gateways might also have a role/ 504 involvement in the IP address configuration procedure (e.g., in some 505 solutions, the gateway might only be responsible of forwarding 506 packets to the infrastructure, while in other solutions it may also 507 be involved in the task of providing nodes with addresses/prefixes). 509 An IP autoconfiguration solution aimed at working in Backbone WMNs 510 does not impose any particular role to the Internet Gateways in the 511 IP address configuration process. Again, given the always-connected 512 nature of this kind of WMNs, a particular solution may become simpler 513 when collocating the gateway and IP address functionalities on the 514 same entities. 516 3.16. Routing protocol dependency 518 An IP autoconfiguration mechanism may depend on a particular routing 519 protocol in order to work properly or may need some specific 520 information from the routing protocol stack, whereas another 521 autoconfiguration mechanism may be completely independent of the 522 routing protocol used in the network. 524 Potentially, it is preferred to keep the IP autoconfiguration 525 solution as much independent as possible from the MANET routing 526 protocol used in the network. However, since Backbone WMN scenarios 527 usually involve relatively closed user groups (e.g., community 528 networks) or domains administered by a single entity (e.g., backhaul 529 operator networks), the MANET routing protocol dependency is not an 530 issue as critical as in generic ad-hoc scenarios. 532 3.17. Multiple interfaces support 534 One characteristic that might have an impact on the IP 535 autoconfiguration mechanism is the number of interfaces that should 536 be provided with IP addresses. Although from a conceptual point of 537 view solutions should not be affected by this, if we look at the 538 solution space, this could have an impact on the IP autoconfiguration 539 mechanism. 541 Wireless mesh routers will typically have more than one single 542 physical interface. Therefore, an IP autoconfiguration solution 543 aimed at working in a backbone WMN should support the operation on 544 multiple-interfaced mesh routers, being able to provide IP addresses 545 to more than one single interface. 547 4. Security Considerations 549 None. 551 5. IANA Considerations 553 This document has no actions for IANA. 555 6. Acknowledgements 557 Patrick Stupar provided text for an earlier version of this draft. 559 This work has been partially supported by the Spanish Government 560 under the POSEIDON (TSI2006-12507-C03-01) project. 562 This work has also been partially supported by the EU through the ICT 563 FP7 European Project CARMEN (INFSO-ICT-214994). Apart from this, the 564 European Commission has no responsibility for the content of this 565 Internet-Draft. The information in this document is provided as is 566 and no guarantee or warranty is given that the information is fit for 567 any particular purpose. The user thereof uses the information at its 568 sole risk and liability. 570 7. References 572 7.1. Normative References 574 [1] Baccelli, E., Mase, K., Ruffino, S., and S. Singh, "Address 575 Autoconfiguration for MANET: Terminology and Problem Statement", 576 draft-ietf-autoconf-statement-04 (work in progress), 577 February 2008. 579 [2] Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc Network 580 Architecture", draft-ietf-autoconf-manetarch-07 (work in 581 progress), November 2007. 583 7.2. Informative References 585 [3] Akyildiz, I., Wang, X., and W. Wang, "Wireless mesh networks: a 586 survey", Computer Networks, vol. 47, no. 4, March 2005, pp. 445- 587 487 , 2005. 589 [4] Moustafa, H., Bernardos, C., and M. Calderon, "Evaluation 590 Considerations for IP Autoconfiguration Mechanisms in MANETs", 591 draft-bernardos-autoconf-evaluation-considerations-03 (work in 592 progress), November 2008. 594 Appendix A. Change Log 596 Changes from -00 to -01: 597 o New release to keep the document alive. 598 o Update of some references. 600 Authors' Addresses 602 Carlos J. Bernardos 603 Universidad Carlos III de Madrid 604 Av. Universidad, 30 605 Leganes, Madrid 28911 606 Spain 608 Phone: +34 91624 6236 609 Email: cjbc@it.uc3m.es 610 Maria Calderon 611 Universidad Carlos III de Madrid 612 Av. Universidad, 30 613 Leganes, Madrid 28911 614 Spain 616 Phone: +34 91624 8780 617 Email: maria@it.uc3m.es 619 Ignacio Soto 620 Universidad Carlos III de Madrid 621 Av. Universidad, 30 622 Leganes, Madrid 28911 623 Spain 625 Phone: +34 91624 5974 626 Email: isoto@it.uc3m.es 628 Full Copyright Statement 630 Copyright (C) The IETF Trust (2008). 632 This document is subject to the rights, licenses and restrictions 633 contained in BCP 78, and except as set forth therein, the authors 634 retain all their rights. 636 This document and the information contained herein are provided on an 637 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 638 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 639 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 640 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 641 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 642 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 644 Intellectual Property 646 The IETF takes no position regarding the validity or scope of any 647 Intellectual Property Rights or other rights that might be claimed to 648 pertain to the implementation or use of the technology described in 649 this document or the extent to which any license under such rights 650 might or might not be available; nor does it represent that it has 651 made any independent effort to identify any such rights. Information 652 on the procedures with respect to rights in RFC documents can be 653 found in BCP 78 and BCP 79. 655 Copies of IPR disclosures made to the IETF Secretariat and any 656 assurances of licenses to be made available, or the result of an 657 attempt made to obtain a general license or permission for the use of 658 such proprietary rights by implementers or users of this 659 specification can be obtained from the IETF on-line IPR repository at 660 http://www.ietf.org/ipr. 662 The IETF invites any interested party to bring to its attention any 663 copyrights, patents or patent applications, or other proprietary 664 rights that may cover technology that may be required to implement 665 this standard. Please address the information to the IETF at 666 ietf-ipr@ietf.org.