idnits 2.17.1 draft-thubert-tree-discovery-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4861]), 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 390: '...following values MUST not change durin...' RFC 2119 keyword, line 413: '... receiver MUST silently ignore an...' RFC 2119 keyword, line 426: '... Implementations MUST silently ignore ...' RFC 2119 keyword, line 474: '... MUST be ignored by the receiver....' RFC 2119 keyword, line 653: '...e Mobile Routers MUST obey to the foll...' (14 more instances...) 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 following values MUST not change during the propagation of the TIO down the tree: Type, Length, G, H, TreePreference, TreeDelay and TreeID. All other fields of the TIO are updated at each hop of the propagation. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 29, 2009) is 5415 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 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. 'I-D.ietf-nemo-terminology') Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Expires: December 31, 2009 June 29, 2009 6 Nested Nemo Tree Discovery 7 draft-thubert-tree-discovery-08.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. This document may contain material 13 from IETF Documents or IETF Contributions published or made publicly 14 available before November 10, 2008. The person(s) controlling the 15 copyright in some of this material may not have granted the IETF 16 Trust the right to allow modifications of such material outside the 17 IETF Standards Process. Without obtaining an adequate license from 18 the person(s) controlling the copyright in such materials, this 19 document may not be modified outside the IETF Standards Process, and 20 derivative works of it may not be created outside the IETF Standards 21 Process, except to format it for publication as an RFC or to 22 translate it into languages other than English. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 31, 2009. 42 Copyright Notice 44 Copyright (c) 2009 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents in effect on the date of 49 publication of this document (http://trustee.ietf.org/license-info). 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. 53 Abstract 55 This paper describes a simple distance vector protocol that exposes 56 only a default route towards the infrastructure in a nested NEMO 57 configuration. The draft extends the Neighbor Discovery Protocol 58 [RFC4861] in order to carry information and metrics which will help a 59 Mobile Router select its Attachment Router(s) in an autonomous 60 fashion and provides generic rules which guarantee that the 61 interaction of different selection processes will not create loops. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 69 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3.1. Multi-Homed nested mobile network . . . . . . . . . . . . 6 71 3.2. Loops in nested Nemo . . . . . . . . . . . . . . . . . . . 7 73 4. Tree Information Option . . . . . . . . . . . . . . . . . . . 9 74 4.1. TIO base option . . . . . . . . . . . . . . . . . . . . . 9 75 4.2. TIO suboptions . . . . . . . . . . . . . . . . . . . . . . 12 76 4.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 4.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 4.2.4. Bandwidth Suboption . . . . . . . . . . . . . . . . . 13 80 4.2.5. Stable time Suboption . . . . . . . . . . . . . . . . 14 81 4.2.6. Tree Group ID Suboption . . . . . . . . . . . . . . . 15 82 4.2.7. Path Free Medium Time Suboption . . . . . . . . . . . 15 83 4.2.8. Uniform Path Metric Suboption . . . . . . . . . . . . 16 85 5. Tree Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17 86 5.1. tree selection . . . . . . . . . . . . . . . . . . . . . . 18 87 5.2. Sub-tree mobility . . . . . . . . . . . . . . . . . . . . 19 88 5.3. Administrative depth . . . . . . . . . . . . . . . . . . . 20 89 5.4. DRL entries states and stability . . . . . . . . . . . . . 20 90 5.4.1. Held-Up . . . . . . . . . . . . . . . . . . . . . . . 20 91 5.4.2. Held-Down . . . . . . . . . . . . . . . . . . . . . . 21 92 5.4.3. Collision . . . . . . . . . . . . . . . . . . . . . . 21 93 5.4.4. Instability . . . . . . . . . . . . . . . . . . . . . 22 94 5.4.5. Density . . . . . . . . . . . . . . . . . . . . . . . 23 95 5.5. Legacy Routers . . . . . . . . . . . . . . . . . . . . . . 23 97 6. Directed Acyclic Graph Discovery . . . . . . . . . . . . . . . 23 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 103 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 24 105 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 108 11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 26 109 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 26 111 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 113 1. Introduction 115 As per Nemo Basic support [RFC3963], a Mobile Router autoconfigures a 116 single Care of Address (CoA) to register to its Home Agent and 117 terminate its Mobile Router-Home Agent tunnel. That Care of Address 118 is the Mobile Router point of attachment to the nested Nemo. 120 Consequently, if loops are avoided, the nested Nemo assumes the shape 121 of a tree. The nodes of the tree are Mobile Routers, the root is 122 either a fixed or a Mobile Router, called in the latter case the root 123 Mobile Router in NEMO terminology [I-D.ietf-nemo-terminology]. The 124 leaves are mobile or fixed hosts, called Local Fixed Nodes, Local 125 Mobile Nodes and Visiting Mobile Nodes in the NEMO terminology. 127 This paper provides (1) a minimum extension to IPv6 Neighbor 128 Discovery Router Advertisements in order to ensure that Mobile 129 Routers attaching to one another actually avoid loops and end up 130 forming a tree, and (2) the minimum common part of all Mobile Router 131 algorithms that is required to ensure that whatever their specific 132 decisions, loops between Mobile Routers will be avoided. 134 The method is based on an autonomous decision by each Mobile Router 135 with no global state convergence such as a MANET proactive routing 136 protocol. In fact, Mobile Routers may make different decisions from 137 a same input, based on their own configuration and their own 138 algorithms. 140 In order to build trees of Mobile Routers, we propose an extension to 141 the ICMP Router Advertisement (RA) message, the Tree Information 142 Option (TIO). The TIO allows Mobile Routers to advertise the tree 143 they belong to, and to select and move to the best location within 144 the available trees. Mobile Routers propagate the TIO in RA down the 145 tree, updating some metrics such as the tree depth, leaving alone 146 root information such as the tree identifier, and sending the result 147 in RAs over the ingress interfaces. 149 2. Terms and Abbreviations 151 This document assumes that the reader is familiar with Mobile IPv6 as 152 defined in [RFC3775] and with the concept of Mobile Router defined in 153 the Nemo terminology document [I-D.ietf-nemo-terminology]. 155 For the needs of this paper, the following new definitions are 156 introduced: 158 Nemo clusterhead: The root of a tree of mobile routers. When the 159 tree of Mobile Routers is attached to the infrastructure, the 160 fixed Access Router may act as cluster head if it supports the 161 Tree Information Option described in this document. If it does 162 not, then the clusterhead coincides with the root Mobile Router in 163 NEMO terminology. A clusterhead is elected even when the tree is 164 not attached to the infrastructure. A stand-alone Mobile Router 165 is a clusterhead. 167 Floating Tree: A Nested Nemo which clusterhead is a Mobile Router 168 that is not attached to an Access Router. 170 Grounded Tree: A Nested Nemo whose clusterhead is attached to the 171 infrastructure. In other words, the clusterhead is either a fixed 172 router that supports Router Advertisement - Tree Information 173 Option or is a Mobile Router which attachment router is a fixed 174 router that does not support Router Advertisement - Tree 175 Information Option. 177 Mobile Access Router: A Mobile Router that provides Access Router 178 services to other Mobile Routers. 180 Attachment Router: The Router that is selected as Access Router by a 181 Mobile Router, making it its parent in the nested NEMO tree. 183 Propagation: The action by a Mobile Router that consists in 184 receiving a Router Advertisement Tree Information Option from its 185 Attachment Router, recomputing a few specific fields, removing 186 unknown suboptions, and appending the resulting TIO to RAs sent 187 over the ingress interfaces. 189 Uniform Path Metric: A multihop metric that can be used by Tree 190 Discovery plug-ins to select feasible successors and specifically 191 an Attachment Router. 193 3. Motivations 195 3.1. Multi-Homed nested mobile network 197 A nested mobile network that is made of multiple Mobile Routers 198 having a direct connection to the Internet is said to be multi-homed. 199 Multihoming in Nemo offers useful properties to Mobile Network Nodes. 200 The NEMO multihoming issues [I-D.ietf-nemo-multihoming-issues] draft 201 lists potential multi-homed configurations for Nemo and explains the 202 different problems and advantages that some configurations may 203 introduce. Multihoming offers three main abilities to the Nemo: it 204 allows route recovery on failure, redundancy and load-sharing between 205 Mobile Routers (or between interfaces of a given Mobile Router). 206 However, for the moment, there is no requirements nor protocol that 207 would define in interaction between several egress interfaces inside 208 a Nemo. 210 In a nested Nemo, the hierarchy of Mobile Routers increases the 211 complexity of the route and/or router selection for Mobile Network 212 Nodes. Each level of a Nemo implies the usage of a new tunnel 213 between the Mobile Router and its home agent. Thus if a Mobile 214 Network Node connects to a sub-Nemo which is also a sub-Nemo, packets 215 from the Mobile Network Node will be encapsulated three times. 217 When the Nemo where the MN is connected to is multi-homed, the MN may 218 have the choice between several Attachment Router to be its default 219 router. Reference [RFC4191] introduces new options in Router 220 Advertisement to allow any node on a link to choose between several 221 routers. This option mainly consists of a 2-bits flag that indicates 222 the preference of the router (low, medium or high). Furthermore, the 223 same flag can be set in the Route Information option indicating the 224 preference of a specific prefix. Therefore, any node can determine 225 its best default router(s) according to a given destination and its 226 best router for default, which will be used by default. 228 However this preference is only useful in a flat topology; It gives a 229 way to the node to choose between different attachment routers 230 advertising prefixes on the node link. But if the node is inside a 231 hierarchical topology the node can not learn the depth of each 232 attachment router, and might not select the most efficient path. In 233 particular, there is a need for Uniform Path Metric that accounts for 234 a multihop wireless path. 236 One of the usage of the new option introduced in this document is to 237 distribute information on the hierarchy of Mobile Routers. This 238 information can be distributed to Attachment Routers, Mobile Routers 239 and Mobile Network Nodes as well in order to allow better route 240 selection and to increase the knowledge of the Nemo topology on each 241 node. 243 3.2. Loops in nested Nemo 245 When several Mobile Routers attach to each other to form a nested 246 Nemo, loops can be created if they are not explicitly avoided. In 247 the simplest case, when egress and ingress interfaces of A Mobile 248 Router are all wireless, a mobile router may be listening to Router 249 Advertisement from its own ingress interface, creating a confliction 250 problem. In the general case, arbitrary attachment of Mobile Routers 251 will form graphs that are not exempt of loops. For instance: Assume 252 a nested Nemo where Mobile Router1 is connected to the 253 infrastructure, and Mobile Router3 is attached to Mobile Router2. 254 Say that Mobile Router2 can hear both Mobile Router3 and Mobile 255 Router1 over its wireless egress interface. If Mobile Router2 select 256 Mobile Router1, the connectivity to the infrastructure is provided 257 for all. But if Mobile Router2 selects Mobile Router3, Mobile 258 Router2 and Mobile Router3 end up forming a loop and are disconnected 259 from their Home Agents. 261 With Nemo basic support, a Mobile Router uses a single primary Care 262 Of Address to attach to the nested structure. As a result, if loops 263 are avoided, the nested NEMO end up forming a tree. It is beneficial 264 to be able to form that tree in an optimum fashion for a given set of 265 metrics such as tree depth. 267 The shape of a nested Nemo may change rapidly due to Mobile Routers 268 movement. It is thus impractical to expect each Mobile Router to be 269 able to maintain states about the whole tree structure in a link 270 state fashion. On the contrary, it is also beneficial to allow each 271 Mobile Router to make its own independent selection based on a 272 minimum information about its immediate neighbors, in order to 273 reestablish the tree quickly upon erratic movements. 275 Each Mobile Router should be able to make its own attachment router 276 selection based on its own condition (eg battery level), its own set 277 of constraints that may not apply to other Mobile Routers in the 278 tree, and in general its own algorithm. As a result, the 279 standardization effort should concentrate on a common minimum set of 280 rules that must be common to all Mobile Routers in order to prevent 281 routing loops in the nested NEMO while leaving Mobile Routers 282 independent in their Attachment Router selection algorithms. 284 4. Tree Information Option 286 The Tree Information Option carries a number of metrics and other 287 information that allows a Mobile Router to discover a tree and select 288 its point of attachment while avoiding loop generation. 290 4.1. TIO base option 292 The Tree Information Option is a container option, which might 293 contain a number of suboptions. The base option regroups the minimum 294 information set that is mandatory in all cases. 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Type | Length |G|H|B| Reserved| Sequence | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | TreePref. | BootTimeRandom | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | MR Preference | TreeDepth | TreeDelay | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | PathDigest | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 + + 309 | TreeID | 310 + + 311 | | 312 + + 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | sub-option(s)... 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 1: TIO base option 320 Type: 8-bit unsigned integer set to 10 by the clusterhead. Value is 321 "TBD". 323 Length: 8-bit unsigned integer set to 4 when there is no suboption. 324 The length of the option (including the type and length fields and 325 the suboptions) in units of 8 octets. 327 Grounded (G): The Grounded (G) flag is set when the clusterhead is 328 attached to a fixed network infrastructure (such as the Internet). 330 Home (H): The Home (H) flag is set when the Mobile Router is bound 331 to its home network over NEMO. With NEMO Basic Support,a MR that 332 is not bound Home cuts off its visitors from the Internet as well. 333 This can be solved by techniques such as Reverse Routing Header 334 [I-D.thubert-nemo-reverse-routing-header]. 336 Battery (B): The Battery (B) flag is indicates that a parent in the 337 tree operates on batteries, an indication of a costly operation. 338 It is set by a mobile router which operates on battery and when 339 set, it is left set as it is propagated down the tree. 341 Reserved: 5-bit unsigned integer set to 0 by the clusterhead. 343 Sequence Number: 8-bit unsigned integer set by the clusterhead and 344 incremented with each new TIO it sends on a link and propagated 345 with no change down the tree. 347 TreePreference: 8-bit unsigned integer set by the clusterhead to its 348 preference and unchanged at propagation. Default is 0 (lowest 349 preference). The tree preference provides a mechanism to engineer 350 the mesh of mobile routers, for instance indicating the most 351 preferred home gateway or the communication ship in a fleet at 352 sea. 354 BootTimeRandom: A random value computed at boot time and recomputed 355 in case of a duplication with another Attachment Router. The 356 concatenation of the Preference and the BootTimeRandom is a 32-bit 357 extended preference that is used to resolve collisions. It is set 358 by each Mobile Router at propagation time. 360 Preference: The administrative preference of that (mobile) Access 361 Router. Default is 0. 255 is the highest possible preference. 362 Set by each Mobile Router at propagation time. 364 TreeDepth: 8-bit unsigned integer. The tree depth of the 365 clusterhead is 0 if it is a fixed router and 1 if it is a Mobile 366 Router. The tree Depth of a tree Node is the depth of its 367 attachment router as received in a TIO, incremented by at least 368 one. All nodes in the tree advertise their tree depth in the Tree 369 Information Options that they append to the RA messages over their 370 ingress interfaces as part of the propagation process. 372 TreeDelay: 16-bit unsigned integer set by the clusterhead indicating 373 the delay before changing the tree configuration, in milliseconds. 374 A default value is 128ms. It is expected to be an order of 375 magnitude smaller than the RA-interval so if the clusterhead has a 376 sub-second RA-interval, the Tree delay may be shorter than 100ms. 377 It is also expected to be an order of magnitude longer than the 378 typical propagation delay inside the nested Nemo. 380 PathDigest: 32-bit unsigned integer CRC, updated by each Mobile 381 Router. This is the result of a CRC-32c computation on a bit 382 string obtained by appending the received value and the Mobile 383 Router Care of Address. clusterheads use a 'previous value' of 384 zeroes to initially set the PathDigest. 386 TreeID: 128-bit unsigned integer which uniquely identify a tree. 387 This value is set by the clusterhead. The global IPv6 home 388 address of the clusterhead can be used. 390 The following values MUST not change during the propagation of the 391 TIO down the tree: Type, Length, G, H, TreePreference, TreeDelay and 392 TreeID. All other fields of the TIO are updated at each hop of the 393 propagation. 395 4.2. TIO suboptions 397 In addition to the minimum options presented in the base option, a 398 number of suboptions are defined for the TIO: 400 4.2.1. Format 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Subopt. Type | Subopt Length | Suboption Data... 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 Figure 2: TIO suboption generic format 410 Suboption Type: 8-bit identifier of the type of mobility option. 411 When processing a TIO containing a suboption for which the 412 suboption Type value is not recognized by the receiver, the 413 receiver MUST silently ignore and skip over the suboption, 414 correctly handling any remaining options in the message. 416 Suboption Length: 8-bit unsigned integer, representing the length in 417 octets of the suboption, not including the suboption Type and 418 Length fields. 420 Suboption Data: A variable length field that contains data specific 421 to the option. 423 The following subsections specify the TIO suboptions which are 424 currently defined for use in the Mobility Header. 426 Implementations MUST silently ignore any TIO suboptions options that 427 they do not understand. 429 TIO suboptions may have alignment requirements. Following the 430 convention in IPv6, these options are aligned in a packet so that 431 multi-octet values within the Option Data field of each option fall 432 on natural boundaries (i.e., fields of width n octets are placed at 433 an integer multiple of n octets from the start of the header, for n = 434 1, 2, 4, or 8). 436 4.2.2. Pad1 438 The Pad1 suboption does not have any alignment requirements. Its 439 format is as follows: 441 0 442 0 1 2 3 4 5 6 7 443 +-+-+-+-+-+-+-+-+ 444 | Type = 0 | 445 +-+-+-+-+-+-+-+-+ 447 Figure 3: Pad 1 449 NOTE! the format of the Pad1 option is a special case - it has 450 neither Option Length nor Option Data fields. 452 The Pad1 option is used to insert one octet of padding in the TIO to 453 enable suboptions alignment. If more than one octet of padding is 454 required, the PadN option, described next, should be used rather than 455 multiple Pad1 options. 457 4.2.3. PadN 459 The PadN option does not have any alignment requirements. Its format 460 is as follows: 462 0 1 463 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 465 | Type = 1 | Subopt Length | Subopt Data 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 468 Figure 4: Pad N 470 The PadN option is used to insert two or more octets of padding in 471 the TIO to enable suboptions alignment. For N (N > 1) octets of 472 padding, the Option Length field contains the value N-2, and the 473 Option Data consists of N-2 zero-valued octets. PadN Option data 474 MUST be ignored by the receiver. 476 4.2.4. Bandwidth Suboption 478 This suboption carries the maximum bandwidth available up the tree 479 via a specific parent. It is the lowest speed of the links on the 480 way and does not reflect the actual use of those links in run time. 481 The value is expressed in the log base 2 of the speed, expressed in 482 bps. The Bandwidth suboption does not have any alignment 483 requirements. Its format is as follows: 485 0 1 2 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 488 | Type = 2 | Length = 1 | Bandwidth | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 491 Figure 5: Bandwidth Suboption 493 Type: Set to 2 for the Bandwidth suboption. 495 Length: Set to 1 for the Bandwidth suboption. 497 Bandwidth: 8-bit unsigned integer. The Log2 of the speed of the 498 path expressed in bps. The clusterhead initializes that field 499 using the speed of the link to the Access Router to which it is 500 attached or 0xFF if it is floating. An attached MR propagates it 501 as the minimum of the Bandwidth as received in the TIO from the 502 parent and the access speed between the MR and the parent. As a 503 result, the value received from a candidate AR is that of the 504 bottleneck between that AR and the wire access. 506 4.2.5. Stable time Suboption 508 This suboption carries an indicator of the stability of a network. 509 This indicator is the time since the branch to which the MR is 510 attached has remained unchanged. The value is expressed in the log 511 base 2 of that duration, expressed in milliseconds. The Stable time 512 suboption does not have any alignment requirements. Its format is as 513 follows: 515 0 1 2 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 518 | Type = 3 | Length = 1 | Stable time | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 521 Figure 6: Stable time 523 Type: Set to 3 for the Stable time suboption. 525 Length: Set to 1 for the Stable time suboption. 527 Stable time: 8-bit unsigned integer. The Log2 of the time since the 528 last change in the attachment branch, expressed in milliseconds. 529 This is set by the MR as it propagates the TIO down the tree, 530 indicating for how long the PathDigest in the TIO from its parent 531 has remained unchanged. 533 4.2.6. Tree Group ID Suboption 535 This suboption carries the Group ID for the tree. It is set by the 536 clusterhead and is left unchanged by the MR that propagates the TIO 537 down the tree. The Tree Group ID Suboption has an alignment 538 requirement of 8n+6. Its format is as follows: 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Type = 4 | Length = 16 | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | | 546 + + 547 | Tree | 548 + Group ID + 549 | | 550 + + 551 | | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Figure 7: Tree Group ID Suboption 556 Type: 8-bit unsigned integer. Its value is 4 for the Tree Group ID 557 suboption. 559 Length: 8-bit unsigned integer. Its value is 16 for the Tree Group 560 ID suboption. 562 Tree Group ID: 128-bit unsigned integer which identify a group for a 563 tree. This value is set by the clusterhead. It can be set 564 administratively, for instance to an IPv6 multicast group. 566 4.2.7. Path Free Medium Time Suboption 568 This suboption carries the Free Medium Time available up the tree via 569 a specific parent at a given point of time. It is an indication of 570 whether bandwidth is available to place VoIP calls for instance. As 571 defined by the Quality of Service (QoS) Task Group of the Wi-Fi 572 Alliance, the Medium Time describes the amount of time admitted to 573 access the medium, in units of 32 microsecond periods per second. 575 The Free Medium Time is the amount of time left the medium, in other 576 words ((1000000/32) - SIGMA(MT)). The Path Free Medium Time is the 577 lowest available Free Medium Time along the way and it reflects the 578 actual use of those links in run time. The Path Free Medium Time 579 suboption does not have any alignment requirements. Its format is as 580 follows: 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Type = 5 | Length = 2 | Path Free Medium Time | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Figure 8: Path Free Medium Time Suboption 590 Type: Set to 5 for the Path Free Medium Time Suboption. 592 Length: Set to 2 for the Path Free Medium Time Suboption. 594 Path Free MT: 16-bit unsigned integer. The amount of Medium Time 595 that is available along the path to the clusterhead in units of 32 596 microsecond periods per second. The clusterhead initializes that 597 field to the Free MT on the link where the TIO is issued. An 598 attached MR propagates it as the minimum of the Path Free MT as 599 received in the TIO from the parent and the Path Free MT on the 600 link on which the TIO is propagated. As a result, the value 601 received from a candidate AR is that of the bottleneck between 602 that AR and the clusterhead. 604 4.2.8. Uniform Path Metric Suboption 606 This suboption carries the Uniform Path Metric (UPM) for the path 607 along the tree. It is set to zero by the clusterhead and incremented 608 as the TIO is propagated down the tree. The Uniform Path Metric 609 Suboption has an alignment requirement of 4n+2. Its format is as 610 follows: 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Type = 6 | Length = 4 | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Uniform Path Metric | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Figure 9: Uniform Path Metric Suboption 622 Type: 8-bit unsigned integer. Its value is 6 for this suboption. 624 Length: 8-bit unsigned integer. Its value is 4 for this suboption. 626 Uniform Path Metric: 32-bit unsigned integer aggregating the cost of 627 radio hops. 629 5. Tree Discovery 631 Tree Discovery is a form of distance vector protocol for use in 632 wireless mesh networks. TD locates the nearest exit and forms a 633 Directed Acyclic Graphs towards that exit, usually a tree. TD 634 enables Mobile Routers to implement different policies for selecting 635 their preferred parent in the Tree by introducing the concept of 636 plug-in, and does not specify the plug-in operation. Rather, TD 637 specifies a set of rules to be implemented by all plug-ins to ensure 638 interoperation. TD also standardizes the format that is used to 639 advertize the most common information that is used by the plug-ins in 640 order to perform the parent selection. 642 One of these information, the tree depth, is used by Tree Discovery 643 to provide loop avoidance between plug-ins even if they implement 644 different policies, and even if these policies do not use the depth 645 as a routing metric. For instance, a MR might use the Uniform Path 646 Metric to select the nearest exit and the best parent from the 647 standpoint of that metric. Once attached to that parent, the MR 648 exposes a depth which is incremented from the parent's depth, and 649 that depth provides a comparable basis with routers which would not 650 use UPM at all. 652 In order organize and maintain loopless structure, the selection 653 plug-ins in the Mobile Routers MUST obey to the following rules and 654 definitions: 656 1. A Mobile Router that is not attached to an Attachment Router is 657 the Nemo clusterhead of its own floating tree. It's depth is 1. 658 A Mobile Router will end up in that situation when it looses its 659 current parent and there is no alternate parent that it can 660 attach to. In that case, the MR SHOULD remember the treeID and 661 the sequence counter in the TIO of the lost parent for a period 662 of time which covers multiple TIO. 664 2. A Mobile Router that is attached to an Attachment Router that 665 does not support TIO, is the clusterhead of its own grounded 666 tree. It's depth is 1. 668 3. A router sending a RA without TIO is considered a grounded 669 Attachment Router at depth 0. 671 4. The Nemo clusterhead of a tree exposes the tree in the Router 672 Advertisement Tree Information Option and Mobile Routers 673 propagate the TIO down the tree with the RAs that they forward 674 over their ingress links. 676 5. A Mobile Router that is already part of a tree MAY move at any 677 time and with no delay in order to be as close or closer to the 678 clusterhead of its current tree - i.e. as long as that does not 679 augment its own tree depth. But A Mobile Router MUST NOT move 680 down the tree that it is attached to. Mobile Routers MUST ignore 681 RAs that are received from other routers located at the same 682 depth or deeper within the same tree. 684 6. A Mobile Router may move from its current tree into any different 685 tree at any time and whatever the depth it reaches in the new 686 tree, but it may have to wait for a Tree Hop timer to elapse in 687 order to do so. A MR SHOULD NOT join a previous tree (identified 688 by its treeID) unless the sequence number in the TIO was 689 incremented since the MR left that tree, indicating that the 690 candidate parent was not attached behind this MR and kept getting 691 subsequent TIOs from the same tree. The Mobile Router MAY join 692 that other tree if it is more preferable for reasons of 693 connectivity, configured preference, free Medium Time, size, 694 security, bandwidth, tree depth, or whatever metrics the Mobile 695 Router cares to use. 697 7. If a Mobile Router has selected a new attachment router but has 698 not moved yet (because it is waiting for Tree Hop timer to 699 elapse), the Mobile Router is unstable and refrains from sending 700 Router Advertisement - Tree Information Options. 702 8. When A Mobile Router joins a tree, moves within its tree, or when 703 it receives a modified TIO from its current attachment router, 704 the Mobile Router sends an unsolicited Router Advertisement 705 message on all its mobile networks (i.e. all its ingress 706 interfaces). The RA contains a TIO that propagates the new tree 707 information. At the same time, the Mobile Router MAY send a 708 Binding Update to its home agent or a local proxy of some sort, 709 because the tree it is attached to has changed. If the Mobile 710 Router fails to reach its Home Agent, it MAY attempt to roll back 711 the movement or to retry the Home Agent discovery procedure. 713 9. This allows the new higher parts of the tree to take place first 714 eventually dragging their sub-tree with them, and allowing 715 stepped sub-tree reconfigurations, limiting relative movements. 717 5.1. tree selection 719 The tree selection is implementation and algorithm dependent. In 720 order to limit erratic movements, and all metrics being equal, Mobile 721 Routers SHOULD stick to their previous selection. Also, Mobile 722 Routers SHOULD provide a mean to filter out candidate Attachment 723 Routers whose availability is detected as fluctuating, at least when 724 more stable choices are available. For instance, the Mobile Router 725 MAY place the failed Attachment Router in a Hold Down mode that 726 ensures that the Attachment Router will not be reused for a given 727 period of time. 729 The known trees are associated with the Attachment Router that 730 advertises them and kept in a list by extending the Default Router 731 List. DRL entries are extended to store the information received 732 from the last TIO. These entries are managed by states and timers 733 described in the next section. 735 When connection to a fixed network is not possible or preferable for 736 security or other reasons, scattered trees should aggregate as much 737 as possible into larger trees in order to allow inner connectivity. 738 How to balance these trees is implementation dependent, and MAY use a 739 specific visitor-counter suboption in the TIO. 741 A Mobile Router SHOULD verify that bidirectional connectivity is 742 available with a candidate Attachment Router before it attaches to 743 that candidate. Some layer 2 such as 802.11 infrastructure mode will 744 provide for this, while others such as 802.11 adhoc mode will not. 745 If the layer 2 does not guarantee the bidirectional connectivity, 746 then the MR needs to make sure that it can reach the AR. This can be 747 achieved using Neighbor Sollicitation and refraining from attaching 748 to an AR for which no neighbor cache exists, or the state is still 749 INCOMPLETE. 751 5.2. Sub-tree mobility 753 It might be perceived as beneficial for a sub-tree to move as a 754 whole. The way it would work is for a Mobile Router to stay 755 clusterhead even if itself is attached into a parent tree. But the 756 loop avoidance is based on the knowledge of the tree that the Mobile 757 Router visit, preventing a Mobile Router to move down a same tree. 758 So without additional support, tree-level loops could form. 760 To avoid this, it is possible to add a path vector suboption to the 761 TIO that reflects the nesting of trees. If a root-Mobile Router 762 joins a parent tree, then it needs to add its treeID to the path 763 vector, but it can not join if the treeID is already listed. 765 A specific case is the root-Mobile Router of a tree that attaches to 766 a fixed Access Router. That root-Mobile Router might omit to 767 consider a TIO that comes from the new Attachment Router and decide 768 to stay root, in order to keep the tree consistency from the nested 769 Mobile Routers standpoint. This does not create loops, even if the 770 path vector is not present 772 5.3. Administrative depth 774 When the tree is formed under a common administration, or when a 775 Mobile Router performs a certain role within a community, it might be 776 beneficial to associate a range of acceptable depth with that MR. 777 For instance, a MR that has limited battery should be a leaf unless 778 there is no other choice, and thus expose an exagerated depth. On 779 the other hane, a MR that is designed for backhaul should operate in 780 a low range of depth. 782 With Tree Discovery, a MR has to expose a depth that is incremented 783 from its parent's depth as receive in the TIO. In particular, a MR 784 might expose a depth which is incremented by more than one from its 785 parent's depth, in order to fit in its own administrative range. So 786 a depth of N does not mean that there is precisely N Mobile Routers 787 on the way, but at most N. 789 5.4. DRL entries states and stability 791 Attachment routers in the DRL may or may not be usable for roaming 792 depending on runtime conditions. The following states are defined: 794 Current This Attachment Router is used for roaming 796 Candidate This Attachment Router can be used for roaming. 798 Held-Up This Attachment Router can not be used till tree hop timer 799 elapses. This does not occur for a fixed Attachment Router that 800 does not send a TIO since the tree delay is null in that case. 802 Held-Down This Attachment Router can not be used till hold down 803 timer elapses. At the end of the hold-down period, the router is 804 removed from the DRL, and will be reinserted if it appears again 805 with a RA. 807 Collision This Attachment Router can not be used till its next RA. 809 5.4.1. Held-Up 811 This state is managed by the tree Hop timer, it serves 2 purposes: 813 Delay the reattachment of a sub-tree that has been forced to 814 detach. This is not as safe as the use of the sequence but still 815 covers that when a sub-tree has detached, the Router Advertisement 816 - Tree Information Option that is initiated by the new clusterhead 817 has spread down the sub-tree so that two different trees have 818 formed. 820 Limit Router Advertisement - Tree Information Option storms when 821 two trees collide. The idea is that between the nodes from tree A 822 that wish to move to tree B, those that see the highest place in 823 tree B will move first and advertise their new locations before 824 other nodes from tree A actually move. 826 A new tree is discovered upon a router advertisement message with or 827 without a Router Advertisement - Tree Information Option. The Mobile 828 Router joins the tree by selecting the source of the RA message as 829 its attachment router (default gateway) and propagating the TIO 830 accordingly. 832 When a new tree is discovered, the candidate Attachment Router that 833 advertises the new tree is placed in a held up state for the duration 834 of a Tree Hop timer. If the new Attachment Router is more preferable 835 than the current one, the Mobile Router expects to jump and becomes 836 unstable. 838 A Mobile Router that is unstable may discover other Attachment 839 Routers from the same new tree during the instability phase. It 840 needs to start a new Tree Hop timer for all these. The first timer 841 that elapses for a given new tree clears them all for that tree, 842 allowing the Mobile Router to jump to the highest position available 843 in the new tree. 845 The duration of the Tree Hop timer depends on the tree delay of the 846 new tree and on the depth of Attachment Router that triggers it: 848 (AR's depth + random) * AR's tree_delay (where 0 <= random < 1). It 849 is randomized in order to limit collisions and synchronizations. 851 5.4.2. Held-Down 853 When a router is 'removed' from the Default Router List, it is 854 actually held down for a hold down timer period, in order to prevent 855 flapping. This happens when an Attachment Router disappears (upon 856 expiration timer), and when an Attachment Router is tried but can not 857 reach the Home Agent (upon expiration of another Attachment Router, 858 or upon tree hop for that Attachment Router). 860 An Attachment Router that is held down is not considered for the 861 purpose of roaming. When the hold down timer elapses, the Attachment 862 Router is removed from the DRL. 864 5.4.3. Collision 866 A race condition occurs if 2 Mobile Routers send Router Advertisement 867 - Tree Information Option at the same time and wish to join each 868 other. This might happen between routers at a same depth, or routers 869 which act as clusterhead of their own tree. In order to detect the 870 situation, Mobile Routers time stamp the sending of Router 871 Advertisement - Tree Information Option. Any Router Advertisement - 872 Tree Information Option received within a short media-dependant 873 period introduces a risk. To divide the risk, A 32bits extended 874 preference is added in the TIO. The first byte is the clusterhead 875 (tree) preference, the remaining 24 bits is a boot time computed 876 random. 878 A Mobile Router that decides to join an Attachment Router will do so 879 between (Attachment Router depth) and (Attachment Router depth + 1) 880 times the Attachment Router tree delay. But since a Mobile Router is 881 unstable as soon as it receives the Router Advertisement - Tree 882 Information Option from the preferred Attachment Router, it will 883 restrain from sending a Router Advertisement - Tree Information 884 Option between the time it receives the RA and the time it actually 885 jumps. So the crossing of RA may only happen during the propagation 886 time between the Attachment Router and the Mobile Router, plus some 887 internal queuing and processing time within each machine. It is 888 expected that one tree delay normally covers that interval, but 889 ultimately it is up to the implementation and the configuration of 890 the Attachment Router to define the duration of risk window. 892 There is risk of a collision when a Mobile Router receives an RA, for 893 an other mobile router that is more preferable than the current 894 Attachment Router, within the risk window. In the face of a 895 potential collision, the Mobile Router with the lowest extended 896 preference processes the Router Advertisement - Tree Information 897 Option normally, while the router with the highest preference places 898 the other in collision state, does not start the tree hop timer, and 899 does not become instable. It is expected that next RAs between the 900 two will not cross anyway. 902 5.4.4. Instability 904 A Mobile Router is instable when it is prepared to move shortly to 905 another Attachment Router. This happens typically when the Mobile 906 Router has selected a more preferred candidate Attachment Router and 907 has to wait for the tree hop timer to elapse before roaming. 908 Instability may also occur when the current Attachment Router is lost 909 and the next best is still held up. Instability is resolved when the 910 tree hop timer of all the Attachment Router (s) causing instability 911 elapse. Such Attachment Router is changes state to Current or Held- 912 Down. 914 Instability is transient (in the order of tree hop timers). When a 915 Mobile Router is unstable, it MUST NOT send RAs with TIO. This 916 avoids loops when Mobile Router A wishes to attach to Mobile Router B 917 and Mobile Router B wishes to attach to Mobile Router A. Unless RA 918 cross (see Collision section), a Mobile Router receives TIO from 919 stable Attachment Routers, which do not plan to attach to itself, so 920 the Mobile Router can safely attach to them. 922 5.4.5. Density 924 In a dense environment, it is useless that all routers that can 925 provide backhauling service actually do so; in practice, limiting the 926 number of routers that accept visitors saves memory in the visitors 927 and reduces the cost of signalling. Also, limiting the number of 928 nodes (mobile routers that is) in the tree improves the multicast 929 operations. 931 Algorithms such a Trickle could be used by a Mobile Router to decide 932 to stop providing its access services for visitors if there are a 933 number of neighboring routers that provide similar services. The 934 simplest abstraction of such similarity is that of multiple routers 935 advertising a same depth, though such a simple similarity does not 936 address the specifics of a router selection in the plugins. In a 937 more general fashion, a Mobile Router can associate the concept of 938 similarity with the characteristics of its own attachment router 939 selection plug in. 941 The Trickle algorithm must be tuned in such a fashion that the 942 susceptibility to stop advertising services is inversely proportional 943 to the number of nodes attached to the Mobile Router, and that the 944 susceptibility to restore services is also inversely proportional to 945 the time it has been suspending those services. Once a router 946 suspends its services, it should do so for a period of time that is 947 exponentially growing each time the decision is made again to keep 948 suspending thise services. That period is interrupted if a neighbor 949 is found that does not have a parent. 951 5.5. Legacy Routers 953 A legacy router sends its Router Advertisements without a TIO. 954 Consequently, a legacy router can be mistaken for a fixed Access 955 Router when it is placed within a nested NEMO structure, and defeat 956 the loop avoidance mechanism. Consequently, it is important for the 957 administrator to prevent address autoconfiguration by visiting Mobile 958 Routers from such a legacy router. 960 6. Directed Acyclic Graph Discovery 962 Tree Discovery builds trees, which are a specific form of a Directed 963 Acyclic Graph (DAG). In a more general Fashion, TD can be adapted to 964 form DAGs, oriented towards the clusterhead. This is DAG Discovery. 966 In Section 5.3, TD enables a given MR to expose a depth that is 967 incremented by more than one with regards to its parent. When it 968 does so, a MR can elect a number of alternate parents as feasible 969 successors. A feasible successor belongs to the same tree as the MR 970 parent, and has a depth that is less than that of the MR. 972 The links MR to feasible successors complete the tree as built by TD 973 into a DAG towards the clusterhead. The DAG enables alternate exit 974 paths for a multihomed Mobile Router. 976 7. IANA Considerations 978 Section 4.1. requires the definition of a new option to Neighbor 979 discovery [RFC4861] messages, the Router Advertisement - Tree 980 Information Option (RA-TIO). The Router Advertisement - Tree 981 Information Option has been assigned the value TBD within the 982 numbering space for IPv6 Neighbor Discovery Option Formats. 984 8. Security Considerations 986 At the current level of this draft, the TIO bears the security level 987 of the RA and the link. Nothing is added to it. A deeper threat 988 analysis would be required to eventually propose additional security. 990 9. Contributors 992 The editor recognizes the contributions by: 994 Caroline Bontoux from Fortinet, 996 Nicolas Montavont from Univerity Louis Pasteur, 998 Ben McCarthy from Lancaster University, 1000 Patrick Wetterwald and JP Vasseur from Cisco. 1002 10. Acknowledgments 1004 The editor wishes to thank Marco Molteni for his early participation 1005 to this design and the review of the document, Massimo Villari for 1006 his early work on simulation and research on the subject and Julien 1007 Abeille for his advanced participation in simulation and real 1008 testing. Also the authors wish to thank Christopher Dearlove for his 1009 suggestion for additional protection against loops in TD, and Philip 1010 Levis, David Cueller and Jonathan Hui for the suggestions about 1011 Trickle. This work is also based on prior publications, in 1012 particular HMRA [I-D.cho-nemo-hmra] by Hosik Cho and Eun-Kyoung Paik 1013 from Seoul National University and other non IETF publications 1014 coauthored with Thierry Ernst and Thomas Noel. Finally, the editor 1015 heartily thanks Marcelo Bagnulo Braun and Teco Boot for their very 1016 constructive reviews. 1018 11. References 1020 11.1. Normative Reference 1022 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1023 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1024 September 2007. 1026 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1027 in IPv6", RFC 3775, June 2004. 1029 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1030 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1031 RFC 3963, January 2005. 1033 [I-D.ietf-nemo-terminology] 1034 Ernst, T. and H. Lach, "Network Mobility Support 1035 Terminology", draft-ietf-nemo-terminology-06 (work in 1036 progress), November 2006. 1038 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1039 More-Specific Routes", RFC 4191, November 2005. 1041 11.2. Informative Reference 1043 [I-D.cho-nemo-hmra] 1044 Cho, H., "Hierarchical Mobile Router Advertisement for 1045 nested mobile networks", draft-cho-nemo-hmra-00 (work in 1046 progress), January 2004. 1048 [I-D.ietf-nemo-multihoming-issues] 1049 Ng, C., "Analysis of Multihoming in Network Mobility 1050 Support", draft-ietf-nemo-multihoming-issues-07 (work in 1051 progress), February 2007. 1053 [I-D.thubert-nemo-reverse-routing-header] 1054 Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header 1055 and its application to Mobile Networks", 1056 draft-thubert-nemo-reverse-routing-header-07 (work in 1057 progress), February 2007. 1059 Author's Address 1061 Pascal Thubert (editor) 1062 Cisco Systems 1063 Village d'Entreprises Green Side 1064 400, Avenue de Roumanille 1065 Batiment T3 1066 Biot - Sophia Antipolis 06410 1067 FRANCE 1069 Phone: +33 497 23 26 34 1070 Email: pthubert@cisco.com