idnits 2.17.1 draft-chelius-adhoc-ipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 577 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 (September 2002) is 7887 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1826 (ref. 'AUTH') (Obsoleted by RFC 2402) -- No information found for draft-ietf-manet-autoconf - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AUTOCONF' == Outdated reference: A later version (-03) exists of draft-montenegro-sucv-02 -- Possible downref: Normative reference to a draft: ref. 'SUCV' == Outdated reference: A later version (-10) exists of draft-ietf-ipngwg-addr-arch-v3-08 == Outdated reference: A later version (-05) exists of draft-wakikawa-manet-globalv6-01 -- Possible downref: Normative reference to a draft: ref. 'CONNECT' Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft G. Chelius 3 Document: draft-chelius-adhoc-ipv6-00.txt E. Fleury 4 Expires: March 2003 Ares, Inria 5 September 2002 7 IPv6 Addressing Architecture Support for mobile ad hoc networks 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of rfc-2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 The concept of node identifier, in practical terms an IP address, is 33 crucial in ad hoc networks. Its use allows the setup of IP routing 34 for ad hoc connectivity and the identification of several wireless 35 devices as part of a unique ad hoc node. In this document, a new 36 addressable object is defined: the ad hoc connector. It virtualizes 37 several ad hoc network interfaces into a single addressable object. 38 To locally address ad hoc connectors, a third IPv6 local-use unicast 39 address (adhoc-local address) and the correlated use of the subnet 40 multicast scope are defined. 42 Table of Contents 44 Status of this Memo................................................1 45 Abstract...........................................................1 46 1. Introduction....................................................3 47 2. Terminology.....................................................3 48 3. Ad hoc connector................................................4 49 3.1 Ad hoc connector management....................................4 50 3.2 Interface binding..............................................5 52 Chelius, Fleury Expires March 2003 1 53 4. Addressing an ad hoc connector..................................5 54 4.1 Local addressing...............................................5 55 4.2 Global addressing..............................................6 56 5. Addressing multiple ad hoc connectors...........................6 57 5.1 Predefined ad hoc multicast addresses..........................6 58 5.2 Multicast and ad hoc sub-networks..............................7 59 5.3 Multicast membership...........................................8 60 6. Duplicated ad hoc address detection.............................8 61 7. Global Prefix Discovery.........................................8 62 8. Security Considerations.........................................8 63 9. Notes...........................................................9 64 References........................................................10 65 Author's Addresses................................................10 67 Chelius, Fleury Expires March 2003 2 68 1. Introduction 70 The notion of ad hoc network is something particular compared to 71 classical network architectures. It is a logical view that unifies 72 several physical networks in a single multigraph topology. As said 73 in [rfc2501], the concept of a "node identifier", in practical terms 74 an IP address, is crucial in ad hoc networks. Its use allows the 75 setup of IP routing for ad hoc connectivity as well as the 76 identification of several wireless devices as part of a unique ad 77 hoc node. 79 To gather several ad hoc interfaces in a single entity, the notion 80 of ad hoc connectors is introduced. The ad hoc connector is the 81 basic element of ad hoc networks. It virtualizes several network 82 interfaces into a single addressable object. A host may have several 83 ad hoc connectors and an interface may be bound to several ad hoc 84 connectors. The ad hoc connector defines a set of addresses which 85 identify indistinctly all bounded interfaces. 87 IPv6 addressing architecture proposes two local unicast addresses 88 and their equivalent multicast scope: link-local and site-local. The 89 use of link-local unicast and multicast addresses is unsuitable to 90 ad hoc networks. A link-Local unicast address refers to a single 91 interface and its validity is limited to the interface link. 92 Since an ad hoc network may be included in a larger site or spread 93 over different sites, a specific ad hoc use of site-local addresses 94 is also inappropriate. In addition, a site-local address identifies 95 a single interface whereas an ad hoc address may identify several 96 ones. 98 To locally address ad hoc connectors, we propose the definition of a 99 third IPv6 local-use unicast address: adhoc-local addresses. Their 100 validity is limited to an ad hoc network. They provide a basic 101 identification support for ad hoc nodes that can be extended by 102 other configuration mechanisms such as stateless global address 103 attribution. 105 In the IPv6 architecture scheme, an ad hoc network may be at the 106 same time, a multi-link subnet and a multi-link multi-subnet. 107 Considering the whole ad hoc network as a multi-link subnet is 108 achieved by matching a particular multicast scope, the subnet scope, 109 with the ad hoc network. To support the multi-link multi-subnet 110 vision, the notion of logical ad hoc sub-networks, also called 111 channels, is introduced. A channel is a connex set of ad hoc 112 connectors sharing a common channel value. A specific range of 113 multicast addresses is associated to each channel. It enables the 114 restriction of multicast groups to a given channel. 116 2. Terminology 118 Ad hoc connector - the basic element of an ad hoc network. It 119 virtualizes several network interfaces in a 121 Chelius, Fleury Expires March 2003 3 122 single addressable object. 124 Ad hoc identifier - a 64bits value that pseudo-uniquely identifies 125 an ad hoc connector. 127 Ad hoc channel - a non null 16bits value associated to an ad 128 hoc connector. This value indicates the ad hoc 129 sub-network the ad hoc connector is connected 130 to. 132 Ad hoc interface - a network interface bound to an ad hoc 133 connector. 135 Ad hoc host - a host with at least one ad hoc interface. 137 Ad hoc route - a network route that only transits through ad 138 hoc interfaces. 140 Ad hoc network - a maximal and connex set of ad hoc connectors. 142 Ad hoc sub-network - a maximal and connex set of ad hoc connectors 143 sharing a common channel value. 145 Ad hoc router - an ad hoc node which may route packets between 146 ad hoc network(s) and non ad hoc network(s). 148 Ad hoc sub-router - an ad hoc node which may route packets between 149 two or more ad hoc sub-networks. 151 All ad hoc nodes must be configured as IPv6 unicast and multicast 152 routers. 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 156 this document are to be interpreted as described in rfc-2119 157 [rfc2119]. 159 3. Ad hoc connector 161 As defined in [rfc2501], a MANet is the *union* of physical-layer 162 multihop topologies, i.e. a multigraph. In this multigraph, it is 163 inappropriate to use the network interface as the basic addressable 164 element; network interfaces only exist in one single physical layer 165 topology. The ad hoc connector is defined as the basic element of ad 166 hoc networks. It is a view of mind that virtualizes several network 167 interfaces into a single addressable object. 169 3.1 Ad hoc connector management 171 Chelius, Fleury Expires March 2003 4 172 In the network, an ad hoc connector is identified by a 64bits value, 173 the ad hoc identifier. Another 16bits non null value is associated 174 to the connector: its ad hoc channel value. 176 Ad hoc connectors are created and destroyed by user management. Ad 177 hoc IDs and ad hoc channel values are provided by the user at the 178 connector creation. The ad hoc channel may be changed during the ad 179 hoc connector life. A host may have several ad hoc connectors. 180 However, ad hoc connectors of a single host must have different 181 identifiers and different channel values. 183 For the ad hoc network to correctly behave, it is preferred for ad 184 hoc IDs to be unique. It is the user responsibility to ensure 185 uniqueness of its IDs. To build pseudo-unique IDs, host interface 186 MAC addresses or cryptographic mechanisms such as the one described 187 in [SUCV] may be used. 189 3.2 Interface binding 191 Network interfaces are manually bound to and unbound from ad hoc 192 connectors by user management. A network interface may be bound to 193 several ad hoc connectors and several network interfaces may be 194 bound to a same ad hoc connector. 196 4. Addressing an ad hoc connector 198 An ad hoc connector is associated to a set of IPv6 addresses which 199 identify all bounded addresses. These addresses are an adhoc-local 200 address and eventually one or more global addresses. The local 201 address ensures connectivity in the ad hoc network and the global 202 ones enable Internet connectivity. 204 4.1 Local addressing 206 To address an ad hoc connector inside an ad hoc network, we define a 207 third type of local-use unicast address: adhoc-local. The adhoc- 208 local scope is for use in a single adhoc network. It is valid in all 209 ad hoc sub-networks of the ad hoc network. Adhoc-Local addresses 210 have the following format: 212 | 10 | | | 213 | bits | 54 bits | 64 bits | 214 +----------+-------------------------+----------------------------+ 215 |1111111001| 0 | ad hoc connector ID | 216 +----------+-------------------------+----------------------------+ 218 Each ad hoc connector is associated to a single adhoc-local address 219 constructed using its identifier. 221 Chelius, Fleury Expires March 2003 5 222 Ad Hoc nodes must not forward any packet with adhoc-local source or 223 destination through a non ad hoc interface. 225 In addition to addresses given in [rfc2373], an ad hoc interface is 226 required to recognize the following addresses as identifying itself: 228 o adhoc-local addresses of all ad hoc connectors it is bounded 229 to. 231 An ad hoc interface is required to join the solicited-node multicast 232 groups associated to the following unicast addresses: 234 o adhoc-local addresses of all ad hoc connectors it is bounded 235 to. 237 4.2 Global addressing 239 Ad hoc connectors may be addressed using global addresses if global 240 prefixes are available in the ad hoc network. 242 If a given global prefix P is delivered to an ad hoc connector with 243 identifier Id, the global address constructed by concatenation of P 244 and Id is associated to the ad hoc connector 246 An ad hoc interface is required to recognize the following addresses 247 as identifying itself: 249 o all global addresses associated to all ad hoc connectors it 250 is bounded to. 252 An ad hoc interface is required to join the solicited-node multicast 253 groups associated to the following unicast addresses: 255 o all global addresses associated to all ad hoc connectors it 256 is bounded to. 258 5. Addressing multiple ad hoc connectors 260 To address multiple ad hoc connectors and to limit the scope of a 261 multicast group to an ad hoc network, we use the subnet multicast 262 scope as defined in [IPV6ADDR]. 264 5.1 Predefined ad hoc multicast addresses 266 In addition to the ones given in [IPV6ADDR], the following well- 267 known ad hoc multicast addresses are predefined: 269 "All ad hoc nodes" address: 270 FF03:0:0:0:0:0:0:1 272 Chelius, Fleury Expires March 2003 6 273 The above multicast address identifies the group of all IPv6 ad hoc 274 nodes within the ad hoc network. 276 "All ad hoc routers" address: 277 FF03:0:0:0:0:0:0:A 279 The above multicast address identifies the group of all IPv6 ad hoc 280 routers within the ad hoc network. 282 "All ad hoc sub-routers" address: 283 FF03:0:0:0:0:0:0:B 285 The above multicast address identifies the group of all IPv6 ad hoc 286 sub-routers within the ad hoc network. 288 Ad Hoc nodes must not forward any multicast packet with subnet scope 289 through a non ad hoc interface. 291 5.2 Multicast and ad hoc sub-networks 293 To address multiple ad hoc connectors inside a single ad hoc sub- 294 network and to limit the scope of a multicast group to an ad hoc 295 sub-network, we define a range of multicast addresses: 296 FF03:0:0:channel value:0:0:0:0 298 For a given channel value X, the following well-known ad hoc 299 multicast addresses are predefined: 301 Reserved Multicast Address: 302 FF03:0:0:X:0:0:0:0 304 The above multicast address is reserved and shall never be assigned 305 to any multicast group. 307 "All ad hoc nodes of a sub-network" address: 308 FF03:0:0:X:0:0:0:1 310 The above multicast address identifies the group of all IPv6 nodes 311 within the ad hoc sub-network. 313 "All ad hoc routers of a sub-network" address: 314 FF03:0:0:X:0:0:0:A 316 The above multicast address identifies the group of all IPv6 ad hoc 317 routers within the ad hoc sub-network. 319 "All ad hoc sub-routers of a sub-network" address: 320 FF03:0:0:X:0:0:0:B 322 The above multicast address identifies the group of all IPv6 ad hoc 323 sub-routers within the ad hoc sub-network. 325 Chelius, Fleury Expires March 2003 7 326 Ad Hoc nodes must not forward any multicast packet limited to an ad 327 hoc sub-network with channel value X through an interface that is 328 not connected to an ad hoc connector with channel value X. 330 5.3 Multicast membership 332 Ad hoc interfaces must join the following multicast groups: 334 o "All ad hoc nodes" 335 o "All ad hoc nodes of a sub-network" for the channel values of 336 the ad hoc connectors they are bounded to. 338 In addition, ad hoc interfaces of ad hoc routers must join the 339 following groups: 341 o "All ad hoc routers" 342 o "All ad hoc routers of a sub-network" for the channel 343 values of the ad hoc connectors they are bounded to. 345 In addition, ad hoc interfaces of ad hoc sub-routers must join the 346 following groups: 348 o "All ad hoc sub-routers" 349 o "All ad hoc sub-routers of a sub-network" for the channel 350 values of the ad hoc connectors they are bounded to. 352 6. Duplicated ad hoc address detection 354 Ad hoc specific Duplicated Address Detection (DAD) may be performed 355 once or several times, eventually periodically, on ad hoc addresses. 356 Ad hoc specific DAD is not mandatory since it is not safe. 358 It is an ad hoc node responsibility to ensure uniqueness of its ad 359 hoc addresses; either using an ad hoc specific DAD, either using 360 unique or pseudo-unique ad hoc connector identifiers. 362 Classical DAD protocols are inappropriate in the ad hoc environment. 363 Definition of an appropriate protocol is behind the scope of this 364 document. An example is given in [AUTOCONF]. 366 7. Global Prefix Discovery 368 Global prefixes may be manually or automatically delivered to ad hoc 369 connectors. Definition of an ad hoc specific Prefix Discovery 370 Protocol is behind the scope of this document. An example is given 371 in [CONNECT]. 373 8. Security Considerations 375 Chelius, Fleury Expires March 2003 8 376 IPv6 addressing documents do not have any direct impact on Internet 377 infrastructure security. Authentication of IPv6 packets is defined 378 in [AUTH]. 380 This document does not modify security issues related to ad hoc 381 networks. 383 9. Notes 385 Values of the adhoc-local unicast prefix and predefined multicast 386 addresses are given as examples and are not restrictive. Addresses 387 and prefixes must be attributed by the IANA. 389 Chelius, Fleury Expires March 2003 9 390 References 392 [AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, August 393 1995. 395 [rfc2373] Hinden, R. and Deering, S., "IP Version 6 Addressing 396 Architecture", RFC 2373, July 1998. 398 [rfc2461] Narten, T. and Nordmark, E. and Simpson, W., "Neighbor 399 Discovery for IP version 6 (IPv6)", RFC 2461, December 1998. 401 [rfc2501] Corson, S. and Macker, J., "Mobile Ad hoc Networking 402 (MANET): Routing Protocol Performance Issues and Evaluation 403 Considerations", RFC 2501, January 1999. 405 [AUTOCONF] Perkins, C. and Malinen, J. and Wakikawa, R. and 406 Belding-Royer, E. And Sun, Y., "IP Address Autoconfiguration for Ad 407 Hoc Networks", Internet draft, draft-ietf-manet-autoconf-01.txt. 409 [SUCV] Montenegro, G. and Castelluccia, C., "SUCV Identifiers and 410 Addresses", Internet draft, draft-montenegro-sucv-02.txt. 412 [IPV6ADDR] Hinden, R. and Deering, S., "IP Version 6 Addressing 413 Architecture", Internet draft, draft-ietf-ipngwg-addr-arch-v3- 414 08.txt. 416 [CONNECT] Wakikawa, R. and Malinen, J. and Perkins, C. and Nilsson, 417 A. and Tuominen, A., "Global connectivity for IPv6 Mobile Ad Hoc 418 Networks", Internet draft, draft-wakikawa-manet-globalv6-01.txt. 420 Author's Addresses 422 Guillaume Chelius 423 Ares, Inria 424 Batiment Leonard de Vinci 425 21 avenue Jean Capelle 426 69621 Villeurbanne Cedex 427 France 428 Email: gchelius@telecom.insa-lyon.fr 430 Eric Fleury 431 Ares, Inria 432 Batiment Leonard de Vinci 433 21 avenue Jean Capelle 434 69621 Villeurbanne Cedex 435 France 436 Email: Eric.Fleury@inria.fr 438 Chelius, Fleury Expires March 2003 10