idnits 2.17.1 draft-ietf-autoconf-adhoc-addr-model-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (March 22, 2010) is 5149 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Autoconf E. Baccelli, Ed. 3 Internet-Draft INRIA 4 Intended status: Informational M. Townsley, Ed. 5 Expires: September 23, 2010 Cisco Systems 6 March 22, 2010 8 IP Addressing Model in Ad Hoc Networks 9 draft-ietf-autoconf-adhoc-addr-model-03 11 Abstract 13 This document describes a model for configuring IP addresses and 14 subnet prefixes on the interfaces of routers which connect to links 15 with undetermined connectivity properties. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 23, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 4 60 4. IP Subnet Prefix Configuration . . . . . . . . . . . . . . . . 4 61 5. IP Address Configuration . . . . . . . . . . . . . . . . . . . 4 62 6. Addressing Model . . . . . . . . . . . . . . . . . . . . . . . 5 63 6.1. IPv6 Model . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.2. IPv4 Model . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 The appropriate configuration of IP addresses and subnet masks for 76 router network interfaces is generally a prerequisite to the correct 77 functioning of routing protocols. Consideration of various items, 78 including underlying link capabilities and connectivity, geographical 79 topology, available address blocks, assumed traffic patterns 80 etc., are used when determining the appropriate network topology and 81 the associated IP interface configuration. 83 When the capabilities and connectivity of the links that connect 84 routers are well-known and stable, logical network topology design 85 and corresponding IP interface configuration are straightforward. 86 Absent any assumption about link-level connectivity, however, there 87 is no canonical method for determining a given IP interface 88 configuration. 90 Link-level connectivity is generally qualified as undetermined when 91 it is unplanned and/or time-varying in character. Ad hoc networks 92 are typical examples of networks with undetermined link-level 93 connectivity. Routing protocols for ad hoc networks have as purpose 94 to detect and maintain paths across the network, even when faced with 95 links with undetermined connectivity, assuming that routers' 96 interfaces are configured with IP addresses. This document thus 97 proposes a model for configuration of IP addresses and subnet 98 prefixes on router interfaces to links with undetermined connectivity 99 properties, to allow routing protocols and data packet forwarding to 100 function. 102 Note that routers may ultimately need additional IP prefixes for the 103 diverse applications that could run directly on the routers 104 themselves, or for assignment to attached hosts or networks. For 105 IPv6, these addresses may be global [RFC3587], Unique-Local [RFC4193] 106 or Link-Local [RFC4291]. For IPv4, the addresses may be global 107 (i.e., public) or private [RFC1918]. In general, global scope is 108 desired over local scope, though it is understood that this may not 109 always be achievable via automatic configuration mechanisms. In this 110 document however, automatic configuration of the prefixes used for 111 general applications is considered as a problem that is separable 112 from that of automatic configuration of addresses and prefixes 113 necessary for routing protocols to function. This document thus 114 focuses on the latter: the type of IP address and subnet mask 115 configuration necessary for routing protocols and data packet 116 forwarding to function. 118 2. Terminology 120 This document uses the vocabulary and the concepts defined in 121 [RFC1918] and [RFC4632] for IPv4, as well as [RFC4291] for IPv6. 123 3. Applicability Statement 125 This model gives guidance about the configuration of IP addresses and 126 the IP subnet prefixes on router's IP interfaces which connect to 127 links with undetermined connectivity properties. 129 When more specific assumptions can be made regarding the connectivity 130 between interfaces, or the (persistent) reachability of some 131 addresses, these should be considered when configuring subnet 132 prefixes. 134 4. IP Subnet Prefix Configuration 136 If the link to which an interface connects enables no assumptions of 137 connectivity to other interfaces, the only addresses which can be 138 assumed "on link", are the address(es) of that interface itself. 139 Note that while link-local addresses are assumed to be "on link", the 140 utility of link-local addresses is limited as described in Section 6. 142 Subnet prefix configuration on such interfaces must thus not make any 143 promises in terms of direct (one hop) IP connectivity to IP addresses 144 other than that of the interface itself. This suggests the following 145 principle: 147 o no on-link subnet prefix should be configured on such an 148 interface. 150 Note that if layer 2 communication is enabled between a pair of 151 interfaces, IP packet exchange is also enabled, even if IP subnet 152 configuration is absent or different on each of these interfaces. 154 Also note that if, on the contrary, assumptions can be made regarding 155 the connectivity between interfaces, or regarding the persistent 156 reachability of some addresses, these should be considered when 157 configuring IP subnet prefixes, and the corresponding interface(s) 158 may in such case be configured with an on-link subnet prefix. 160 5. IP Address Configuration 162 Routing protocols running on a router may exhibit different 163 requirements for uniqueness of interface addresses; some have no such 164 requirements, others have requirements ranging from local uniqueness 165 only, to uniqueness within, at least, the routing domain (as defined 166 in [RFC1136]). 168 Configuring an IP address that is unique within the routing domain 169 satisfies the less stringent uniqueness requirements of local 170 uniqueness, while also enabling protocols which have the most 171 stringent requirements of uniqueness within the routing domain. This 172 suggests the following principle: 174 o an IP address assigned to an interface that connects to a link 175 with undetermined connectivity properties should be unique, at 176 least within the routing domain. 178 6. Addressing Model 180 Section 4 and Section 5 describe principles for IP address and subnet 181 prefix configuration on an interface of a router, when that interface 182 connects to a link with undetermined connectivity properties. The 183 following describes guidelines that follow from these principles, 184 respectively for IPv6 and IPv4. 186 Note that the guidelines provided in this document slightly differ 187 for IPv6 and IPv4, as IPv6 offers possibilities that IPv4 does not 188 (i.e., the possibility to simply not configure any on-link subnet 189 prefix on an IPv6 interface), which provide a "cleaner" model. 191 6.1. IPv6 Model 193 For IPv6, the principles described in Section 4 and Section 5 suggest 194 the following rules: 196 o An IP address configured on this interface should be unique, at 197 least within the routing domain, and 199 o No on-link subnet prefix is configured on this interface. 201 Note that while an IPv6 link-local address is assigned to each 202 interface as per [RFC4291], in general link-local addresses are of 203 limited utility on links with undetermined connectivity, as 204 connectivity to neighbors may be constantly changing. The known 205 limitations are: 207 o There is no mechanism to ensure that IPv6 link-local addresses are 208 unique across multiple links, hence they cannot be used to 209 reliably identify routers (it is often desirable to identify a 210 router with an IP address). 212 o Routers cannot forward any packets with link-local source or 213 destination addresses to other links (as per [RFC4291]) while most 214 of the time, routers need to be able to forward packets to/from 215 different links. 217 Therefore, autoconfiguration solutions should be encouraged to 218 primarily focus on configuring IP addresses that are not IPv6 link- 219 local. 221 6.2. IPv4 Model 223 For IPv4, the principles described in Section 4 and Section 5 suggest 224 rules similar to those mentioned for IPv6 in Section 6.1, that are: 226 o An IP address configured on this interface should be unique, at 227 least within the routing domain, and 229 o Any subnet prefix configured on this interface should be 32 bits 230 long. 232 Note that the use of IPv4 link-local addresses [RFC3927] in this 233 context should be discouraged for most applications, as the 234 limitations outlined in Section 6.1 for IPv6 link-local addresses 235 also concern IPv4 link-local addresses. These limitations are 236 further exacerbated by the smaller pool of IPv4 link-local addresses 237 to choose from and thus increased reliance on Duplicate Address 238 Detection (DAD). 240 7. IANA Considerations 242 This document has no actions for IANA. 244 8. Security Considerations 246 This document thus focuses on the IP address and subnet mask 247 configuration necessary for routing protocols and data packet 248 forwarding to function. [RFC4593] describes generic threats to 249 routing protocols, whose applicability is not altered by the presence 250 of interfaces with undetermined connectivity properties. As such, 251 the addressing model described in this document does not introduce 252 new security threats. 254 However, the possible lack of pre-established infrastructure or 255 authority, as enabled by the use of interfaces with undetermined 256 connectivity properties, may render some of the attacks described in 257 [RFC4593] easier to undertake. In particular, detection of 258 malevolent misconfiguration may be more difficult to detect and to 259 locate. 261 9. References 263 9.1. Normative References 265 [RFC1136] Hares, S. and D. Katz, "Administrative Domains and Routing 266 Domains: A Model for Routing in the Internet", RFC 1136, 267 December 1989. 269 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 270 Architecture", RFC 4291, 2006. 272 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 273 Configuration of IPv4 Link-Local Addresses", RFC 3927, 274 2005. 276 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 277 and E. Lear, "Address Allocation for Private Internets", 278 RFC 1918, 1996. 280 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 281 Addresses", RFC 4193, 2005. 283 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 284 Unicast Address Format", RFC 3587, 2003. 286 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 287 (CIDR): The Internet Address Assignment and Aggregation 288 Plan", RFC 4632, 2006. 290 9.2. Informative References 292 [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to 293 Routing Protocols", RFC 4593, 2006. 295 Appendix A. Contributors 297 This document reflects discussions and contributions from several 298 individuals including (in alphabetical order): Teco Boot, Ulrich 299 Herberg, Thomas Narten, Erik Nordmark, Charles Perkins, Zach Shelby 300 and Dave Thaler. 302 Authors' Addresses 304 Emmanuel Baccelli 305 INRIA 307 Email: Emmanuel.Baccelli@inria.fr 308 URI: http://www.emmanuelbaccelli.org/ 310 Mark Townsley 311 Cisco Systems 313 Email: townsley@cisco.com