idnits 2.17.00 (12 Aug 2021) /tmp/idnits36363/draft-thubert-tree-discovery-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1099. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1110. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1117. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1123. 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 ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 385: '...following values MUST not change durin...' RFC 2119 keyword, line 408: '... receiver MUST silently ignore an...' RFC 2119 keyword, line 421: '... Implementations MUST silently ignore ...' RFC 2119 keyword, line 469: '... MUST be ignored by the receiver....' RFC 2119 keyword, line 650: '...e Mobile Routers MUST obey to the foll...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2007) is 5436 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 2461 (ref. '1') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '4') == Outdated reference: draft-ietf-nemo-multihoming-issues has been published as RFC 4980 Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NEMO Working Group P. Thubert 3 Internet-Draft Cisco 4 Expires: January 4, 2008 C. Bontoux 5 Fortinet 6 N. Montavont 7 LSIIT - ULP 8 July 3, 2007 10 Nested Nemo Tree Discovery 11 draft-thubert-tree-discovery-06.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 4, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This paper describes a simple distance vector protocol that exposes 45 only a default route towards the infrastructure in a nested NEMO 46 configuration. The draft extends the Neighbor Discovery Protocol [1] 47 in order to carry information and metrics which will help a Mobile 48 Router select its Attachment Router(s) in an autonomous fashion and 49 provides generic rules which guarantee that the interaction of 50 different selection processes will not create loops. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 58 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Multi-Homed nested mobile network . . . . . . . . . . . . 5 60 3.2. Loops in nested Nemo . . . . . . . . . . . . . . . . . . . 6 62 4. Tree Information Option . . . . . . . . . . . . . . . . . . . 8 63 4.1. TIO base option . . . . . . . . . . . . . . . . . . . . . 8 64 4.2. TIO suboptions . . . . . . . . . . . . . . . . . . . . . . 11 65 4.2.1. Format . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.2.2. Pad1 . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 4.2.3. PadN . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.2.4. Bandwidth Suboption . . . . . . . . . . . . . . . . . 12 69 4.2.5. Stable time Suboption . . . . . . . . . . . . . . . . 13 70 4.2.6. Tree Group ID Suboption . . . . . . . . . . . . . . . 14 71 4.2.7. Path Free Medium Time Suboption . . . . . . . . . . . 14 72 4.2.8. Uniform Path Metric Suboption . . . . . . . . . . . . 15 74 5. Tree Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17 75 5.1. tree selection . . . . . . . . . . . . . . . . . . . . . . 18 76 5.2. Sub-tree mobility . . . . . . . . . . . . . . . . . . . . 19 77 5.3. Administrative depth . . . . . . . . . . . . . . . . . . . 20 78 5.4. DRL entries states and stability . . . . . . . . . . . . . 20 79 5.4.1. Held-Up . . . . . . . . . . . . . . . . . . . . . . . 20 80 5.4.2. Held-Down . . . . . . . . . . . . . . . . . . . . . . 21 81 5.4.3. Collision . . . . . . . . . . . . . . . . . . . . . . 21 82 5.4.4. Instability . . . . . . . . . . . . . . . . . . . . . 22 83 5.5. Legacy Routers . . . . . . . . . . . . . . . . . . . . . . 23 85 6. Directed Acyclic Graph Discovery . . . . . . . . . . . . . . . 23 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 91 9. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 92 9.1. Changes from version 00 to 01 . . . . . . . . . . . . . . 24 93 9.2. Changes from version 01 to 02 . . . . . . . . . . . . . . 24 94 9.3. Changes from version 02 to 03 . . . . . . . . . . . . . . 24 95 9.4. Changes from version 03 to 04 . . . . . . . . . . . . . . 24 96 9.5. Changes from version 04 to 05 . . . . . . . . . . . . . . 24 97 9.6. Changes from version 05 to 06 . . . . . . . . . . . . . . 24 99 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 102 11.1. Normative Reference . . . . . . . . . . . . . . . . . . . 26 103 11.2. Informative Reference . . . . . . . . . . . . . . . . . . 26 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 106 Intellectual Property and Copyright Statements . . . . . . . . . . 28 108 1. Introduction 110 As per Nemo Basic support [3], a Mobile Router autoconfigures a 111 single Care of Address (CoA) to register to its Home Agent and 112 terminate its Mobile Router-Home Agent tunnel. That Care of Address 113 is the Mobile Router point of attachment to the nested Nemo. 115 Consequently, if loops are avoided, the nested Nemo assumes the shape 116 of a tree. The nodes of the tree are Mobile Routers, the root is 117 either a fixed or a Mobile Router, called in the latter case the root 118 Mobile Router in NEMO terminology [4]. The leaves are mobile or 119 fixed hosts, called Local Fixed Nodes, Local Mobile Nodes and 120 Visiting Mobile Nodes in the NEMO terminology. 122 This paper provides (1) a minimum extension to IPv6 Neighbor 123 Discovery Router Advertisements in order to ensure that Mobile 124 Routers attaching to one another actually avoid loops and end up 125 forming a tree, and (2) the minimum common part of all Mobile Router 126 algorithms that is required to ensure that whatever their specific 127 decisions, loops between Mobile Routers will be avoided. 129 The method is based on an autonomous decision by each Mobile Router 130 with no global state convergence such as a MANET proactive routing 131 protocol. In fact, Mobile Routers may make different decisions from 132 a same input, based on their own configuration and their own 133 algorithms. 135 In order to build trees of Mobile Routers, we propose an extension to 136 the ICMP Router Advertisement (RA) message, the Tree Information 137 Option (TIO). The TIO allows Mobile Routers to advertise the tree 138 they belong to, and to select and move to the best location within 139 the available trees. Mobile Routers propagate the TIO in RA down the 140 tree, updating some metrics such as the tree depth, leaving alone 141 root information such as the tree identifier, and sending the result 142 in RAs over the ingress interfaces. 144 2. Terms and Abbreviations 146 This document assumes that the reader is familiar with Mobile IPv6 as 147 defined in [2] and with the concept of Mobile Router defined in the 148 Nemo terminology document [4]. 150 For the needs of this paper, the following new definitions are 151 introduced: 153 Nemo clusterhead: The root of a tree of mobile routers. When the 154 tree of Mobile Routers is attached to the infrastructure, the 155 fixed Access Router may act as cluster head if it supports the 156 Tree Information Option described in this document. If it does 157 not, then the clusterhead coincides with the root Mobile Router in 158 NEMO terminology. A clusterhead is elected even when the tree is 159 not attached to the infrastructure. A stand-alone Mobile Router 160 is a clusterhead. 162 Floating Tree: A Nested Nemo which clusterhead is a Mobile Router 163 that is not attached to an Access Router. 165 Grounded Tree: A Nested Nemo whose clusterhead is attached to the 166 infrastructure. In other words, the clusterhead is either a fixed 167 router that supports Router Advertisement - Tree Information 168 Option or is a Mobile Router which attachment router is a fixed 169 router that does not support Router Advertisement - Tree 170 Information Option. 172 Mobile Access Router: A Mobile Router that provides Access Router 173 services to other Mobile Routers. 175 Attachment Router: The Router that is selected as Access Router by a 176 Mobile Router, making it its parent in the nested NEMO tree. 178 Propagation: The action by a Mobile Router that consists in 179 receiving a Router Advertisement Tree Information Option from its 180 Attachment Router, recomputing a few specific fields, removing 181 unknown suboptions, and appending the resulting TIO to RAs sent 182 over the ingress interfaces. 184 Uniform Path Metric: A multihop metric that can be used by Tree 185 Discovery plug-ins to select feasible successors and specifically 186 an Attachment Router. 188 3. Motivations 190 3.1. Multi-Homed nested mobile network 192 A nested mobile network that is made of multiple Mobile Routers 193 having a direct connection to the Internet is said to be multi-homed. 194 Multihoming in Nemo offers useful properties to Mobile Network Nodes. 195 The NEMO multihoming issues [7] draft lists potential multi-homed 196 configurations for Nemo and explains the different problems and 197 advantages that some configurations may introduce. Multihoming 198 offers three main abilities to the Nemo: it allows route recovery on 199 failure, redundancy and load-sharing between Mobile Routers (or 200 between interfaces of a given Mobile Router). However, for the 201 moment, there is no requirements nor protocol that would define in 202 interaction between several egress interfaces inside a Nemo. 204 In a nested Nemo, the hierarchy of Mobile Routers increases the 205 complexity of the route and/or router selection for Mobile Network 206 Nodes. Each level of a Nemo implies the usage of a new tunnel 207 between the Mobile Router and its home agent. Thus if a Mobile 208 Network Node connects to a sub-Nemo which is also a sub-Nemo, packets 209 from the Mobile Network Node will be encapsulated three times. 211 When the Nemo where the MN is connected to is multi-homed, the MN may 212 have the choice between several Attachment Router to be its default 213 router. Reference [5] introduces new options in Router Advertisement 214 to allow any node on a link to choose between several routers. This 215 option mainly consists of a 2-bits flag that indicates the preference 216 of the router (low, medium or high). Furthermore, the same flag can 217 be set in the Route Information option indicating the preference of a 218 specific prefix. Therefore, any node can determine its best default 219 router(s) according to a given destination and its best router for 220 default, which will be used by default. 222 However this preference is only useful in a flat topology; It gives a 223 way to the node to choose between different attachment routers 224 advertising prefixes on the node link. But if the node is inside a 225 hierarchical topology the node can not learn the depth of each 226 attachment router, and might not select the most efficient path. In 227 particular, there is a need for Uniform Path Metric that accounts for 228 a multihop wireless path. 230 One of the usage of the new option introduced in this document is to 231 distribute information on the hierarchy of Mobile Routers. This 232 information can be distributed to Attachment Routers, Mobile Routers 233 and Mobile Network Nodes as well in order to allow better route 234 selection and to increase the knowledge of the Nemo topology on each 235 node. 237 3.2. Loops in nested Nemo 239 When several Mobile Routers attach to each other to form a nested 240 Nemo, loops can be created if they are not explicitly avoided. In 241 the simplest case, when egress and ingress interfaces of A Mobile 242 Router are all wireless, a mobile router may be listening to Router 243 Advertisement from its own ingress interface, creating a confliction 244 problem. In the general case, arbitrary attachment of Mobile Routers 245 will form graphs that are not exempt of loops. For instance: Assume 246 a nested Nemo where Mobile Router1 is connected to the 247 infrastructure, and Mobile Router3 is attached to Mobile Router2. 249 Say that Mobile Router2 can hear both Mobile Router3 and Mobile 250 Router1 over its wireless egress interface. If Mobile Router2 select 251 Mobile Router1, the connectivity to the infrastructure is provided 252 for all. But if Mobile Router2 selects Mobile Router3, Mobile 253 Router2 and Mobile Router3 end up forming a loop and are disconnected 254 from their Home Agents. 256 With Nemo basic support, a Mobile Router uses a single primary Care 257 Of Address to attach to the nested structure. As a result, if loops 258 are avoided, the nested NEMO end up forming a tree. It is beneficial 259 to be able to form that tree in an optimum fashion for a given set of 260 metrics such as tree depth. 262 The shape of a nested Nemo may change rapidly due to Mobile Routers 263 movement. It is thus impractical to expect each Mobile Router to be 264 able to maintain states about the whole tree structure in a link 265 state fashion. On the contrary, it is also beneficial to allow each 266 Mobile Router to make its own independent selection based on a 267 minimum information about its immediate neighbors, in order to 268 reestablish the tree quickly upon erratic movements. 270 Each Mobile Router should be able to make its own attachment router 271 selection based on its own condition (eg battery level), its own set 272 of constraints that may not apply to other Mobile Routers in the 273 tree, and in general its own algorithm. As a result, the 274 standardization effort should concentrate on a common minimum set of 275 rules that must be common to all Mobile Routers in order to prevent 276 routing loops in the nested NEMO while leaving Mobile Routers 277 independent in their Attachment Router selection algorithms. 279 4. Tree Information Option 281 The Tree Information Option carries a number of metrics and other 282 information that allows a Mobile Router to discover a tree and select 283 its point of attachment while avoiding loop generation. 285 4.1. TIO base option 287 The Tree Information Option is a container option, which might 288 contain a number of suboptions. The base option regroups the minimum 289 information set that is mandatory in all cases. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Type | Length |G|H|B| Reserved| Sequence | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | TreePref. | BootTimeRandom | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | MR Preference | TreeDepth | TreeDelay | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | PathDigest | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | | 303 + + 304 | TreeID | 305 + + 306 | | 307 + + 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | sub-option(s)... 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Figure 1: TIO base option 315 Type: 8-bit unsigned integer set to 10 by the clusterhead. Value is 316 "TBD". 318 Length: 8-bit unsigned integer set to 4 when there is no suboption. 319 The length of the option (including the type and length fields and 320 the suboptions) in units of 8 octets. 322 Grounded (G): The Grounded (G) flag is set when the clusterhead is 323 attached to a fixed network infrastructure (such as the Internet). 325 Home (H): The Home (H) flag is set when the Mobile Router is bound 326 to its home network over NEMO. With NEMO Basic Support,a MR that 327 is not bound Home cuts off its visitors from the Internet as well. 328 This can be solved by techniques such as Reverse Routing Header 329 [8]. 331 Battery (B): The Battery (B) flag is indicates that a parent in the 332 tree operates on batteries, an indication of a costly operation. 333 It is set by a mobile router which operates on battery and when 334 set, it is left set as it is propagated down the tree. 336 Reserved: 5-bit unsigned integer set to 0 by the clusterhead. 338 Sequence Number: 8-bit unsigned integer set by the clusterhead and 339 incremented with each new TIO it sends on a link and propagated 340 with no change down the tree. 342 TreePreference: 8-bit unsigned integer set by the clusterhead to its 343 preference and unchanged at propagation. Default is 0 (lowest 344 preference). The tree preference provides a mechanism to engineer 345 the mesh of mobile routers, for instance indicating the most 346 preferred home gateway or the communication ship in a fleet at 347 sea. 349 BootTimeRandom: A random value computed at boot time and recomputed 350 in case of a duplication with another Attachment Router. The 351 concatenation of the Preference and the BootTimeRandom is a 32-bit 352 extended preference that is used to resolve collisions. It is set 353 by each Mobile Router at propagation time. 355 Preference: The administrative preference of that (mobile) Access 356 Router. Default is 0. 255 is the highest possible preference. 357 Set by each Mobile Router at propagation time. 359 TreeDepth: 8-bit unsigned integer. The tree depth of the 360 clusterhead is 0 if it is a fixed router and 1 if it is a Mobile 361 Router. The tree Depth of a tree Node is the depth of its 362 attachment router as received in a TIO, incremented by at least 363 one. All nodes in the tree advertise their tree depth in the Tree 364 Information Options that they append to the RA messages over their 365 ingress interfaces as part of the propagation process. 367 TreeDelay: 16-bit unsigned integer set by the clusterhead indicating 368 the delay before changing the tree configuration, in milliseconds. 369 A default value is 128ms. It is expected to be an order of 370 magnitude smaller than the RA-interval so if the clusterhead has a 371 sub-second RA-interval, the Tree delay may be shorter than 100ms. 372 It is also expected to be an order of magnitude longer than the 373 typical propagation delay inside the nested Nemo. 375 PathDigest: 32-bit unsigned integer CRC, updated by each Mobile 376 Router. This is the result of a CRC-32c computation on a bit 377 string obtained by appending the received value and the Mobile 378 Router Care of Address. clusterheads use a 'previous value' of 379 zeroes to initially set the PathDigest. 381 TreeID: 128-bit unsigned integer which uniquely identify a tree. 382 This value is set by the clusterhead. The global IPv6 home 383 address of the clusterhead can be used. 385 The following values MUST not change during the propagation of the 386 TIO down the tree: Type, Length, G, H, TreePreference, TreeDelay and 387 TreeID. All other fields of the TIO are updated at each hop of the 388 propagation. 390 4.2. TIO suboptions 392 In addition to the minimum options presented in the base option, a 393 number of suboptions are defined for the TIO: 395 4.2.1. Format 397 0 1 2 3 398 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 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Subopt. Type | Subopt Length | Suboption Data... 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Figure 2: TIO suboption generic format 405 Suboption Type: 8-bit identifier of the type of mobility option. 406 When processing a TIO containing a suboption for which the 407 suboption Type value is not recognized by the receiver, the 408 receiver MUST silently ignore and skip over the suboption, 409 correctly handling any remaining options in the message. 411 Suboption Length: 8-bit unsigned integer, representing the length in 412 octets of the suboption, not including the suboption Type and 413 Length fields. 415 Suboption Data: A variable length field that contains data specific 416 to the option. 418 The following subsections specify the TIO suboptions which are 419 currently defined for use in the Mobility Header. 421 Implementations MUST silently ignore any TIO suboptions options that 422 they do not understand. 424 TIO suboptions may have alignment requirements. Following the 425 convention in IPv6, these options are aligned in a packet so that 426 multi-octet values within the Option Data field of each option fall 427 on natural boundaries (i.e., fields of width n octets are placed at 428 an integer multiple of n octets from the start of the header, for n = 429 1, 2, 4, or 8). 431 4.2.2. Pad1 433 The Pad1 suboption does not have any alignment requirements. Its 434 format is as follows: 436 0 437 0 1 2 3 4 5 6 7 438 +-+-+-+-+-+-+-+-+ 439 | Type = 0 | 440 +-+-+-+-+-+-+-+-+ 442 Figure 3: Pad 1 444 NOTE! the format of the Pad1 option is a special case - it has 445 neither Option Length nor Option Data fields. 447 The Pad1 option is used to insert one octet of padding in the TIO to 448 enable suboptions alignment. If more than one octet of padding is 449 required, the PadN option, described next, should be used rather than 450 multiple Pad1 options. 452 4.2.3. PadN 454 The PadN option does not have any alignment requirements. Its format 455 is as follows: 457 0 1 458 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 460 | Type = 1 | Subopt Length | Subopt Data 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 463 Figure 4: Pad N 465 The PadN option is used to insert two or more octets of padding in 466 the TIO to enable suboptions alignment. For N (N > 1) octets of 467 padding, the Option Length field contains the value N-2, and the 468 Option Data consists of N-2 zero-valued octets. PadN Option data 469 MUST be ignored by the receiver. 471 4.2.4. Bandwidth Suboption 473 This suboption carries the maximum bandwidth available up the tree 474 via a specific parent. It is the lowest speed of the links on the 475 way and does not reflect the actual use of those links in run time. 476 The value is expressed in the log base 2 of the speed, expressed in 477 bps. The Bandwidth suboption does not have any alignment 478 requirements. Its format is as follows: 480 0 1 2 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 483 | Type = 2 | Length = 1 | Bandwidth | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 486 Figure 5: Bandwidth Suboption 488 Type: Set to 2 for the Bandwidth suboption. 490 Length: Set to 1 for the Bandwidth suboption. 492 Bandwidth: 8-bit unsigned integer. The Log2 of the speed of the 493 path expressed in bps. The clusterhead initializes that field 494 using the speed of the link to the Access Router to which it is 495 attached or 0xFF if it is floating. An attached MR propagates it 496 as the minimum of the Bandwidth as received in the TIO from the 497 parent and the access speed between the MR and the parent. As a 498 result, the value received from a candidate AR is that of the 499 bottleneck between that AR and the wire access. 501 4.2.5. Stable time Suboption 503 This suboption carries an indicator of the stability of a network. 504 This indicator is the time since the branch to which the MR is 505 attached has remained unchanged. The value is expressed in the log 506 base 2 of that duration, expressed in milliseconds. The Stable time 507 suboption does not have any alignment requirements. Its format is as 508 follows: 510 0 1 2 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 513 | Type = 3 | Length = 1 | Stable time | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 516 Figure 6: Stable time 518 Type: Set to 3 for the Stable time suboption. 520 Length: Set to 1 for the Stable time suboption. 522 Stable time: 8-bit unsigned integer. The Log2 of the time since the 523 last change in the attachment branch, expressed in milliseconds. 524 This is set by the MR as it propagates the TIO down the tree, 525 indicating for how long the PathDigest in the TIO from its parent 526 has remained unchanged. 528 4.2.6. Tree Group ID Suboption 530 This suboption carries the Group ID for the tree. It is set by the 531 clusterhead and is left unchanged by the MR that propagates the TIO 532 down the tree. The Tree Group ID Suboption has an alignment 533 requirement of 8n+6. Its format is as follows: 535 0 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Type = 4 | Length = 16 | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | | 541 + + 542 | Tree | 543 + Group ID + 544 | | 545 + + 546 | | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Figure 7: Tree Group ID Suboption 551 Type: 8-bit unsigned integer. Its value is 4 for the Tree Group ID 552 suboption. 554 Length: 8-bit unsigned integer. Its value is 16 for the Tree Group 555 ID suboption. 557 Tree Group ID: 128-bit unsigned integer which identify a group for a 558 tree. This value is set by the clusterhead. It can be set 559 administratively, for instance to an IPv6 multicast group. 561 4.2.7. Path Free Medium Time Suboption 563 This suboption carries the Free Medium Time available up the tree via 564 a specific parent at a given point of time. It is an indication of 565 whether bandwidth is available to place VoIP calls for instance. As 566 defined by the Quality of Service (QoS) Task Group of the Wi-Fi 567 Alliance, the Medium Time describes the amount of time admitted to 568 access the medium, in units of 32 microsecond periods per second. 570 The Free Medium Time is the amount of time left the medium, in other 571 words ((1000000/32) - SIGMA(MT)). The Path Free Medium Time is the 572 lowest available Free Medium Time along the way and it reflects the 573 actual use of those links in run time. 575 The Path Free Medium Time suboption does not have any alignment 576 requirements. Its format is as follows: 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Type = 5 | Length = 2 | Path Free Medium Time | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 Figure 8: Path Free Medium Time Suboption 586 Type: Set to 5 for the Path Free Medium Time Suboption. 588 Length: Set to 2 for the Path Free Medium Time Suboption. 590 Path Free MT: 16-bit unsigned integer. The amount of Medium Time 591 that is available along the path to the clusterhead in units of 32 592 microsecond periods per second. The clusterhead initializes that 593 field to the Free MT on the link where the TIO is issued. An 594 attached MR propagates it as the minimum of the Path Free MT as 595 received in the TIO from the parent and the Path Free MT on the 596 link on which the TIO is propagated. As a result, the value 597 received from a candidate AR is that of the bottleneck between 598 that AR and the clusterhead. 600 4.2.8. Uniform Path Metric Suboption 602 This suboption carries the Uniform Path Metric for the path along the 603 tree. It is set to zero by the clusterhead and incremented as the 604 TIO is propagated down the tree. The Uniform Path Metric Suboption 605 has an alignment requirement of 4n+2. Its format is as follows: 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Type = 6 | Length = 4 | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Uniform Path Metric | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Figure 9: Uniform Path Metric Suboption 617 Type: 8-bit unsigned integer. Its value is 6 for the Uniform Path 618 Metric. 620 Length: 8-bit unsigned integer. Its value is 4 for the Uniform Path 621 Metric suboption. 623 Uniform Path Metric: 32-bit unsigned integer aggragating the cost of 624 multiple radio hops. 626 5. Tree Discovery 628 Tree Discovery is a form of distance vector protocol for use in 629 wireless mesh networks. TD locates the nearest exit and forms a 630 Directed Acyclic Graphs towards that exit, usually a tree. TD 631 enables Mobile Routers to implement different policies for selecting 632 their preferred parent in the Tree by introducing the concept of 633 plug-in, and does not specify the plug-in operation. Rather, TD 634 specifies a set of rules to be implemented by all plug-ins to ensure 635 interoperation. TD also standardizes the format that is used to 636 advertize the most common information that is used by the plug-ins in 637 order to perform the parent selection. 639 One of these information, the tree depth, is used by Tree Discovery 640 to provide loop avoidance between plug-ins even if they implement 641 different policies, and even if these policies do not use the depth 642 as a routing metric. For instance, a MR might use the Uniform Path 643 Metric to select the nearest exit and the best parent from the 644 standpoint of that metric. Once attached to that parent, the MR 645 exposes a depth which is incremented from the parent's depth, and 646 that depth provides a comparable basis with routers which would not 647 use UPM at all. 649 In order organize and maintain loopless structure, the selection 650 plug-ins in the Mobile Routers MUST obey to the following rules and 651 definitions: 653 1. A Mobile Router that is not attached to an Attachment Router is 654 the Nemo clusterhead of its own floating tree. It's depth is 1. 655 A Mobile Router will end up in that situation when it looses its 656 current parent and there is no alternate parent that it can 657 attach to. In that case, the MR remembers the treeID and the 658 sequence counter in the TIO of the lost parent for a period of 659 time which covers multiple TIO. 661 2. A Mobile Router that is attached to an Attachment Router that 662 does not support TIO, is the clusterhead of its own grounded 663 tree. It's depth is 1. 665 3. A router sending a RA without TIO is considered a grounded 666 Attachment Router at depth 0. 668 4. The Nemo clusterhead of a tree exposes the tree in the Router 669 Advertisement Tree Information Option and Mobile Routers 670 propagate the TIO down the tree with the RAs that they forward 671 over their ingress links. 673 5. A Mobile Router that is already part of a tree MAY move at any 674 time and with no delay in order to get closer to the clusterhead 675 of its current tree - i.e. in order to reduce its own tree depth. 676 But A Mobile Router MUST NOT move down the tree that it is 677 attached to. Mobile Routers MUST ignore RAs that are received 678 from other routers located deeper within the same tree. 680 6. A Mobile Router may move from its current tree into any different 681 tree at any time and whatever the depth it reaches in the new 682 tree, but it may have to wait for a Tree Hop timer to elapse in 683 order to do so. If the MR was clusterhead of its own floating 684 tree, it may not join its previous tree (identified by the last 685 parent treeID) unless the sequence number is the TIO was 686 incrememented since the MR left that tree, indicating that the 687 candidate parent was not attached behind this MR and kept getting 688 subsequent TIOs from the same tree. The Mobile Router will join 689 that other tree if it is more preferable for reasons of 690 connectivity, configured preference, free Medium Time, size, 691 security, bandwidth, tree depth, or whatever metrics the Mobile 692 Router cares to use. 694 7. If a Mobile Router has selected a new attachment router but has 695 not moved yet (because it is waiting for Tree Hop timer to 696 elapse), the Mobile Router is unstable and refrains from sending 697 Router Advertisement - Tree Information Options. 699 8. When A Mobile Router joins a tree, moves within its tree, or when 700 it receives a modified TIO from its current attachment router, 701 the Mobile Router sends an unsolicited Router Advertisement 702 message on all its mobile networks (i.e. all its ingress 703 interfaces). The RA contains a TIO that propagates the new tree 704 information. At the same time, the Mobile Router MAY send a 705 Binding Update to its home agent or a local proxy of some sort, 706 because the tree it is attached to has changed. If the Mobile 707 Router fails to reach its Home Agent, it MAY attempt to roll back 708 the movement or to retry the Home Agent discovery procedure. 710 9. This allows the new higher parts of the tree to take place first 711 eventually dragging their sub-tree with them, and allowing 712 stepped sub-tree reconfigurations, limiting relative movements. 714 5.1. tree selection 716 The tree selection is implementation and algorithm dependent. In 717 order to limit erratic movements, and all metrics being equal, Mobile 718 Routers SHOULD stick to their previous selection. Also, Mobile 719 Routers SHOULD provide a mean to filter out candidate Attachment 720 Routers whose availability is detected as fluctuating, at least when 721 more stable choices are available. For instance, the Mobile Router 722 MAY place the failed Attachment Router in a Hold Down mode that 723 ensures that the Attachment Router will not be reused for a given 724 period of time. 726 The known trees are associated with the Attachment Router that 727 advertises them and kept in a list by extending the Default Router 728 List. DRL entries are extended to store the information received 729 from the last TIO. These entries are managed by states and timers 730 described in the next section. 732 When connection to a fixed network is not possible or preferable for 733 security or other reasons, scattered trees should aggregate as much 734 as possible into larger trees in order to allow inner connectivity. 735 How to balance these trees is implementation dependent, and MAY use a 736 specific visitor-counter suboption in the TIO. 738 A Mobile Router SHOULD verify that bidirectional connectivity is 739 available with a candidate Attachment Router before it attaches to 740 that candidate. Some layer 2 such as 802.11 infrastructure mode will 741 provide for this, while others such as 802.11 adhoc mode will not. 742 If the layer 2 does not guarantee the bidirectional connectivity, 743 then the MR needs to make sure that it can reach the AR. This can be 744 achieved using Neighbor Sollicitation and refraining from attaching 745 to an AR for which no neighbor cache exists, or the state is still 746 INCOMPLETE. 748 5.2. Sub-tree mobility 750 It might be perceived as beneficial for a sub-tree to move as a 751 whole. The way it would work is for a Mobile Router to stay 752 clusterhead even if itself is attached into a parent tree. But the 753 loop avoidance is based on the knowledge of the tree that the Mobile 754 Router visit, preventing a Mobile Router to move down a same tree. 755 So without additional support, tree-level loops could form. 757 To avoid this, it is possible to add a path vector suboption to the 758 TIO that reflects the nesting of trees. If a root-Mobile Router 759 joins a parent tree, then it needs to add its treeID to the path 760 vector, but it can not join if the treeID is already listed. 762 A specific case is the root-Mobile Router of a tree that attaches to 763 a fixed Access Router. That root-Mobile Router might omit to 764 consider a TIO that comes from the new Attachment Router and decide 765 to stay root, in order to keep the tree consistency from the nested 766 Mobile Routers standpoint. This does not create loops, even if the 767 path vector is not present 769 5.3. Administrative depth 771 When the tree is formed under a common administration, or when a 772 Mobile Router performs a certain role within a community, it might be 773 beneficial to associate a range of acceptable depth with that MR. 774 For instance, a MR that has limited battery should be a leaf unless 775 there is no other choice, and thus expose an exagerated depth. On 776 the other hane, a MR that is designed for backhaul should operate in 777 a low range of depth. 779 With Tree Discovery, a MR has to expose a depth that is incremented 780 from its parent's depth as receive in the TIO. In particular, a MR 781 might expose a depth which is incremented by more than one from its 782 parent's depth, in order to fit in its own administrative range. So 783 a depth of N does not mean that there is precisely N Mobile Routers 784 on the way, but at most N. 786 5.4. DRL entries states and stability 788 Attachment routers in the DRL may or may not be usable for roaming 789 depending on runtime conditions. The following states are defined: 791 Current This Attachment Router is used for roaming 793 Candidate This Attachment Router can be used for roaming. 795 Held-Up This Attachment Router can not be used till tree hop timer 796 elapses. This does not occur for a fixed Attachment Router that 797 does not send a TIO since the tree delay is null in that case. 799 Held-Down This Attachment Router can not be used till hold down 800 timer elapses. At the end of the hold-down period, the router is 801 removed from the DRL, and will be reinserted if it appears again 802 with a RA. 804 Collision This Attachment Router can not be used till its next RA. 806 5.4.1. Held-Up 808 This state is managed by the tree Hop timer, it serves 2 purposes: 810 Delay the reattachment of a sub-tree that has been forced to 811 detach. This allows to make sure that when a sub-tree has 812 detached, the Router Advertisement - Tree Information Option that 813 is initiated by the new clusterhead has spread down the sub-tree 814 so that two different trees have formed. 816 Limit Router Advertisement - Tree Information Option storms when 817 two trees collide. The idea is that between the nodes from tree A 818 that wish to move to tree B, those that see the highest place in 819 tree B will move first and advertise their new locations before 820 other nodes from tree A actually move. 822 A new tree is discovered upon a router advertisement message with or 823 without a Router Advertisement - Tree Information Option. The Mobile 824 Router joins the tree by selecting the source of the RA message as 825 its attachment router (default gateway) and propagating the TIO 826 accordingly. 828 When a new tree is discovered, the candidate Attachment Router that 829 advertises the new tree is placed in a held up state for the duration 830 of a Tree Hop timer. If the new Attachment Router is more preferable 831 than the current one, the Mobile Router expects to jump and becomes 832 unstable. 834 A Mobile Router that is unstable may discover other Attachment 835 Routers from the same new tree during the instability phase. It 836 needs to start a new Tree Hop timer for all these. The first timer 837 that elapses for a given new tree clears them all for that tree, 838 allowing the Mobile Router to jump to the highest position available 839 in the new tree. 841 The duration of the Tree Hop timer depends on the tree delay of the 842 new tree and on the depth of Attachment Router that triggers it: 844 (AR's depth + random) * AR's tree_delay (where 0 <= random < 1). It 845 is randomized in order to limit collisions and synchronizations. 847 5.4.2. Held-Down 849 When a router is 'removed' from the Default Router List, it is 850 actually held down for a hold down timer period, in order to prevent 851 flapping. This happens when an Attachment Router disappears (upon 852 expiration timer), and when an Attachment Router is tried but can not 853 reach the Home Agent (upon expiration of another Attachment Router, 854 or upon tree hop for that Attachment Router). 856 An Attachment Router that is held down is not considered for the 857 purpose of roaming. When the hold down timer elapses, the Attachment 858 Router is removed from the DRL. 860 5.4.3. Collision 862 A race condition occurs if 2 Mobile Routers send Router Advertisement 863 - Tree Information Option at the same time and wish to join each 864 other. This might happen between routers at a same depth, or routers 865 which act as clusterhead of their own tree. In order to detect the 866 situation, Mobile Routers time stamp the sending of Router 867 Advertisement - Tree Information Option. Any Router Advertisement - 868 Tree Information Option received within a short media-dependant 869 period introduces a risk. To divide the risk, A 32bits extended 870 preference is added in the TIO. The first byte is the clusterhead 871 (tree) preference, the remaining 24 bits is a boot time computed 872 random. 874 A Mobile Router that decides to join an Attachment Router will do so 875 between (Attachment Router depth) and (Attachment Router depth + 1) 876 times the Attachment Router tree delay. But since a Mobile Router is 877 unstable as soon as it receives the Router Advertisement - Tree 878 Information Option from the preferred Attachment Router, it will 879 restrain from sending a Router Advertisement - Tree Information 880 Option between the time it receives the RA and the time it actually 881 jumps. So the crossing of RA may only happen during the propagation 882 time between the Attachment Router and the Mobile Router, plus some 883 internal queuing and processing time within each machine. It is 884 expected that one tree delay normally covers that interval, but 885 ultimately it is up to the implementation and the configuration of 886 the Attachment Router to define the duration of risk window. 888 There is risk of a collision when a Mobile Router receives an RA, for 889 an other mobile router that is more preferable than the current 890 Attachment Router, within the risk window. In the face of a 891 potential collision, the Mobile Router with the lowest extended 892 preference processes the Router Advertisement - Tree Information 893 Option normally, while the router with the highest preference places 894 the other in collision state, does not start the tree hop timer, and 895 does not become instable. It is expected that next RAs between the 896 two will not cross anyway. 898 5.4.4. Instability 900 A Mobile Router is instable when it is prepared to move shortly to 901 another Attachment Router. This happens typically when the Mobile 902 Router has selected a more preferred candidate Attachment Router and 903 has to wait for the tree hop timer to elapse before roaming. 904 Instability may also occur when the current Attachment Router is lost 905 and the next best is still held up. Instability is resolved when the 906 tree hop timer of all the Attachment Router (s) causing instability 907 elapse. Such Attachment Router is changes state to Current or Held- 908 Down. 910 Instability is transient (in the order of tree hop timers). When a 911 Mobile Router is unstable, it MUST NOT send RAs with TIO. This 912 avoids loops when Mobile Router A wishes to attach to Mobile Router B 913 and Mobile Router B wishes to attach to Mobile Router A. Unless RA 914 cross (see Collision section), a Mobile Router receives TIO from 915 stable Attachment Routers, which do not plan to attach to itself, so 916 the Mobile Router can safely attach to them. 918 5.5. Legacy Routers 920 A legacy router sends its Router Advertisements without a TIO. 921 Consequently, a legacy router can be mistaken for a fixed Access 922 Router when it is placed within a nested NEMO structure, and defeat 923 the loop avoidance mechanism. Consequently, it is important for the 924 administrator to prevent address autoconfiguration by visiting Mobile 925 Routers from such a legacy router. 927 6. Directed Acyclic Graph Discovery 929 Tree Discovery builds trees, which are a specific form of a Directed 930 Acyclic Graph (DAG). In a more general Fashion, TD can be adapted to 931 form DAGs, oriented towards the clusterhead. This is DAG Discovery. 933 In Section 5.3, TD enables a given MR to expose a depth that is 934 incremented by more than one with regards to its parent. When it 935 does so, a MR can elect a number of alternate parents as feasible 936 successors. A feasible successor belongs to the same tree as the MR 937 parent, and has a depth that is less than that of the MR. 939 The links MR to feasible successors complete the tree as built by TD 940 into a DAG towards the clusterhead. The DAG enables alternate exit 941 paths for a multihomed Mobile Router. 943 7. IANA Considerations 945 Section 4.1. requires the definition of a new option to Neighbor 946 discovery [1] messages, the Router Advertisement - Tree Information 947 Option (RA-TIO). The Router Advertisement - Tree Information Option 948 has been assigned the value TBD within the numbering space for IPv6 949 Neighbor Discovery Option Formats. 951 8. Security Considerations 953 At the current level of this draft, the TIO bears the security level 954 of the RA and the link. Nothing is added to it. A deeper threat 955 analysis would be required to eventually propose additional security. 957 9. Changes 959 9.1. Changes from version 00 to 01 961 Added text on sub-tree mobility from the discussion with Marcelo. 963 Added text on nested legacy routers from the discussion with 964 Marcelo. 966 9.2. Changes from version 01 to 02 968 Improved text on instability 970 Changed the formula for the 4 bytes number used in collision 971 avoidance 973 9.3. Changes from version 02 to 03 975 Added suboptions for tree group, stable time and bandwidth. 977 Added administrative depth and increment by more than 1. 979 Added words on bidirectional check using ND. 981 Added DAG discovery. 983 9.4. Changes from version 03 to 04 985 Added suboptions for Path Free Medium Time. 987 9.5. Changes from version 04 to 05 989 Added a sequence counter which provides additional loop protection 990 based on a comment by Christipher Dearlove. For the sake of the 991 discussion, note that if a loop were to occur, the count to 992 infinity would actually cause the MR taht reaches the max depth to 993 detach and that would resolve the issue anyway. 995 9.6. Changes from version 05 to 06 997 Added the Uniform Path Metric. Removed the N bit in RA and 998 changed the semantics of the H bit in TIO. Added some test at teh 999 beginning of the Tree Discovery section to explain the role of the 1000 depth vs. the plug-ins. 1002 10. Acknowledgments 1004 The authors wish to thank Marco Molteni and Patrick Wetterwald 1005 (cisco) for their participation to this design and the review of the 1006 document, Massimo Villari (university of Messina), for his early work 1007 on simulation and research on the subject and Julien Abeille for his 1008 advanced participation in simulation and real testing. Also the 1009 authors wish to thank Christopher Dearlove for his suggestion for 1010 additional protection against loops in TD. This work is also based 1011 on prior publications, in particular HMRA [6] by Hosik Cho and Eun- 1012 Kyoung Paik from Seoul National University and other non IETF 1013 publications coauthored with Thierry Ernst and Thomas Noel. Finally, 1014 the authors heartily thank Marcelo Bagnulo Braun and Teco Boot for 1015 their very constructive reviews. 1017 11. References 1019 11.1. Normative Reference 1021 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1022 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1024 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1025 IPv6", RFC 3775, June 2004. 1027 [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1028 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 1029 January 2005. 1031 [4] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 1032 draft-ietf-nemo-terminology-06 (work in progress), 1033 November 2006. 1035 [5] Draves, R. and D. Thaler, "Default Router Preferences and More- 1036 Specific Routes", RFC 4191, November 2005. 1038 11.2. Informative Reference 1040 [6] Cho, H., "Hierarchical Mobile Router Advertisement for nested 1041 mobile networks", draft-cho-nemo-hmra-00 (work in progress), 1042 January 2004. 1044 [7] Ng, C., "Analysis of Multihoming in Network Mobility Support", 1045 draft-ietf-nemo-multihoming-issues-07 (work in progress), 1046 February 2007. 1048 [8] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its 1049 application to Mobile Networks", 1050 draft-thubert-nemo-reverse-routing-header-07 (work in progress), 1051 February 2007. 1053 Authors' Addresses 1055 Pascal Thubert 1056 Cisco Systems 1057 Village d'Entreprises Green Side 1058 400, Avenue de Roumanille 1059 Batiment T3 1060 Biot - Sophia Antipolis 06410 1061 FRANCE 1063 Phone: +33 4 97 23 26 34 1064 Email: pthubert@cisco.com 1066 Caroline Bontoux 1067 Fortinet 1068 Sophia Antipolis 1069 Biot 06410 1070 FRANCE 1072 Email: cbontoux@fortinet.com 1074 Nicolas Montavont 1075 LSIIT - Univerity Louis Pasteur 1076 Pole API, bureau C444 1077 Boulevard Sebastien Brant 1078 Illkirch 67400 1079 FRANCE 1081 Phone: (33) 3 90 24 45 87 1082 Email: montavont@dpt-info.u-strasbg.fr 1083 URI: http://www-r2.u-strasbg.fr/~montavont/ 1085 Full Copyright Statement 1087 Copyright (C) The IETF Trust (2007). 1089 This document is subject to the rights, licenses and restrictions 1090 contained in BCP 78, and except as set forth therein, the authors 1091 retain all their rights. 1093 This document and the information contained herein are provided on an 1094 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1095 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1096 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1097 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1098 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1099 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1101 Intellectual Property 1103 The IETF takes no position regarding the validity or scope of any 1104 Intellectual Property Rights or other rights that might be claimed to 1105 pertain to the implementation or use of the technology described in 1106 this document or the extent to which any license under such rights 1107 might or might not be available; nor does it represent that it has 1108 made any independent effort to identify any such rights. Information 1109 on the procedures with respect to rights in RFC documents can be 1110 found in BCP 78 and BCP 79. 1112 Copies of IPR disclosures made to the IETF Secretariat and any 1113 assurances of licenses to be made available, or the result of an 1114 attempt made to obtain a general license or permission for the use of 1115 such proprietary rights by implementers or users of this 1116 specification can be obtained from the IETF on-line IPR repository at 1117 http://www.ietf.org/ipr. 1119 The IETF invites any interested party to bring to its attention any 1120 copyrights, patents or patent applications, or other proprietary 1121 rights that may cover technology that may be required to implement 1122 this standard. Please address the information to the IETF at 1123 ietf-ipr@ietf.org. 1125 Acknowledgment 1127 Funding for the RFC Editor function is provided by the IETF 1128 Administrative Support Activity (IASA).