idnits 2.17.1 draft-bernardos-autoconf-addressing-model-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors Copyright Line does not match the current year -- The document date (October 26, 2009) is 5295 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-04) exists of draft-iab-ip-model-evolution-01 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AUTOCONF Working Group C. Bernardos 3 Internet-Draft UC3M 4 Intended status: Informational R. in 't Velt 5 Expires: April 29, 2010 TNO 6 October 26, 2009 8 Addressing Model for Router Interfaces in Ad Hoc Networks 9 draft-bernardos-autoconf-addressing-model-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 29, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document describes a practical IP addressing model for 48 interfaces that take part in router-to-router communications in ad 49 hoc networks. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [RFC2119]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Addressing model . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. IPv4/IPv6 practical addressing model . . . . . . . . . . . 5 64 3.3. DAD considerations . . . . . . . . . . . . . . . . . . . . 7 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 In order to communicate among themselves, ad hoc routers [RFC2501] 76 need to configure their network interface(s) with addresses that are 77 valid within an ad hoc network. Ad hoc routers may also need to 78 configure globally routable addresses, in order to communicate with 79 devices on the Internet. From the IP layer perspective, an ad hoc 80 network presents itself as a L3 multi-hop network formed over a 81 collection of links. 83 This document describes a practical addressing model for ad hoc 84 networks. It is required that a such model does not cause problems 85 for ad hoc-unaware parts of the system, such as standard applications 86 running on an ad hoc router or regular Internet nodes attached to the 87 ad hoc routers. 89 2. Terminology 91 Readers are expected to be familiar with all the terms defined in the 92 RFC 2501 [RFC2501]. In addition the document makes use of the 93 following definitions: 95 Wireless Link 97 According to [I-D.iab-ip-model-evolution], a "link" in the IP 98 service model refers to the topological area within which a packet 99 with an IPv4 TTL or IPv6 Hop Limit of 1 can be delivered. That 100 is, where no IP-layer forwarding (which entails a TTL/Hop Limit 101 decrement) occurs between two nodes. A "wireless link" can be 102 defined similarly, with the topological area in this case given by 103 the radio-range coverage of the wireless technology used. Due to 104 the nature of the wireless medium, links are intermittent, and 105 potentially short-lived. Node movement exacerbates these 106 characteristics. 108 MANET interface 110 Any interface over which a MANET protocol is run. 112 MANET domain 114 A MANET domain is delimited by a set of MANET routers that run a 115 common MANET routing protocol and corresponds to its routing 116 domain. 118 Attached MANET (domain) 119 A MANET domain attached to an infrastructure based network (e.g., 120 the Internet). The MANET interfaces of routers of an attached 121 MANET should be configured with unique global IP addresses, if 122 these addresses are somehow exposed beyond the MANET domain. By 123 infrastructure network, we refer to any existing network which 124 presents a certain hierarchical organisation (e.g., different 125 subnets) and that is delegated a certain set of IP addresses/ 126 prefixes. 128 Non-overlapping prefix 130 Two IP prefixes p::/l_p and q::/l_q are non-overlapping if and 131 only if there is no IP address p::a/l_p configured from p::/l_p 132 that also belongs to q::/l_q, and the other way around. For 133 example, 2001:DB8:1:1::/64 and 2001:DB8:1:2::/64 are non- 134 overlapping prefixes, while 2001:DB8:1::/48 and 2001:DB8:1:2::/64 135 are not. 137 3. Addressing model 139 This section describes a practical IPv4/IPv6 addressing model for ad 140 hoc networks. We first define the scope of the addressing model, 141 then propose how to practically configure IP on MANET interfaces. 142 Finally, we provide some considerations on address uniqueness. 144 3.1. Scope 146 This document describes an addressing model for MANET interfaces. 147 Regular (non-MANET) interfaces are not in the scope of the present 148 document, as they are expected to be configured using standard 149 mechanisms (such as SLAAC [RFC4862] or DHCP [RFC2131], [RFC3315]). 150 Note, that MANET routers may need to acquire IP address prefixes to 151 facilitate the configuration of IP addresses on nodes reachable via 152 non-MANET interfaces. How to do this is a topic that is also outside 153 the scope of this document. 155 This document does not place restrictions on the use of IP addresses 156 configured on MANET interfaces. We assume that these IP addresses 157 are used by MANET routing protocols. We also assume that, once MANET 158 routing protocols have started to populate the Forwarding Information 159 Bases (FIB) of routers with routing entries, these IP addresses will 160 play a role in the forwarding of user data packets. In particular, 161 it is assumed that these addresses will be found as next-hop 162 addresses in the routing tables of MANET routers. The forwarding of 163 user data in many cases includes the resolution of the link-layer 164 address of the interface to which the next-hop IP address is bound. 165 Furthermore, it cannot be ruled out that the IP addresses configured 166 on MANET interfaces will be used as source or destination addresses 167 by end-user applications in cases where such applications reside on 168 MANET routers. An architecture in which applications are separated 169 by one hop from MANET interfaces is conceptually elegant, but may not 170 always be practical. 172 This document considers MANET domains for the purposes of IP 173 configuration. Therefore, when we use the term "MANET" throughout 174 this document, we are referring to a MANET domain. For example, 175 MANET local uniqueness refer to uniqueness within the MANET domain. 177 Globally unique IP addresses MUST be provided for routers of attached 178 MANETs for those cases where these addresses are visible outside the 179 MANET domain, while only uniqueness within the MANET domain is 180 required for non-attached MANETs. 182 This document does not rule out that IP addresses might be configured 183 by non-autoconf mechanisms (e.g., manually) on MANET interfaces. 185 3.2. IPv4/IPv6 practical addressing model 187 This section describes the basic principles for IP addressing for 188 MANET interfaces, in as much an IP version agnostic manner as 189 possible. 191 MANET interfaces of attached MANETs SHOULD be configured with global 192 IPv6 addresses if these addresses are somehow exposed outside the 193 MANET domain. For non-attached MANETs, ULAs or global addresses 194 SHOULD be used. 196 Since the topology of a mobile ad hoc network is expected to be 197 frequently changing, MANET interfaces MUST be configured with unique/ 198 non-overlapping prefixes. This principle does not assume any prefix 199 length. The use of /32 (in the IPv4 case) or /128 (in the IPv6 case) 200 prefix lengths can be an effective way to ensure that prefixes are 201 non-overlapping. However, it would be needlessly restrictive to 202 mandate the use of only these prefix lengths. Due to its larger 203 address space, it is much easier to generate addresses for IPv6 that 204 are unique than is the case for IPv4. This is equally true for 205 prefixes with non-maximum lengths. 207 MANET interfaces MUST also be configured with IPv6 Link-local 208 addresses (as required by RFC 4861 [RFC4861] and RFC 4291 [RFC4291]). 209 Two main concerns may arise when considering the use of IPv6 Link- 210 local addresses: 212 o Address uniqueness: the event of having two duplicate addresses in 213 the same link has proved to be very low (EUI64 derived interface 214 identifiers very rarely collide, since MAC addresses are expected 215 to be globally unique), and even some mechanisms have been 216 proposed to reduce the collision probability [paper.DAD]. 217 Therefore, in most scenarios it is safe to assume that the 218 probability of having two or more duplicated link-local addresses 219 in a MANET is negiglible. For those scenarios, in which this 220 cannot be safely assumed, we refer to the DAD considerations of 221 Section 3.3. 223 o Reachability: connectivity among neighbours in wireless links may 224 be intermittent and/or short-lived. Therefore, the use of link- 225 local addresses may lead to reachability issues, since two nodes 226 that were in direct coverage range at one moment, might not be 227 anymore shortly after. These problems might also arise in wired 228 networks (nodes going up/down), but it is not the common case. 230 Designers of MANET routing protocols (and other protocols) should be 231 aware of these concerns and assess their impact, in order to make an 232 informed decision whether to make use of link-local addresses or not. 234 Fluctuating reachability as discussed above is also of concern to the 235 data forwarding process in ad hoc networks. This is especially true, 236 if existing mechanisms for neighbour discovery and address resolution 237 are to be applied. In order to mitigate these problems, several 238 solutions may be used, such as (but not limited to): decrease some of 239 the ND default timer values (specified in RFC 4861 [RFC4861]), such 240 as REACHABLE_TIME, RETRANS_TIMER, DELAY_FIRST_PROBE_TIME, 241 MIN_RANDOM_FACTOR, MAX_RANDOM_FACTOR; implement a stronger 242 interaction between the MANET routing protocols and the ND process, 243 so the MANET routing protocol helps to keep updated the ND tables. 244 Finally, if none of these solutions (or alternative ones) may be 245 implemented, processes running on the MANET routers that need to be 246 isolated from this problem can decide not to use link-local addresses 247 for their local communications. Since IPv4 lacks any standardised 248 unreachability detection mechanism, these considerations about 249 reachability only concern IPv6. 251 Configuration and use of IPv4 link-locals on MANET interfaces are not 252 forbidden. However, while in IPv6, an interface may be 253 simultaneously configured with a link-local address and with unicast 254 (global or local) addresses, this is not recommended in IPv4 255 [RFC3927]. 257 When forwarding user data packets from one MANET router to the next, 258 along the path from source to destination, standard mechanisms for 259 layer-2 address resolution of next-hop IP addresses, such as ND or 260 ARP, may be used. In this context, it should be noted that the 261 presence of IPv6 link-local addresses on MANET interfaces may lead to 262 their use, e.g. as source address in a neigbor solicitation. As 263 mentioned before, the exchange of MANET routing protocols packets is 264 a potential alternative source of link-layer address information. 266 3.3. DAD considerations 268 This document assumes that DAD is disabled by default for the IP 269 addresses configured on MANET interfaces (this is allowed in RFC 4862 270 [RFC4862]. For the case of link-local addresses, we assume the 271 collision probability is negiglible, and that it therefore is safe to 272 avoid the overhead of an active DAD process (which would need to be 273 modified to be run in a MANET domain wide fashion). For the case of 274 the non-overlapping prefixes, we do not specify how their uniqueness 275 is ensured (this is out-of-scope of this document and falls in the 276 solution space). 278 However, this document does not forbid the use of any DAD mechanism, 279 if it is required in some certain scenarios. From the point of view 280 of MANETs, it seems appropriate to consider as well the use of 281 passive DAD approaches (such as [paper.PACMAN], 282 [paper.PACMAN_assessment]). 284 4. IANA Considerations 286 This document makes no request of IANA. 288 5. Security Considerations 290 This document does currently not describe any security 291 considerations. 293 6. Acknowledgements 295 Some of the ideas included in this draft have been proposed in the 296 AUTOCONF ML by several people. Thanks for all the AUTOCONF WG 297 participants for the fruitful discussions over these years. 299 The authors would like to thank Thomas Clausen and Teco Boot for 300 their comments and discussion on this document. 302 The research of Carlos J. Bernardos leading to these results has 303 received funding from the European Community's Seventh Framework 304 Programme (FP7/2007-2013) under grant agreement n. 214994 (CARMEN 305 project) and also from the Ministry of Science and Innovation of 306 Spain, under the QUARTET project (TIN2009-13992-C02-01). 308 7. References 310 7.1. Normative References 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, March 1997. 315 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 316 RFC 2131, March 1997. 318 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 319 and M. Carney, "Dynamic Host Configuration Protocol for 320 IPv6 (DHCPv6)", RFC 3315, July 2003. 322 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 323 Configuration of IPv4 Link-Local Addresses", RFC 3927, 324 May 2005. 326 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 327 Architecture", RFC 4291, February 2006. 329 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 330 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 331 September 2007. 333 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 334 Address Autoconfiguration", RFC 4862, September 2007. 336 7.2. Informative References 338 [I-D.iab-ip-model-evolution] 339 Thaler, D., "Evolution of the IP Model", 340 draft-iab-ip-model-evolution-01 (work in progress), 341 November 2008. 343 [RFC2501] Corson, M. and J. Macker, "Mobile Ad hoc Networking 344 (MANET): Routing Protocol Performance Issues and 345 Evaluation Considerations", RFC 2501, January 1999. 347 [paper.DAD] 348 Bagnulo, M., Soto, I., Garcia-Martinez, A., and A. 349 Azcorra, "Avoiding DAD for Improving Real-Time 350 Communication in MIPv6 Environments", Joint International 351 Workshop on Interactive Distributed Multimedia Systems/ 352 Protocols for Multimedia Systems IDMS-PROMS 2002, Coimbra 353 (Portugal). Lecture Notes in Computer Science 2515, pps 354 73-79, Ed. Springer-Verlag, 2002. , November 2002. 356 [paper.PACMAN] 357 Weniger, K., "PACMAN: passive autoconfiguration for mobile 358 ad hoc networks", IEEE Journal on Selected Areas in 359 Communications 23 (3) , 2005. 361 [paper.PACMAN_assessment] 362 Bernardos, C., Calderon, M., Soto, I., Solana, A., and K. 363 Weniger, "Building an IP-based Community Wireless Mesh 364 Network: Assessment of PACMAN as an IP Address 365 Autoconfiguration Protocol", Computer Networks, accepted 366 for publication , 2009. 368 Authors' Addresses 370 Carlos J. Bernardos 371 Universidad Carlos III de Madrid 372 Av. Universidad, 30 373 Leganes, Madrid 28911 374 Spain 376 Phone: +34 91624 6236 377 Email: cjbc@it.uc3m.es 378 URI: http://www.it.uc3m.es/cjbc/ 380 Ronald in 't Velt 381 TNO Information and Communication Technology 382 Brassersplein 2 383 Delft 2600 GB 384 The Netherlands 386 Phone: +31 15 2857306 387 Email: Ronald.intVelt@tno.nl