idnits 2.17.00 (12 Aug 2021) /tmp/idnits2987/draft-weniger-manet-addressautoconf-ipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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 is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 118: '...eader node. This SHOULD include the nu...' RFC 2119 keyword, line 133: '... [1]. This address MAY only be used for the communication within the...' RFC 2119 keyword, line 138: '... RAs SHALL be set to two times the p...' RFC 2119 keyword, line 140: '... Router Solicitation messages MUST NOT be send as described in [2]....' RFC 2119 keyword, line 151: '...ss. Unsolicited NA messages SHALL NOT...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [RFC 2119], but that reference does not seem to mention RFC 2119 either. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC 2119' on line 84 ** Obsolete normative reference: RFC 2462 (ref. '1') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2373 (ref. '3') (Obsoleted by RFC 3513) Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad Hoc Networking Working Group K. Weniger 3 INTERNET DRAFT M. Zitterbart 4 22 February 2002 Universitaet Karlsruhe (TH) 6 IPv6 Stateless Address Autoconfiguration for 7 Hierarchical 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 RFC2026. 15 Internet Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsolete by other documents at 21 anytime. It is inappropriate to use Internet Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 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 This document describes, how the IPv6 Stateless Address 33 Autoconfiguration [1] can be applied to hierarchical mobile ad hoc 34 networks. A hierarchical address space is build up to limit the 35 protocol overhead needed for the Duplicate Address Detection (DAD) 36 and to enable route aggregation for hierarchical routing protocols. 37 Unique addresses are guaranteed, even if the network splits up and 38 merges later on. 40 Contents 42 1. Introduction............................................. 2 43 2. Terminology.............................................. 2 44 3. Limitations and Assumptions.............................. 2 45 4. Protocol Overview........................................ 3 46 5. Address Generation ...................................... 3 47 6. Duplicate Address Detection.............................. 4 48 6.3. Random Source ID..................................... 4 49 6.2. Hop Limit............................................ 4 50 6.4. Relay of DAD messages................................ 4 51 7. Leader Election.......................................... 5 52 8. Duplicate Subnet ID Detection............................ 5 53 9. Network Partitioning..................................... 5 54 10. Message Formats.......................................... 6 55 10.1 IPv6 Header.......................................... 6 56 10.2 MANET-option......................................... 7 57 11. Security Considerations.................................. 7 58 References................................................... 7 59 Author's Address............................................ 7 60 Appendix A: Estimation of Protocol Overhead.................. 8 62 1. Introduction 64 Routing protocols assume network-wide unique node identifiers. 65 Because mobile ad hoc networks are infrastructure-free, highly 66 dynamic wireless networks, central administration or manual 67 configuration of the IP stack is impractical. The Internet Protocol 68 IPv6 defines mechanisms to autoconfigure interfaces of nodes in wired 69 networks in a distributed manner. This document specifies a method, 70 how the IPv6 Stateless Address Autoconfiguration (SAA) and the 71 Neighbor Discovery Protocol (NDP) can be applied to mobile ad hoc 72 networks. The protocol overhead is limited due to a hierarchical 73 approach. The resulting hierarchical address space can be used by 74 routing protocols for route aggregation. Most notably, this approach 75 guarantees to detect all duplicate addresses within a limited time, 76 even if the network splits up and merges later on. 78 2. Terminology 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in "Key words for use in 83 RFCs to Indicate Requirement Levels" [RFC 2119]. 85 A leader node is the center of a subnet and sends Router Announcement 86 (RA) messages. The scope of a node is an area of r hops around this 87 node. Furthermore, the terminology of [1], [2] and [3] are used. 89 3. Limitations and Assumptions 91 The assignment of global routable addresses is outside the scope of 92 this document. The hierarchical addresses can only be used for 93 communication within the ad hoc network. Due to the hierarchy, the 94 address changes if a node changes the subnet. This situation can lead 95 to the interruption of TCP-sessions and has to be handled by routing 96 or mobility protocols. This is outside the scope of this document. 97 Furthermore, it is assumed that the nodes do not necessarily have any 98 kind of guaranteed unique interface identifier. This assumption is 99 especially true for networks with devices, which do not own IEEE 100 802.x MAC-addresses (even they are not guaranteed to be unique). It 101 is assumed, that an interface knows that it is in MANET operation 102 and, subsequently, when to use this modified version of IPv6 SAA. 104 4. Protocol Overview 106 First, a node generates a link-local address as described in [1]. 107 After that, the Duplicate Address Detection (DAD) is performed. The 108 node broadcasts a modified Neighbor Solicitation (NS) message [2] 109 extended by the so-called MANET-option. This message will be flooded 110 within a limited area, the so-called scope. A node, which has the 111 same address replies with a Neighbor Advertisement (NA) message. 112 Subsequently, the sender of the NS message chooses a new address and 113 repeats the process. This guarantees the uniqueness of the addresses 114 within each node's scope. 116 An hierarchy is build by periodically sending these NS messages. 117 Therefore, the MANET-option contains a weight that implies how well a 118 node qualifies to be a leader node. This SHOULD include the number of 119 neighbors, the degree of association with neighboring nodes and the 120 remaining battery power of the node. The node with the highest weight 121 within a scope becomes the leader node. This node sends Router 122 Announcement (RA) containing a randomly chosen subnet ID. All nodes 123 within the scope of the leader node construct a site-local address 124 based on the subnet ID. In order to guarantee the uniqueness of 125 subnet IDs, a Duplicate Subnet ID Detection (DSD) is performed 126 between all leader nodes. Subsequently, the site-local addresses are 127 guaranteed to be unique within the entire ad hoc network and can be 128 used for communication within the ad hoc network. 130 5. Address Generation 132 The generation of a link-local address is performed as described in 133 [1]. This address MAY only be used for the communication within the 134 scope of the node. Based on the subnet ID contained in the Router 135 Announcements (RAs) sent by the leader node, nodes construct a site- 136 local address. This address can be used for communication within the 137 entire ad hoc network. The lifetime of the prefixes contained in the 138 RAs SHALL be set to two times the period which the RAs are issued. 140 Router Solicitation messages MUST NOT be send as described in [2]. 142 6. Duplicate Address Detection 144 The DAD is only performed within the scope of a node and guarantees 145 the uniqueness of the link-local address within the scope. A node 146 performing the DAD sends a modified NS message to the all-nodes 147 multicast address [3] with the link-local address as solicitation 148 target address. This message will be flooded within a limited area, 149 the so-called scope. A node with the same address replies with a NA 150 message. Subsequently, the sender of the NS message chooses a new 151 address and repeats the process. Unsolicited NA messages SHALL NOT 152 be send. Further differences to [1] are, that addresses can already 153 be used before the DAD is completed (it is repeated anyway) and that 154 the autoconfiguration process is started even if no RAs are received. 156 6.1. Random Source ID 158 In order to distinguish NS messages of different senders, which 159 potentially have the same IP address, a Random Source ID (RS-ID) is 160 introduced. Every NS message includes a new, randomly chosen ID. This 161 ID is not changed if the message is forwarded only. First, this 162 prevents nodes from forwarding the same message more than one time. 163 Second, this allows nodes to detect address conflicts: Nodes remember 164 the last RS-IDs used for sending NS messages. If a node receives an 165 NS message with an RS-ID that it did not use recently and a target 166 address, which is equal to its own address, an address conflict is 167 detected and the node replies with an NA message. Subsequently, the 168 corresponding node chooses a new address and the conflict is 169 resolved. If the RS-ID were not be changed continuously, an address 170 conflict of two nodes with the same IP and the same RS-ID would never 171 be detectable. 173 6.2. Hop Limit 175 The hop limit field in the IPv6 header has to be set to the radius of 176 the scope. Subsequently, NDP packets with a hop limit field other 177 than 255 MUST NOT be discarded as it is specified in [2]. 179 6.3. Relay of DAD messages 181 Because all nodes within the scope of a leader node form one subnet 182 and have the same subnet ID, they must have a unique interface 183 identifier part. This can only be guaranteed, if the link-local 184 addresses are unique within a subnet, which is equal to the scope of 185 the leader node. Therefore, the leader node has to relay NS and NA 186 messages received from nodes of its subnet with a hop limit set to 187 the radius of the subnet. Before the leader node changes the hop 188 limit field, it stores its value in the so-called pre-relay hop limit 189 field of the MANET-option. Subsequently, each node knows the distance 190 to the sender, even after the modification of the hop limit field, by 191 adding the value of the pre-relay hop limit field. This is required 192 for a fair leader election, where each node only competes with the 193 nodes within its scope. The default value for this field is 0. 195 7. Leader Election 197 The algorithm for the leader election is not specified in this 198 document. It SHOULD consider the number of neighbors, the degree of 199 association with neighboring nodes and the remaining battery power of 200 the node. A weight, that has to be defined more detailed, implies how 201 well a node qualifies to be a leader node. Each node includes its 202 weight in the NS messages sent. Because these messages are sent 203 periodically, each node knows about the current weight of all nodes 204 within its scope and can decide, who the current leader node is. The 205 election results in a minimum distance between two leader nodes equal 206 to the radius of the scope. After entering the Leader State (LS), the 207 node subscribes to the all-leadernodes multicast group. Nodes, that 208 are not in LS are in Host State (HS). 210 8. Duplicate Subnet ID Detection 212 In order to guarantee unique subnet IDs, the leader nodes need to 213 perform a Duplicate Subnet ID Detection (DSD). Therefore, they send 214 NS messages to the all-nodes multicast address containing a site- 215 local address constructed by the subnet ID and an interface 216 identifier of 0 as solicitation target address. A so-called D-flag 217 indicates, that the message is used for the detection of duplicate 218 subnet IDs. Only nodes in HS forward this message. In case of an 219 conflict, an NA messages is issued and a new subnet ID is chosen. The 220 hop limit field SHOULD be set to the diameter of the ad hoc network. 221 This can be estimated by the number of leader nodes, which is equal 222 to the number of NS messages received during the DSD, and the scope 223 radius. 225 9. Network Partitioning 227 The leader node election is done periodically along with the DAD and 228 the DSD in order to maintain the hierarchical address space and to 229 cope with the network dynamics. Therefore, network partitioning and 230 merging is supported. 232 10. Message Formats 234 10.1 IPv6 Header 236 Changed fields in the IPv6 Header include the hop limit field and the 237 destination address. The solicited-node multicast address can not be 238 used, because all nodes must be able to receive and forward a 239 message. 241 0 1 2 3 242 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 |Version| Prio. | Flow Label | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Payload Length | Next Header | Hop Limit: r | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | | 249 + + 250 | | 251 + Source Address: + 252 | unspecified address | 253 + + 254 | | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 + + 258 | | 259 + Destination Address: + 260 | all-nodes multicast address | 261 + + 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 10.2 MANET-option 267 NDP messages as specified in [2] are extended by the MANET-option 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Type: 6 | Length: 2 | Random Source ID | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 |Pre-relay h.l. |D| Node Status | Weight | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Random Source ID 275 Random number to distinguish between different 276 senders of messages with the same IP address 278 Pre-relay hop limit 279 Contains the value of the hop limit field prior to 280 modification by the leader node 282 Node Status 283 Can be either Host State (0) or Leader State (1) 285 D-Flag 286 Can be either Duplicate Address Detection (0) or 287 Duplicate Subnet ID Detection (1) 289 Weight 290 Indicates, how well a node qualifies to be a leader 291 node 293 11. Security Considerations 295 TBD. 297 References 299 [1] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", 300 Request for Comments 2462, Internet Engineering Task Force, Dec. 301 1998 303 [2] T. Narten, El. Nordmark and W. Simpson , "Neighbor Discovery for 304 IP version 6", Request for Comments 2461, Internet Engineering Task 305 Force, Dec. 1998 307 [3] R. Hinden and S. Deering , "IP version 6 Addressing Architecture", 308 Request for Comments 2373, Internet Engineering Task Force, July 309 1998 311 Author's Address 313 Questions about this memo can be directed to: 315 Kilian Weniger, Martina Zitterbart 316 Zirkel 2 317 Institute of Telematics 318 Universitaet Karlsruhe (TH) 319 76128 Karlsruhe 320 Germany 321 Phone: +49 721 608 {6415,6400} 322 Fax: +49 721 388097 323 Email: {weniger,zit}@tm.uka.de 325 Appendix A: Estimation of Protocol Overhead 327 In this section, the overhead of this protocol is estimated. First, 328 we assume 1000 nodes and a period of 5 seconds for the DAD and the 329 DSD. 331 Number of nodes N_NODES 1000 332 Size of NS msg (bytes) S_NS 72 333 Network density DEN 3 334 Period of DAD (sec) PERIOD 5 336 The network density is defined as the average number of nodes within 337 the range of a node competing for access to the shared medium. We 338 assume that power control algorithms are used in dense networks. 339 Therefore, a number of 3 seems to be reasonable. 341 The number of leader nodes can be estimated giving the number of 342 nodes and the scope radius (assumed that each node is a member of 343 only one subnet). The optimal value of leader nodes is estimated by 344 minimizing the number of messages that a node has to forward (N_MSG). 346 Optimal number of leader nodes 347 N_LEADER = N_NODES^(1/2) =~ 32 349 Scope radius (hops) 350 R_SCOPE = (N_NODES/(N_LEADER*pi))^(1/2) =~ 3 352 N_MSG = pi*R_SCOPE^2 + N_LEADER =~ 64 354 This results in the following utilization of an 802.11b link (brutto 355 data rate: 11MBit/s, netto data rate: 600 kbyte/s): 357 Bandwidth of link (bytes) 358 BANDWIDTH 600 000 360 Link utilization 361 UTIL = N_MSG * S_NS * DEN / (PERIOD * BANDWIDTH) 362 = 64 * 72 * 3 / (5 * 600 000) =~ 0.0046 or 0.46 % 364 The utilization increases proportional to N_MSG, which is in turn 365 proportional to N_NODES^(1/2): 367 UTIL ~ N_MSG = N_NODES/N_NODES^(1/2) + N_NODES^(1/2) = 2*N_NODES^(1/2) 369 If the number of nodes doubles, the utilization increases only by 370 2^(1/2) =~ 1.4. Subsequently, the utilization is as follows for our 371 system and a system without a hierarchy, respectively: 373 # of nodes | with hierarchy | without hierarchy 374 ------------------------------------------------ 375 1 000 | 0.5 % | 7.2 % 376 10 000 | 1.4 % | 72.0 % 377 100 000 | 4.6 % | >100.0 %