idnits 2.17.1 draft-herberg-autoconf-yaap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The field is set to 15. The PS message MUST not contain a header field. SHOULD be set to 1. -- The document date (July 5, 2010) is 5015 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group U. Herberg 3 Internet-Draft T. Clausen 4 Intended status: Informational LIX, Ecole Polytechnique 5 Expires: January 6, 2011 July 5, 2010 7 Yet Another Autoconf Proposal (YAAP) for Mobile Ad hoc NETworks 8 draft-herberg-autoconf-yaap-00 10 Abstract 12 This document describes automatic configuration of MANET router 13 interfaces, as well as prefix delegation to MANET routers. This 14 autoconfiguration protocol is characterized by (i) adhering strictly 15 to the Internet addressing architecture, (ii) being able to configure 16 both MANET interface addresses and handle prefix delegation, and 17 (iii) being able to configure both stand-alone MANETs, as well as 18 MANETs connected to an infrastructure providing, e.g., globally 19 scoped addresses/prefixes for use within the MANET. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 6, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 58 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 5 59 5. Protocol Parameters and Constants . . . . . . . . . . . . . . 6 60 5.1. Protocol and Port Numbers . . . . . . . . . . . . . . . . 6 61 5.2. Multicast Address . . . . . . . . . . . . . . . . . . . . 6 62 5.3. IP Header . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.4. Hold Times . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.5. Time Granularity . . . . . . . . . . . . . . . . . . . . . 7 65 5.6. Message Intervals and Timeouts . . . . . . . . . . . . . . 7 66 5.7. Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. Information Sets . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.1. Neighbor Set . . . . . . . . . . . . . . . . . . . . . . . 8 69 6.2. Initiator Selector Set . . . . . . . . . . . . . . . . . . 9 70 6.3. Forwarded Set . . . . . . . . . . . . . . . . . . . . . . 9 71 7. Unique Identifiers . . . . . . . . . . . . . . . . . . . . . . 10 72 8. Packets and Messages . . . . . . . . . . . . . . . . . . . . . 10 73 8.1. Prefix Solicitation (PS) Message . . . . . . . . . . . . . 10 74 8.1.1. PS Message Specification . . . . . . . . . . . . . . . 10 75 8.1.2. PS Message Generation . . . . . . . . . . . . . . . . 11 76 8.1.3. PS Message Jitter . . . . . . . . . . . . . . . . . . 11 77 8.1.4. PS Message Processing . . . . . . . . . . . . . . . . 11 78 8.2. Prefix Advertisement (PA) Message . . . . . . . . . . . . 11 79 8.2.1. PA Message Specification . . . . . . . . . . . . . . . 11 80 8.2.2. PA Message Generation . . . . . . . . . . . . . . . . 12 81 8.2.3. PA Message Jitter . . . . . . . . . . . . . . . . . . 12 82 8.2.4. PA Message Processing . . . . . . . . . . . . . . . . 12 83 8.3. Router Solicitation (RS) Message . . . . . . . . . . . . . 13 84 8.3.1. Local RS Message from Configuring Router to 85 Initiator Router . . . . . . . . . . . . . . . . . . . 13 86 8.3.2. MANET-wide RS Message from Initiator Router . . . . . 16 87 8.4. Router Advertisement (RA) Message . . . . . . . . . . . . 17 88 8.4.1. MANET-wide RA Message from Defensive Router . . . . . 17 89 8.4.2. Local RA Message from Initiator Router to 90 Configuring Router . . . . . . . . . . . . . . . . . . 18 91 8.5. Acknowledgement (AC) Message . . . . . . . . . . . . . . . 19 92 8.5.1. AC Message Specification . . . . . . . . . . . . . . . 19 93 8.5.2. AC Message Generation . . . . . . . . . . . . . . . . 19 94 8.5.3. AC Message Jitter . . . . . . . . . . . . . . . . . . 19 95 8.5.4. AC Message Processing . . . . . . . . . . . . . . . . 20 97 9. Message Considered for Forwarding . . . . . . . . . . . . . . 20 98 10. Router States . . . . . . . . . . . . . . . . . . . . . . . . 21 99 10.1. State Change . . . . . . . . . . . . . . . . . . . . . . . 21 100 10.1.1. From Configuring State to Defensive State . . . . . . 21 101 10.1.2. From Defensive State to Configuring State . . . . . . 21 102 11. Initiator Selection . . . . . . . . . . . . . . . . . . . . . 22 103 12. Prefix Conflict . . . . . . . . . . . . . . . . . . . . . . . 22 104 13. Protocol Optimizations . . . . . . . . . . . . . . . . . . . . 22 105 13.1. Proxying . . . . . . . . . . . . . . . . . . . . . . . . . 22 106 13.2. Unicast RA Messages . . . . . . . . . . . . . . . . . . . 22 107 13.3. Optimized Broadcasting . . . . . . . . . . . . . . . . . . 22 108 14. Additional Considerations . . . . . . . . . . . . . . . . . . 23 109 14.1. Duplicate UUIDs . . . . . . . . . . . . . . . . . . . . . 23 110 14.2. No initiator router exist . . . . . . . . . . . . . . . . 23 111 14.3. Initiator Proxying . . . . . . . . . . . . . . . . . . . . 23 112 15. Proposed Values for Parameters and Constants . . . . . . . . . 23 113 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 114 16.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 23 115 16.2. Message Types . . . . . . . . . . . . . . . . . . . . . . 23 116 16.3. Message TLV Types . . . . . . . . . . . . . . . . . . . . 24 117 16.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 25 118 17. Security Considerations . . . . . . . . . . . . . . . . . . . 26 119 18. Normative References . . . . . . . . . . . . . . . . . . . . . 26 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 122 1. Introduction 124 This document adheres to the address architecture specified in 125 [RFC5889], i.e.: 127 o IP addresses configured on an interface are unique, at least 128 within the routing domain, and, 130 o No on-link subnet prefix is configured on this interface . 132 This specification allows to configure MANET-local and global 133 prefixes to MANET routers. A router using the specified mechanism 134 (i) acquires a MANET-wide unique prefix, and (ii) configures 135 addresses from within this prefix for its interfaces as well as hosts 136 attached to these routers (using any mechanism, such as SLAAC 137 [RFC4861] or DHCPv6 [RFC3315]). This document does not stipulate how 138 to configure link-local addresses or link-local prefixes. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in 145 [RFC2119]. 147 This document uses the terminology and notation defined in [RFC5444]. 148 Additionally, it defines the following terminology: 150 o Configuring Router 152 A Configuring Router is a router which has not yet configured a 153 prefix, and which uses the protocol specified in this document 154 in order to acquire a prefix. 156 o Initiator Router 158 A Configuring Router selects one Initiator Router in the 159 process of acquiring a prefix, which assists in validating the 160 uniqueness of the chosen tentative prefix. 162 o Defensive Router 164 A Defensive Router is a router which has already configured a 165 prefix, and which can assist other, unconfigured routers (i.e. 166 Configuring Routers) and thereby become an Initiator Router for 167 unconfigured routers. 169 3. Applicability Statement 171 This autoconfiguration mechanism is applicable for MANET routers. 172 The mechanism allows to configure MANET-wide and globally unique 173 prefixes on a router, adhering to the address architecture specified 174 in [RFC5889]. 176 This mechanism is applicable for IPv6. 178 4. Protocol Overview and Functioning 180 Each MANET router will acquire a prefix, constructed as d:p:s:: with 181 d being a prefix (possibly of size 0), common for the whole site 182 (e.g., a global prefix assigned administratively to a given site, or 183 provided by an Internet gateway), p being common for all routers in 184 this MANET, and s being unique to a specific router. 186 The task for a router, appearing in a MANET, can thus be summarized 187 as: 189 o Acquiring d and p from the network; 191 o Selecting s, unique within the MANET; 193 o Configuring own MANET interfaces with addresses from within 194 d:p:s:: (and with a prefix length of /128). 196 A router, appearing in a network and wishing to be configured, is 197 denoted a "Configuring router". Through a Prefix Solicitation (PS) / 198 Prefix Advertisement (PA) message exchange, the router learns of the 199 (already configured) routers in its vicinity, and selects one as 200 initiator - the router which will assist in acquiring a valid 201 configuration. The Configuring router extracts d and p from the PA 202 received from the selected initiator, generates a tentative prefix 203 d:p:s:: (s being generated locally by the Configuring router, e.g., 204 by a pseudorandom generator) and, by way of a Router Solicitation 205 (RS) message requests from its initiator that this tentative prefix 206 be verified unique within the MANET. The initiator then issues an RS 207 to the entire MANET, containing the tentative address of its 208 Configuring router, through the MANET. If the initiator does not 209 (after due delay and retransmissions) receive a Router Advertisement 210 (RA) indicating that the prefix is already in use, it will transmit 211 an Autoconfiguration Confirmation (AC) message to the Configuring 212 router, confirming that the Configuring router now "owns" d:p:s:: and 213 can become a Defensive router. If the initiator receives an RA 214 indicating that the tentative prefix is already in use, it informs 215 the Configuring router by issuing an RA. 217 A Defensive router has two tasks. First, if receiving a RS 218 containing its own d:p:s::, it must respond by issuing an RA. 219 Second, if receiving a PS, it must respond by a PA, thus accept 220 becoming initiator and act as described above. 222 The initiator and Configuring routers communicate using link-local 223 multicast to LL-MANET-Routers [RFC5498], with the configuring router 224 using the Unspecified Address as source [RFC3513]. These two routers 225 identify traffic destined to each other by way of UUIDsS. [RFC4122], 226 embedded in all messages exchanged between them. UUIDs are 16 octets 227 long, and as they are exchanged in messages only between neighboring 228 routers, they need only be locally unique. Network-wide messages 229 (RS/RA) are "proxyed" by the initiator, which is already configured 230 and which thereby has a MANET-wide unique address. 232 5. Protocol Parameters and Constants 234 This specification uses the parameters and constants described in 235 this section. 237 5.1. Protocol and Port Numbers 239 This protocol specifies PS, PA, RS, RA, and AC messages, which are 240 included in packets as defined by [RFC5444]. These packets may be 241 sent either using the "manet" protocol number or the "manet" well- 242 known UDP port number, as specified in [RFC5498]. 244 5.2. Multicast Address 246 The packets (as defined by [RFC5444]) which contain the messages 247 specified by this document may be locally transmitted using LL-MANET- 248 Routers, as specified in [RFC5498]. 250 5.3. IP Header 252 If the router is in the Configuring state, the source address in the 253 IP header containing control messages is set to the Unspecified 254 Address, as specified in [RFC3513]. For a router in any other state, 255 the source address is set to any (non link-local) IP address of the 256 interface transmitting the packet. 258 5.4. Hold Times 260 o N_HOLD_TIME - determines how long a Neighbor Tuple is kept in the 261 Neighbor Set in milliseconds. 263 o I_HOLD_TIME - determines the maximum time duration that a 264 Initiator Selector Tuple is kept in the Initiator Selector Set in 265 milliseconds. 267 o F_HOLD_TIME - is the period after receipt of a message that is 268 forwarded by this router for which that information is recorded, 269 in order that the message is not forwarded again if received 270 again. 272 The following constraints applies to these router parameters: 274 o N_HOLD_TIME >= 0 276 o I_HOLD_TIME >= 0 278 o F_HOLD_TIME >= 0 280 5.5. Time Granularity 282 The constant C (time granularity) is used as specified in [RFC5497]. 284 5.6. Message Intervals and Timeouts 286 o PS_INTERVAL - specifies the time interval between two successive 287 PS messages in milliseconds. 289 o PS_TIMEOUT - specifies the maximum time, in milliseconds, after 290 the first transmitted PS which a router waits for an incoming PA 291 message. If no PA message has been received, this router switches 292 from Configuring State to Defensive state as described in 293 Section 10.1.1. 295 o RS_INTERVAL - specifies the time interval between two successive 296 local RS messages in milliseconds. 298 o RS_TIMEOUT - specifies the maximum time, in milliseconds, after 299 the first transmitted local RS message which a router waits for an 300 incoming RA or AC message. If no such message has been received, 301 this router switches from Configuring State to Defensive state. 303 o RA_INTERVAL - specifies the time interval between two successive 304 RA messages in milliseconds. 306 o RA_TIMEOUT - specifies the maximum time, in milliseconds, after 307 the first transmitted RA during which this router transmits RA 308 messages. 310 o AC_INTERVAL - specifies the time interval between two successive 311 AC messages in milliseconds. 313 o AC_TIMEOUT - specifies the maximum time, in milliseconds, after 314 the first transmitted AC during which this router transmits AC 315 messages. 317 5.7. Jitter 319 o PS_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] 320 for generated PS messages on this MANET interface. 322 o PA_MAXJITTER - represents the value of MAXJITTER used in [RFC5148] 323 for generated PA messages on this MANET interface. 325 o F_MAXJITTER - represents the default value of MAXJITTER used in 326 [RFC5148] for messages forwarded by this router. 328 6. Information Sets 330 6.1. Neighbor Set 332 A router's Neighbor Set records site prefixes and MANET prefixes of 333 each of its 1-hop Defensive neighbor routers. It consists of 334 Neighbor Tuples, each representing a single such 1-hop neighbor: 336 (N_UUID, N_is_initiator, N_site_prefix, N_site_prefix_length, 337 N_manet_prefix, N_manet_prefix_length, N_iface, N_time) 339 where: 341 N_UUID - is the unique identifier of the neighbor, as received in a 342 PA message. 344 N_is_initiator - is a boolean flag that determines whether this 345 neighbor is selected as initiator. 347 N_site_prefix - is the site prefix d as indicated by a PA message. 349 N_site_prefix_length - is the length of N_site_prefix in number of 350 bits. 352 N_manet_prefix - is the MANET prefix p as indicated by a PA message. 354 N_manet_prefix_length - is the length of N_manet_prefix in number of 355 bits. 357 N_iface - is the identifier of the network interface on which the 358 neighbor can be reached. 360 N_time - specifies when this Tuple expires and MUST be removed. 362 6.2. Initiator Selector Set 364 A router's Initiator Selector Set records UUIDs and tentative 365 prefixes of each 1-hop Configuring neighbor router, which has 366 selected this router as its initiator. It consists of Initiator 367 Selector Tuples, each representing a single 1-hop neighbor: 369 (I_UUID, I_prefix, I_prefix_length, I_iface, I_time) 371 where: 373 I_UUID - is the unique identifier of the initiator selector, as 374 received in a local RS message. 376 I_prefix - is the tentative prefix s as indicated by the initiator 377 selector in an RS message. 379 I_prefix_length - is the length of I_prefix in number of bits. 381 I_iface - is the identifier of the network interface on which the 382 neighbor can be reached. 384 I_time - specifies when this Tuple expires and MUST be removed. 386 6.3. Forwarded Set 388 A router has a single Forwarded Set which records signatures of 389 messages which have been forwarded by the router. It consists of 390 Forwarded Tuples: 392 (F_type, F_orig_addr, F_seq_number, F_time) 394 where: 396 F_type - is the forwarded Message Type; 398 F_orig_addr - is the originator address of the forwarded message; 400 F_seq_number - is the message sequence number of the forwarded 401 message; 403 F_time - specifies the time at which this Tuple expires and MUST be 404 removed. 406 7. Unique Identifiers 408 Throughout this document, it is supposed that routers have a unique 409 identifier (UUID) of length of 16 octets, according to [RFC4122]. 410 This identifier can be created by a pseudo-random number generator or 411 any other means (such as calculated from the MAC address of a network 412 interface). The identifier serves to discern routers without 413 configured IP addresses in a 1-hop neighborhood. They SHOULD be 414 unique within a link-local scope. If they are not unique within this 415 scope, the mechanism will still work, however, as described in 416 Section 14.1. 418 8. Packets and Messages 420 The packet and message format used by this protocol is defined in 421 [RFC5444], which is used with the following considerations: 423 o This protocol specifies five Message Types, the Prefix 424 Solicitation (PS) message, the Prefix Advertisement (PA) message, 425 the Router Solicitation (RS) message, the Router Advertisement 426 (RA) message, and the Acknowledgment (AC) message. 428 o PS, PA, and AC messages MUST NOT be forwarded, i.e., a , if present, MUST have the value 1. 431 o All five message types MAY be included in multi-message packets as 432 specified in [RFC5444]. 434 o Received messages MUST be parsed in accordance with [RFC5444]. A 435 message which is not in conformance with [RFC5444] MUST be 436 discarded without being processed. 438 o This protocol specifies two Address Block TLVs. These TLV Types 439 are all defined only with Type Extension = 0. TLVs of other 440 types, and of these types but without Type Extension = 0, are 441 ignored by this protocol. 443 8.1. Prefix Solicitation (PS) Message 445 A PS message is broadcast by a Configuring router to its 1-hop 446 neighbors in order to discover already configured routers, and if 447 such exist, to acquire their site prefix and MANET prefix. 449 8.1.1. PS Message Specification 451 The field is set to 15. The PS message MUST not 452 contain a header field. SHOULD be set 453 to 1. 455 The PS message does not contain any addresses, Address Block TLVs, or 456 Message TLVs (but MAY so by an extension of this protocol). 458 8.1.2. PS Message Generation 460 A PS message is generated per router and sent over all MANET 461 interfaces when the router is not yet configured and desires to 462 acquire a MANET-wide unique prefix. 464 If no PA message has been received on any interface after 465 PS_INTERVAL, the router generates a new PS message. 467 If no PA message has been received within PS_TIMEOUT after the first 468 generated PS message, the router assumes that it is the first router 469 of the MANET and switches to the "Defensive state" (as described in 470 Section 10.1.1). 472 8.1.3. PS Message Jitter 474 If using data link and physical layers which are subject to packet 475 loss due to collisions, PS messages SHOULD be jittered as described 476 in [RFC5148]. PS messages MUST NOT be forwarded, and thus message 477 forwarding jitter does not apply to PS messages. Each form of jitter 478 described in [RFC5148] requires a parameter MAXJITTER. These 479 parameters may be dynamic, and are specified by PS_MAXJITTER. 481 8.1.4. PS Message Processing 483 A router in Configuring state MUST ignore incoming PS messages. 485 A router in the Defensive state MAY trigger a PA message upon 486 reception of an incoming PS message. The PA message is transmitted 487 on the same interface the PS message has been received as described 488 in Section 8.2. 490 8.2. Prefix Advertisement (PA) Message 492 A PA message is broadcast by a Defensive router to its 1-hop 493 neighbors, as a response to an incoming PS message. 495 8.2.1. PA Message Specification 497 The field is set 15. SHOULD be set 498 to 1. 500 The PA message MUST contain a UUID Message TLV with the router's 501 Unique identifier (UUID) as TLV value and length 16 and type 502 extension 1 (which indicates that it is a source UUID). 504 The PA message MUST contain the MANET prefix, contained in an Address 505 Block and associated with a MANET_PREFIX TLV. The type extension of 506 the MANET_PREFIX TLV determines the length of the prefix in number of 507 bits. 509 The PA message MAY contain the site prefix, contained in an Address 510 Block and associated with a SITE_PREFIX TLV. The type extension of 511 the SITE_PREFIX TLV determines the length of the prefix in number of 512 bits. 514 8.2.2. PA Message Generation 516 A PA message is generated by a Defensive router as a response to a 517 received PS message, and transmitted over the same interface as the 518 one on which the PS message was received. 520 8.2.3. PA Message Jitter 522 If using data link and physical layers which are subject to packet 523 loss due to collisions, PA messages SHOULD be jittered as described 524 in [RFC5148]. PA messages MUST NOT be forwarded, and thus message 525 forwarding jitter does not apply to PA messages. Each form of jitter 526 described in [RFC5148] requires a parameter MAXJITTER. These 527 parameters may be dynamic, and are specified by PA_MAXJITTER. 529 8.2.4. PA Message Processing 531 If the router is in the Configuring state, the message is processed, 532 otherwise it MUST be ignored. 534 If the message is processed, the following steps MUST be performed: 536 1. Find the Neighbor Tuple which corresponds to the UUID contained 537 in the UUID Message TLV of the message (henceforth current 538 tuple). 540 2. If no such tuple exists, create a new one (henceforth current 541 tuple) and add it to the Neighbor Set. 543 3. The values of the current tuple are set to: 545 * N_UUID: the unique identifier of the neighbor, as acquired 546 from the UUID Message TLV in the PA message. 548 * N_is_initiator: false 550 * N_site_prefix: is set to the prefix associated with the 551 SITE_PREFIX Address Block TLV in the previously received PS 552 message that triggered this PA transmission; this value may be 553 NULL if no such TLV has been contained in the PS message. 555 * N_site_prefix: is set to the length of the N_site_prefix in 556 number of bits, as acquired from the type extension of the 557 SITE_PREFIX TLV or 0 if no SITE_PREFIX TLV has been contained 558 in the PS message. 560 * N_manet_prefix: is set to the MANET prefix associated with the 561 MANET_PREFIX Address Block TLV in the previously received PS 562 message that triggered this PA transmission. 564 * N_manet_prefix_length: is set to the length of N_manet_prefix 565 in number of bits, as acquired from the type extension of the 566 MANET_PREFIX Address Block TLV. 568 * N_iface: is set to the interface identifier on which the PA 569 message has been received. 571 * N_time: current time + N_HOLD_TIME (both in milliseconds) 573 8.3. Router Solicitation (RS) Message 575 A Configuring router sends a local Router Solicitation (RS) Message 576 to its initiator (using link-local multicast and the UUID of the 577 initiator in a Message TLV). Upon reception of this local RS, the 578 initiator broadcasts a Router Solicitation (RS) Message throughout 579 the MANET, on behalf of the Configuring router. In the following, 580 these two different cases (RS between Configuring router and 581 initiator router, and RS flooded by the initiator) are discerned. In 582 both cases, the same message type (RS) is used, as only the link- 583 local RS contains the UUID TLV, which allows to differentiate between 584 the two different message scopes. 586 8.3.1. Local RS Message from Configuring Router to Initiator Router 588 8.3.1.1. Local RS Message Specification 590 The field is set to 15. The local RS message MUST 591 NOT contain a header field. SHOULD be 592 set to 1. 594 The local RS message MUST contain a UUID Message TLV with the UUID of 595 the router's selected initiator as value and type extension 0 (i.e. 597 indicating a destination UUID). 599 The local RS message MUST contain a UUID Message TLV with this 600 router's UUID as value and type extension 1 (i.e. indicating a source 601 UUID). 603 The local RS message MUST contain a TIMEOUT Message TLV with the 604 value being: 606 time_of_first_sent_RS - current_time + RS_TIMEOUT. 608 where 610 o time_of_first_sent_RS is the time of the first RS that has been 611 sent for the tentative prefix, or the current time if this message 612 is the first one. 614 The value is encoded using the format specified in [RFC5497]. 616 The local RS message MUST contain the tentative router prefix s in an 617 address block associated with a TENTATIVE_PREFIX Address Block TLV 618 with the value hereof being the length of the prefix in number of 619 bits. 621 8.3.1.2. Local RS Message Generation 623 An RS message is generated after the router has selected an initiator 624 (as specified in Section 11). The message is sent to the MANET 625 interface on which the initiator can be reached (determined from 626 N_iface in the Neighbor Set). 628 If no RA or AC message has been received on the N_iface interface 629 from the selected initiator (determined from the Neighbor Tuple of 630 the initiator) after RS_INTERVAL milliseconds, the router generates a 631 new local RS message. This process is repeated until an RA or AC 632 message has been received, or otherwise RS_TIMEOUT milliseconds have 633 passed since the first generated local RS message for this prefix. 635 If then still no RA or AC message has been received, the router 636 SHOULD restart the autoconfiguration process and start transmitting 637 PS messages again (refer to Section 8.1) or select a new initiator 638 router. 640 8.3.1.3. Local RS Message Jitter 642 No jitter is required for local RS messages, since only one router - 643 the selected initiator - will process them. 645 8.3.1.4. Local RS Message Processing 647 If the message does not contain any UUID Message TLVs, it is 648 considered a MANET-wide RS Message and processed accordingly (refer 649 to Section 8.3.2). 651 If the router receiving an RS is in Configuring state, the message 652 MUST be ignored. 654 If the message does not contains a UUID Message TLV with type 655 extension 0, it MUST be ignored. Otherwise, if the value of that 656 UUID Message TLV does not correspond to this router's UUID, the 657 message MUST be ignored. 659 If the message does not contain an address associated with a 660 TENTATIVE_PREFIX Address Block TLV, the message MUST be ignored. 662 If a prefix conflict between the router's prefix s and the address 663 associated with a TENTATIVE_PREFIX Address Block TLV has been 664 detected, a local RA message MUST be triggered (as specified in 665 Section 8.4.2). 667 If the message is not ignored, the following steps MUST be performed: 669 1. If no Initiator Selector Tuple exists, which corresponds to the 670 UUID contained in the UUID Message TLV with type extension 0 in 671 the message, create a new tuple and add it to the Initiator 672 Selector Set. The values of the newly created tuple are: 674 * I_UUID: the unique identifier of the neighbor, as acquired 675 from the UUID Message TLV in the RS message. 677 * I_prefix: is the prefix associated with the TENTATIVE_PREFIX 678 Address Block TLV in the RS message. 680 * I_prefix_length is the length of the I_prefix in number of 681 bits, as acquired from the value of the TENTATIVE_PREFIX 682 Address Block TLV. 684 * I_iface: is set to the interface identifier on which the RS 685 message has been received. 687 * I_time: current_time + max(I_HOLD_TIME, 688 value_of_the_TIMEOUT_Message_TLV) # in milliseconds 690 2. A MANET-wide RS message is generated (refer to Section 8.3.2.2). 692 8.3.2. MANET-wide RS Message from Initiator Router 694 8.3.2.1. MANET-wide RS Message Specification 696 The field is set to 15. The MANET-wide RS message 697 MUST contain a header field, which contains the 698 prefix s of this router. SHOULD set to 255. The 699 MANET-wide RS message MUST contain a field. 701 The MANET-wide RS message MUST NOT contain any UUID Message TLVs. 703 The MANET-wide RS message MUST contain the tentative prefix in an 704 address block associated with a TENTATIVE_PREFIX Address Block TLV 705 with the value being the length of the prefix in number of bits. The 706 prefix is acquired from the I_prefix field in the Initiator Selector 707 Tuple that corresponds to the initiator selector that has sent the 708 local RS message, which triggered this MANET-wide RS message. 710 8.3.2.2. MANET-wide RS Message Generation 712 Whenever a router has received a local RS message from a router that 713 has selected it as its initiator (i.e. for which a corresponding 714 Initiator Selector tuple exists), it generates a MANET-wide RS 715 message and sends it to all MANET interfaces. 717 8.3.2.3. MANET-wide RS Message Jitter 719 No jitter is required for generating MANET-wide RS messages. 720 However, for forwarded RS messages, jitter considerations as 721 specified in Section 9 apply. 723 8.3.2.4. MANET-wide RS Message Processing 725 If the message contains a UUID Message TLV, it is considered as local 726 RS Message and processed accordingly (refer to Section 8.3.1.4). 728 If this router is in the Configuring state, the message MUST be 729 ignored. 731 If the message does not contain an address associated with a 732 TENTATIVE_PREFIX Address Block TLV, the message MUST be ignored. 734 If a prefix conflict between the router's prefix s and the address 735 associated with a TENTATIVE_PREFIX Address Block TLV has been 736 detected, a MANET-wide RA message MUST be generated, specified in 737 Section 8.4.1. 739 If no conflict has occurred, the message is considered for forwarding 740 as specified in Section 9. 742 8.4. Router Advertisement (RA) Message 744 A Defensive router floods a MANET-wide Router Advertisement (RA) 745 Message throughout the MANET if it has detected a conflicting prefix 746 (as specified in Section 12) advertised in an RS message. When the 747 initiator router for the conflicting prefix receives this RA, it 748 generates a local RA message to its initiator selector (using link- 749 local multicast and the UUID of the initiator in a Message TLV). In 750 the following, these two different cases (RA flooded by the 751 conflicting router, and RA between initiator router and Configuring 752 router) are discerned. In both cases, the same message type (RA) is 753 used, as only the link-local RA contains the UUID TLV, which allows 754 to differentiate between the two different message scopes. 756 8.4.1. MANET-wide RA Message from Defensive Router 758 8.4.1.1. MANET-wide RA Message Specification 760 The field is set to 15. The MANET-wide RA message 761 MUST contain a header field. SHOULD 762 be set to 255. The MANET-wide RA message MUST contain a field. 765 The MANET-wide RA message MUST NOT contain a UUID Message TLV. 767 The MANET-wide RA message MUST put its prefix (i.e. the prefix which 768 is conflicting) in an address block and associate with a 769 TENTATIVE_PREFIX Address Block TLV. 771 8.4.1.2. MANET-wide RA Message Generation 773 A MANET-wide RA message is generated as a response to an incoming 774 MANET-wide RS message if a prefix conflict has been detected (as 775 specified in Section 12). The message is sent to all MANET 776 interfaces. 778 The router generates a new RA message RA_INTERVAL milliseconds after 779 the last generated RA message. This process is repeated until 780 RA_TIMEOUT milliseconds have passed since the first generated RA 781 message for this prefix. 783 8.4.1.3. MANET-wide RA Message Jitter 785 No jitter is applied to generated RA messages. When forwarding an RA 786 message, jitter is applied as specified in Section 9. 788 8.4.1.4. MANET-wide RA Message Processing 790 If the message contains a UUID TLV, then: 792 o if this router is a Configuring router, the message is considered 793 as local RA Message and processed accordingly (refer to 794 Section 8.4.2). 796 o or otherwise the message MUST be ignored. 798 If the message does not contain a UUID TLV, then: 800 o if the message contains an address associated with a 801 TENTATIVE_PREFIX TLV, and the address is contained in the I_prefix 802 field of an Initiator Selector Tuple, then the router generates a 803 local RA as specified in Section 8.4.2. 805 o otherwise, the message is considered for forwarding as specified 806 in Section 9. 808 8.4.2. Local RA Message from Initiator Router to Configuring Router 810 8.4.2.1. Local RA Message Specification 812 The field is set to 15. SHOULD be 813 set to 1. 815 The local RA message MUST contain a UUID Message TLV with type 816 extension 0 with the value being the UUID of the initiator selector. 817 The UUID is determined from the I_UUID field of the Initiator 818 Selector Tuple whose I_prefix is equivalent to the address of the 819 MANET-wide RA which is associated with an TENTATIVE_PREFIX Address 820 Block TLV. 822 8.4.2.2. Local RA Message Generation 824 A local RA message is generated as a response to an incoming MANET- 825 wide RA message, if the message contains a tentative prefix, which is 826 equivalent to an I_prefix entry of an Initiator Selector Tuple. The 827 message is sent to the I_iface interface of the initiator selector. 829 8.4.2.3. Local RA Message Jitter 831 No jitter is applied. 833 8.4.2.4. Local RA Message Processing 835 If the message does not contain a UUID Message TLV, then the message 836 is processed as specified in Section 8.4.1.4. 838 If the message contains a UUID TLV, then: 840 o if this router is a Configuring router and if the TLV value from 841 the UUID Message TLV corresponds to this router's UUID, then this 842 router MUST: 844 * Choose another tentative prefix s, and 846 * Restart the autoconfiguration process by generating RS messages 847 with this new tentative prefix. 849 o or otherwise the message MUST be ignored. 851 8.5. Acknowledgement (AC) Message 853 8.5.1. AC Message Specification 855 The field is set to 15. SHOULD be 856 set to 1. 858 The AC message MUST contain a UUID Message TLV with type extension 0 859 with the UUID of the Configuring router as TLV value. 861 The AC message MUST contain the tentative prefix in an address block 862 associated with an TENTATIVE_PREFIX Address Block TLV with the length 863 of the prefix in number of bits as TLV value. 865 The AC message MAY contain any other TLV as specified by extensions 866 to this protocol. 868 8.5.2. AC Message Generation 870 An AC message is generated on a Defensive router when no RA message 871 has been received for a tentative prefix of an initiator at the time 872 the Initiator Selector Tuple expires (i.e. at I_time). The message 873 is sent to the I_iface interface of the initiator selector. 875 8.5.3. AC Message Jitter 877 No jitter is applied. 879 8.5.4. AC Message Processing 881 If the receiving router is not a Configuring router, then the message 882 MUST be ignored. 884 Otherwise, if: 886 o the message contains a UUID TLV and the value from the UUID 887 Message TLV corresponds to this router's UUID and 889 o the message contains an address associated with a TENTATIVE_PREFIX 890 Address Block TLV, and the address is equivalent to this router's 891 tentative prefix, then this router MUST: 893 * Select this prefix as permanent. 895 * Switch in the Defensive state (as specified in Section 10.1.1 897 o or otherwise the message MUST be ignored. 899 9. Message Considered for Forwarding 901 If a message (the "current message") is considered for forwarding, 902 then the following tasks MUST be performed: 904 1. If a Forwarded Tuple exists with: 906 * F_type = the Message Type of the current message, AND; 908 * F_orig_addr = the originator address of the current message, 909 AND; 911 * F_seq_number = the sequence number of the current message. 913 then the current message MUST be silently discarded. 915 2. Otherwise: 917 1. The Message Header of the current message is modified by: 919 + if present, decrement in the Message 920 Header by 1, AND; 922 + if present, increment in the Message 923 Header by 1. 925 2. The message is transmitted over all interfaces. 927 If using data link and physical layers which are subject to packet 928 loss due to collisions, forwarded messages SHOULD be jittered as 929 described in [RFC5148]. PS messages MUST NOT be forwarded, and thus 930 message forwarding jitter does not apply to PS messages. Each form 931 of jitter described in [RFC5148] requires a parameter MAXJITTER. 932 These parameters may be dynamic, and are specified by F_MAXJITTER. 934 10. Router States 936 A router is in either of the following states: 938 o Configuring 940 o Defensive 942 10.1. State Change 944 10.1.1. From Configuring State to Defensive State 946 A router can change from Configuring state to Defensive state (i.e. 947 complete the autoconfiguration process) in two different ways: 949 1. If no PA message has been received within PS_TIMEOUT milliseconds 950 after the first generated PS message of a Configuring router, the 951 router assumes that it is the first router of the MANET. It then 952 uses a predefined site-local prefix part "d", creates a random 953 MANET prefix part "p" of length PREFIX_LENGTH using a pseudo- 954 random number generator and concatenates a random router prefix 955 part "s". The Neighbor Set can be cleared (i.e. all Neighbor 956 Tuples deleted). The router switches to the "Defensive state". 958 2. If the Configuring router receives an AC message from its 959 initiator router for the tentative prefix, the Configuring router 960 uses a predefined site-local prefix part "d" and the MANET prefix 961 part "p" that is has acquired by PA messages from the Initiator. 962 It then concatenates a the tentative router prefix part "s", 963 which it has verified to be unique within the MANET. The 964 Neighbor Set can be cleared (i.e. all Neighbor Tuples deleted). 965 The router switches to the "Defensive state". 967 10.1.2. From Defensive State to Configuring State 969 TBD: Router releases the prefix and needs a new prefix. 971 11. Initiator Selection 973 After a Configuring router has received at least one PA message, it 974 may at any time select its initiator router among the neighbors from 975 which it has received a PA message. As soon as it has selected the 976 initiator router, it can start generating RS messages. This document 977 does not specify how to select the initiator router. For example, a 978 router could select the first router that from which it has received 979 a PA message. PA messages MAY also include additional information by 980 means of TLVs that can be used to determine the best initiator 981 router. 983 Examples of such information may be: 985 o number of routers in the MANET; 987 o density of the routers in the MANET; 989 o distance to an Internet gateway; 991 o distance to a certain address prefix. 993 12. Prefix Conflict 995 A prefix conflict occurs when a requested prefix (by means of an RS 996 message) is equivalent to the router prefix of this router. 998 TBD 1000 13. Protocol Optimizations 1002 The following protocol optimizations MAY be applied to the base 1003 protocol in order to increase performance. 1005 13.1. Proxying 1007 TBD 1009 13.2. Unicast RA Messages 1011 TBD 1013 13.3. Optimized Broadcasting 1015 TBD 1017 14. Additional Considerations 1019 14.1. Duplicate UUIDs 1021 TBD 1023 14.2. No initiator router exist 1025 TBD 1027 14.3. Initiator Proxying 1029 TBD 1031 15. Proposed Values for Parameters and Constants 1033 TBD 1035 16. IANA Considerations 1037 This specification defines five Message Types, which must be 1038 allocated from the "Message Types" repository of [RFC5444], four 1039 Message TLV Types, which must be allocated from the "Message TLV 1040 Types" repository of [RFC5444], and one Address Block TLV Type, which 1041 must be allocated from the "Address Block TLV Types" repository of 1042 [RFC5444] 1044 16.1. Expert Review: Evaluation Guidelines 1046 For the registries where an Expert Review is required, the designated 1047 expert SHOULD take the same general recommendations into 1048 consideration as are specified by [RFC5444]. 1050 16.2. Message Types 1052 This specification defines five Message Types, to be allocated from 1053 the 0-223 range of the "Message Types" namespace defined in 1054 [RFC5444], as specified in Table 1. 1056 +------+----------------------------------+ 1057 | Type | Description | 1058 +------+----------------------------------+ 1059 | TBD1 | PS: Prefix Solicitation message | 1060 | TBD2 | PA: Prefix Advertisement message | 1061 | TBD3 | RS: Router Solicitation message | 1062 | TBD4 | RA: Router Advertisement message | 1063 | TBD5 | AC: Acknowledgment message | 1064 +------+----------------------------------+ 1066 Table 1: Message Type Assignment 1068 16.3. Message TLV Types 1070 This specification defines four Message TLV Types, which must be 1071 allocated from the "Message TLV Types" namespace defined in 1072 [RFC5444]. IANA is requested to make allocations in the 0-127 range 1073 for these types. This will create four new Type Extension registries 1074 with assignments as specified in Table 2, Table 3, Table 4, and 1075 Table 5. Specifications of these TLVs are in Section xxx and Section 1076 xxx, respectively. Each of these TLVs MUST NOT be included more than 1077 once in a Message TLV Block. 1079 +------+------+-----------+----------------------------+------------+ 1080 | Name | Type | Type | Description | Allocation | 1081 | | | Extension | | Policy | 1082 +------+------+-----------+----------------------------+------------+ 1083 | UUID | TBD6 | 0 | Specifies the destination | | 1084 | | | | UUID of a neighbor router | | 1085 | UUID | TBD7 | 1 | Specifies the source UUID | | 1086 | | | | of this router | | 1087 | UUID | TBD8 | 2-255 | Unassigned | Expert | 1088 | | | | | Review | 1089 +------+------+-----------+----------------------------+------------+ 1091 Table 2: Message TLV Type assignment: UUID 1093 +--------------+-------+-----------+-------------------+------------+ 1094 | Name | Type | Type | Description | Allocation | 1095 | | | Extension | | Policy | 1096 +--------------+-------+-----------+-------------------+------------+ 1097 | MANET_PREFIX | TBD9 | 0-128 | Specifies the | | 1098 | | | | MANET prefix part | | 1099 | | | | with the type | | 1100 | | | | extension being | | 1101 | | | | the length of the | | 1102 | | | | prefix in number | | 1103 | | | | of bits. | | 1104 | MANET_PREFIX | TBD10 | 1-255 | Unassigned | Expert | 1105 | | | | | Review | 1106 +--------------+-------+-----------+-------------------+------------+ 1108 Table 3: Message TLV Type assignment: MANET_PREFIX 1110 +-------------+-------+-----------+--------------------+------------+ 1111 | Name | Type | Type | Description | Allocation | 1112 | | | Extension | | Policy | 1113 +-------------+-------+-----------+--------------------+------------+ 1114 | SITE_PREFIX | TBD11 | 0-128 | Specifies the SITE | | 1115 | | | | prefix part with | | 1116 | | | | the type extension | | 1117 | | | | being the length | | 1118 | | | | of the prefix in | | 1119 | | | | number of bits. | | 1120 | SITE_PREFIX | TBD12 | 129-255 | Unassigned | Expert | 1121 | | | | | Review | 1122 +-------------+-------+-----------+--------------------+------------+ 1124 Table 4: Message TLV Type assignment: SITE_PREFIX 1126 +---------+-------+-----------+------------------------+------------+ 1127 | Name | Type | Type | Description | Allocation | 1128 | | | Extension | | Policy | 1129 +---------+-------+-----------+------------------------+------------+ 1130 | TIMEOUT | TBD13 | 0 | Specifies the timeout | | 1131 | | | | of the Configuring | | 1132 | | | | router which are | | 1133 | | | | waiting for AC or RA | | 1134 | | | | messages. | | 1135 | TIMEOUT | TBD14 | 1-255 | Unassigned | Expert | 1136 | | | | | Review | 1137 +---------+-------+-----------+------------------------+------------+ 1139 Table 5: Message TLV Type assignment: TIMEOUT 1141 16.4. Address Block TLV Types 1143 This specification defines one Address Block TLV Type, which must be 1144 allocated from the "Address Block TLV Types" namespace defined in 1145 [RFC5444]. IANA are requested to make allocations in the 8-127 range 1146 for this type. This will create a new Type Extension registry with 1147 assignments as specified in Table 6. Specification of this TLV is in 1148 Section xxx. 1150 +------------------+-------+-----------+---------------+------------+ 1151 | Name | Type | Type | Description | Allocation | 1152 | | | Extension | | Policy | 1153 +------------------+-------+-----------+---------------+------------+ 1154 | TENTATIVE_PREFIX | TBD15 | 0 | Specifies the | | 1155 | | | | tentative | | 1156 | | | | prefix that | | 1157 | | | | is checked | | 1158 | | | | for | | 1159 | | | | uniqueness. | | 1160 | TENTATIVE_PREFIX | TBD16 | 1-255 | Unassigned | Expert | 1161 | | | | | Review | 1162 +------------------+-------+-----------+---------------+------------+ 1164 Table 6: Address Block TLV Type assignment: TENTATIVE_PREFIX 1166 17. Security Considerations 1168 TBD 1170 18. Normative References 1172 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1173 Requirement Levels", RFC 2119, BCP 14, March 1997. 1175 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1176 and M. Carney, "Dynamic Host Configuration Protocol for 1177 IPv6 (DHCPv6)", RFC 3315, July 2003. 1179 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 1180 (IPv6) Addressing Architecture", RFC 3513, April 2003. 1182 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 1183 Unique IDentifier (UUID) URN Namespace", RFC 4122, 1184 July 2005. 1186 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1187 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1188 September 2007. 1190 [RFC5148] Clausen, T., Dearlove, C., and B. Brian, "Jitter 1191 Considerations in Mobile Ad Hoc Networks (MANETs)", 1192 RFC 5148, February 2008. 1194 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 1195 "Generalized MANET Packet/Message Format", RFC 5444, 1196 February 2009. 1198 [RFC5497] Clausen, T. and C. Dearlove, "Representing multi-value 1199 time in MANETs", RFC 5497, March 2009. 1201 [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network 1202 (MANET) Protocols", RFC 5498, March 2009. 1204 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 1205 Hoc Networks", RFC 5889, July 2010. 1207 Authors' Addresses 1209 Ulrich Herberg 1210 LIX, Ecole Polytechnique 1211 91128 Palaiseau Cedex, 1212 France 1214 Phone: +33-1-6933-4126 1215 Email: ulrich@herberg.name 1216 URI: http://www.herberg.name/ 1218 Thomas Clausen 1219 LIX, Ecole Polytechnique 1220 91128 Palaiseau Cedex, 1221 France 1223 Phone: +33-6-6058-9349 1224 Email: T.Clausen@computer.org 1225 URI: http://www.thomasclausen.org