idnits 2.17.1 draft-ietf-autoconf-adhoc-addr-model-00.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.i 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 == Line 157 has weird spacing: '...m these princ...' -- The document date (October 19, 2009) is 5302 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: April 22, 2010 Cisco Systems 6 October 19, 2009 8 IP Addressing Model in Ad Hoc Networks 9 draft-ietf-autoconf-adhoc-addr-model-00 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 22, 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 model for configuring IP addresses and 48 subnet prefixes on the interfaces of routers which connect to links 49 with undetermined connectivity properties. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 3 56 4. IP Subnet Prefix Configuration . . . . . . . . . . . . . . . . 3 57 5. IP Address Configuration . . . . . . . . . . . . . . . . . . . 4 58 6. Addressing Model . . . . . . . . . . . . . . . . . . . . . . . 4 59 6.1. IPv4 Model . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6.2. IPv6 Model . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 64 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 6 65 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 The appropriate configuration of IP addresses and subnet masks for 71 router network interfaces is generally a prerequisite to the correct 72 functioning of routing protocols. Consideration of various items, 73 including underlying link capabilities and connectivity, geographical 74 topology, available address blocks, assumed traffic patterns, 75 etc. are used when determining the appropriate network topology and 76 the associated IP interface configuration. 78 When the capabilities and connectivity of the links that connect 79 routers are well-known and rather stable, logical network topology 80 design and corresponding IP interface configuration are rather 81 straightforward. Absent any assumption about link-level 82 connectivity, there is no canonical method for determining a given IP 83 interface configuration. 85 Ad hoc networks are typical examples of networks with undetermined 86 link-level connectivity. MANET routing protocols have as purpose to 87 detect and maintain network connectivity, assuming that routers' 88 interfaces are configured with IP addresses. This document thus 89 proposes a model for configuration of IP addresses and subnet 90 prefixes on router interfaces to links with undetermined connectivity 91 properties. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in RFC 98 2119 [RFC2119]. 100 3. Applicability Statement 102 The configuration proposed by this model is applicable to any 103 router's IP interface. It specifies IP addresses and IP subnet 104 prefixes to be configured on network interfaces. 106 When more specific assumptions can be made regarding the connectivity 107 between interfaces, these SHOULD be considered when configuring 108 subnet prefixes. 110 4. IP Subnet Prefix Configuration 112 If the link to which an interface connects enables no assumptions of 113 connectivity to other interfaces, the only addresses which can be 114 assumed "on link", are the address(es) of that interface itself. 115 Note that while link-local addresses are assumed to be "on link", the 116 utility of link-local addresses is limited as described in Section 6. 118 Subnet prefix configuration on such interfaces must thus not make any 119 promises in terms of direct (one hop) IP connectivity to IP addresses 120 other than that of the interface itself. This suggests the following 121 principle: 123 o no two such interfaces in the network should be configured with 124 the same subnet prefix. 126 If L2 communication is enabled between a pair of interfaces, IP 127 packet exchange is enabled regardless of the IP subnet configuration 128 on each of these interfaces. 130 If on the contrary, assumptions can be made regarding connectivity 131 between interfaces, these SHOULD be considered when configuring IP 132 subnet prefixes, and the corresponding interfaces MAY be configured 133 with the same subnet prefix. 135 5. IP Address Configuration 137 Routing protocols running on a router may exhibit different 138 requirements for uniqueness of interface addresses; some have no such 139 requirements, others have requirements ranging from local uniqueness 140 only, to uniqueness within, at least, the routing domain. 142 Configuring an IP address that is unique within the routing domain 143 satisfies the less stringent uniqueness requirements of local 144 uniqueness, while also enabling protocols which have the most 145 stringent requirements of uniqueness within the routing domain. This 146 suggests the following principle: 148 o an IP address assigned to an interface that connects to a link 149 with undetermined connectivity properties should be unique, at 150 least within the routing domain. 152 6. Addressing Model 154 Section 4 and Section 5 describe principles for IP address and subnet 155 prefix configuration on an interface of a router, when that interface 156 connects to a link with undetermined connectivity properties. The 157 following describes guidelines that follow from these principles, 158 respectively for IPv4 and IPv6. 160 6.1. IPv4 Model 162 For IPv4, the principles described in Section 4 and Section 5 suggest 163 the following rules: 165 o An IP address configured on this interface should be unique, at 166 least within the routing domain; and 168 o Any subnet prefix configured on this interface should be of length 169 /32. 171 Note that the use of IPv4 link-local addresses [RFC3927] in this 172 context should be discouraged for most applications, as the 173 limitations outlined in Section 6.2 for IPv6 link-local addresses 174 also concern IPv4 link-local addresses. These limitations are 175 further exacerbated by the smaller pool of IPv4 link-local addresses 176 to choose from and thus increased reliance on DAD. 178 6.2. IPv6 Model 180 For IPv6, the principles described in Section 4 and Section 5 suggest 181 the following rules: 183 o An IP address configured on this interface should be unique, at 184 least within the routing domain, and 186 o A subnet prefix configured on this interface should be of length 187 /128. 189 Note that while an IPv6 link-local address is assigned to each 190 interface as per [RFC4291], in general link-local addresses are of 191 limited utility on links with undetermined connectivity, as 192 connnectivity to neighbors may be constantly changing. The known 193 limitations are: 195 o Even if tested for local uniqueness at one moment using 196 Duplicate Address Detection [RFC4862], a duplicate link-local 197 address might appear as a neighbor the next moment, without it 198 being an explicit event that would trigger DAD again. Such 199 duplication would thus go undetected. 201 o There is no mechanism to ensure that IPv6 link-local addresses are 202 unique across multiple links, hence they can not be used to 203 reliably identify routers. 205 o Routers cannot forward any packets with link-local source or 206 destination addresses to other links (as per [RFC4291]) while most 207 of the time, routers need to be able to forward packets to/from 208 different links. 210 Therefore MANET autoconfiguration solutions should be encouraged to 211 primarily focus on configuring IP addresses that are not IPv6 link- 212 local. 214 7. IANA Considerations 216 This document has no actions for IANA. 218 8. Security Considerations 220 This document does currently not describe any security 221 considerations. 223 9. Normative References 225 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 226 Requirement Levels", BCP 14, RFC 2119, March 1997. 228 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 229 Architecture", RFC 4291, 2006. 231 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 232 Configuration of IPv4 Link-Local Addresses", RFC 3927, 233 2005. 235 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 236 Address Autoconfiguration", RFC 4862, 2007. 238 Appendix A. Open Issues 240 The following issues were extensively discussed among the design 241 team, without reaching a conclusion. 243 MANET Link Model - no satisfying MANET link model was formulated to 244 date. Lacking a better definition so far, a MANET link is: a link 245 with undetermined connectivity properties. 247 Global Uniqueness Requirements - it remains to be determined whether 248 or not the scope of AUTOCONF includes applications other than 249 routing protocols running on the router, which may communicate 250 with outside the routing domain and which for that, require 251 globally unique addresses. 253 Appendix B. Contributors 255 This document reflects discussions and contributions from several 256 individuals including (in alphabetical order): 258 Teco Boot: teco@inf-net.nl 260 Ulrich Herberg: ulrich@herberg.name 262 Thomas Narten: narten@us.ibm.com 264 Charles Perkins: charliep@computer.org 266 Erik Nordmark: erik.nordmark@sun.com 268 Authors' Addresses 270 Emmanuel Baccelli 271 INRIA 273 Email: Emmanuel.Baccelli@inria.fr 274 URI: http://www.emmanuelbaccelli.org/ 276 Mark Townsley 277 Cisco Systems 279 Email: townsley@cisco.com