idnits 2.17.1 draft-thubert-nina-01.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1038. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1049. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1056. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1062. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 4, 2007) is 6141 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. '2') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3344 (ref. '3') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == Outdated reference: A later version (-08) exists of draft-thubert-tree-discovery-05 -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 3041 (ref. '8') (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3633 (ref. '10') (Obsoleted by RFC 8415) == Outdated reference: A later version (-07) exists of draft-ietf-autoconf-manetarch-03 == Outdated reference: A later version (-19) exists of draft-ietf-manet-olsrv2-03 == Outdated reference: A later version (-15) exists of draft-ietf-manet-nhdp-04 == Outdated reference: A later version (-01) exists of draft-wakikawa-manemo-problem-statement-00 == Outdated reference: A later version (-04) exists of draft-ietf-autoconf-statement-00 == Outdated reference: A later version (-05) exists of draft-bernardos-manet-autoconf-survey-00 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Thubert 3 Internet-Draft Cisco 4 Intended status: Standards Track R. Wakikawa 5 Expires: January 5, 2008 Keio University 6 C. Bernardos 7 UC3M 8 R. Baldessari 9 NEC Europe 10 J. Lorchat 11 Keio University 12 July 4, 2007 14 Network In Node Advertisement 15 draft-thubert-nina-01.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 5, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 The Internet is evolving to become a more ubiquitous network, driven 49 by the low prices of wireless routers and access points and by the 50 users' requirements of connectivity anytime and anywhere. For that 51 reason, a cloud of nodes connected by wireless technology is being 52 created at the edge of the Internet. This cloud is called a MANEMO 53 Fringe Stub (MFS). It is expected that networking in the MFS will be 54 highly unmanaged and ad-hoc, but at the same time will need to offer 55 excellent service availability. The NEMO Basic Support protocol 56 could be used to provide global reachability for a mobile access 57 network within the MFS and the Tree-Discovery mechanism could be used 58 to avoid the formation of loops in this highly unmanaged structure. 59 Since Internet connectivity in mobile scenarios can be costly, 60 limited or unavailable, there is a need to enable local routing 61 between the Mobile Routers within a portion of the MFS. This form of 62 local routing is useful for Route Optimization (RO) between Mobile 63 Routers that are communicating directly in a portion of the MFS. 65 Network In Node Advertisement (NINA) is the second of a 2-passes 66 routing protocol; a first pass, Tree Discovery, builds a loop-less 67 structure -- a tree --, and the second pass, NINA, exposes the Mobile 68 Network Prefixes (MNPs) up the tree. The protocol operates as a 69 multi-hop extension of Neighbor Discovery (ND), to populate TD-based 70 trees with prefixes, and establish routes towards the MNPs down the 71 tree, from the root-MR towards the MR that owns the prefix, whereas 72 the default route is oriented towards the root-MR. 74 The NINA protocol introduces a new option in the ND Neighbor 75 Advertisement (NA), the Network In Node Option (NINO). An NA with 76 NINO(s) is called a NINA (Network In Node Advertisement). NINA is 77 designed for a hierarchical model where an embedded network is 78 abstracted as a Host for the upper level of network abstraction. 79 With NINA, a Mobile Router presents its sub-tree to its parent as an 80 embedded network and hides the inner topology and movements. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 6 87 4. Rationale for the proposed solution . . . . . . . . . . . . . 7 88 4.1. Why ND based . . . . . . . . . . . . . . . . . . . . . . . 7 89 4.2. Why NA based . . . . . . . . . . . . . . . . . . . . . . . 7 90 4.3. Relationship with TD . . . . . . . . . . . . . . . . . . . 8 91 4.4. Relationship with NEMO . . . . . . . . . . . . . . . . . . 8 92 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 93 5.1. Nested NEMO . . . . . . . . . . . . . . . . . . . . . . . 10 94 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 12 95 6.1. NINA message . . . . . . . . . . . . . . . . . . . . . . . 12 96 7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 15 97 7.1. Multicast TD RA messages from parent . . . . . . . . . . . 17 98 7.2. Unicast NINA messages from child to parent . . . . . . . . 18 99 7.3. Other events . . . . . . . . . . . . . . . . . . . . . . . 18 100 7.4. Aggregation of prefixes on a same MR . . . . . . . . . . . 19 101 7.5. Aggregation of prefixes by a parent acting as mobile 102 Home . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 7.6. Default value . . . . . . . . . . . . . . . . . . . . . . 20 104 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 21 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 106 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 107 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 108 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 109 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 110 12.2. Informative References . . . . . . . . . . . . . . . . . . 25 111 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 113 Intellectual Property and Copyright Statements . . . . . . . . . . 31 115 1. Introduction 117 Mobile IP [3] allows transparent routing of IPv4 datagrams to mobile 118 nodes in the Internet. Mobile IPv6 (MIPv6) [4] extends this facility 119 for IPv6, and NEMO [5] enables it for mobile prefixes. In any case, 120 a mobile node is always identified by its Home Address (HoA), 121 regardless of its current point of attachment to the Internet. In 122 turn, MANET [12], [15] allows a set of unrelated nodes and routers to 123 discover their peers and establish communication. 125 Mobile Routers (MRs) may attach to other MRs and form a Care-of 126 Address (CoA) from a Mobile Network Prefix (MNP). As a result, MRs 127 are really MARs, Mobile Access Routers, because they can accept 128 connections from other MRs on their ingress interfaces. When Mobile 129 Routers attach to other Mobile Routers with a single Care-of Address 130 in a loop-less manner, they end up building trees. This process is 131 described in Tree Discovery (TD) [6]. 133 This draft provides a minimum extension to IPv6 Neighbor Discovery 134 (ND) Neighbors Advertisements (NA) - called NINA (Network In Node 135 Advertisement) - extending RFC 2461 [2] and RFC 4191 [7] to add the 136 capability to include a prefix option - called NINO (Network In Node 137 Option) - in the NAs. This enables an MR to learn the prefixes of 138 all other MRs down its sub-tree. Note that NINO is pronounced NEE- 139 GNO and NINA is pronounced NEE-GNA. 141 A NEMO Mobile Router has a double behavior. On its egress 142 interfaces, which are used to backhaul the traffic to the Home 143 Network and the rest of the Internet, it is seen as a Mobile Node 144 (MN), performing the IPv6 and MIPv6 host-required features such as 145 neighbor and router discovery [2]. On the (ingress) interfaces to 146 the Mobile Networks, the Mobile Router behaves as an IPv6 router with 147 support of the MIPv6 requirements on routers. This is why TD [6] 148 extends ND RA over the ingress interface of a Mobile Router whereas 149 NINA extends ND NAs to advertise over the egress interface the 150 prefixes that are reachable via the MR. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [1]. 158 Readers are expected to be familiar with all the terms defined in the 159 RFC 3753 [11], the NEMO Terminology draft [20] and the MANEMO Problem 160 Statement draft [19]. 162 NINO (Network In Node Option): a new Neighbor Discovery (ND) 163 option that adds the capability to include a prefix option in 164 Neighbor Advertisements (NAs). 166 NINA (Network In Node Advertisement): a Neighbor Discovery (ND) 167 Neighbor Advertisement (NA) carrying a NINO. NINA is also used to 168 refer to the protocol itself (defined in this document). 170 3. Motivations 172 The Internet is evolving to become a more ubiquitous network, driven 173 by the low prices of wireless routers and access points and by the 174 users' requirements of connectivity anytime and anywhere. For that 175 reason, a cloud of nodes connected by wireless technology is being 176 created at the edge of the Internet. This cloud is called a MANEMO 177 Fringe Stub (MFS) in [19]. Examples of wireless technologies used 178 within a MFS are wireless metropolitan and local area network 179 protocols (WiMAX, WLAN, 802.20, etc), short distance wireless 180 technology (bluetooth, IrDA, UWB), and radio mesh networks (e.g., 181 802.11s). It is expected that networking in the MFS will be highly 182 unmanaged and ad-hoc, but at the same time will need to offer 183 excellent service availability. 185 The NEMO Basic Support protocol [5] could be used to provide global 186 reachability for a mobile access network within the MFS. 187 Analogously, the Tree-Discovery mechanism [6] could be used to avoid 188 the formation of loops in this highly unmanaged structure. However, 189 even with these two technologies in place, packet delivery within the 190 MFS can still be highly inefficient. Since Internet connectivity in 191 mobile scenarios can be costly, limited or unavailable, there is a 192 need to enable local routing between the Mobile Routers within a 193 portion of the MFS. NINA can provide this form of local routing; it 194 is an example of Route Optimization (RO) between Mobile Routers that 195 are communicating directly in a portion of the MFS. 197 4. Rationale for the proposed solution 199 4.1. Why ND based 201 NINA extends the Neighbor Discovery protocol to address the MANEMO 202 requirements listed in [19], although MANET protocols [13], [16], 203 [17] provides similar features such as local routing and Internet 204 access over multihop. 206 One of the drawbacks of MANET protocols is the question of which 207 protocol should be used. AODV, DSR, DYMO, OLSR, etc. are 208 standardized in IETF and each has distinct features, like proactive 209 and reactive. In MANEMO scenarios, Mobile Routers, mobile hosts, and 210 fixed access routers are involved, and therefore, it is highly 211 important to deploy a consistent protocol in the network. On the 212 other hand, ND is a core component of IPv6 and is supported by all 213 IPv6 nodes. All IPv6 nodes can process a NINO(s) in ND messages if 214 desired. 216 MANEMO does not require full link states of a network as OLSR does, 217 it only requires path to and from the exit router (tree root) in the 218 tree fashion. Flooding the entire network with route information is 219 a redundant process and its overhead is not negligible. ND simply 220 carries prefix information to setup the path from the tree root to 221 each mobile router/node. 223 4.2. Why NA based 225 Since an MR appears as a host on the egress interface side, it is 226 legitimate to use NA in the visited network. There are two reasons 227 for that: 229 o If an MR advertises itself as a router in the visited network 230 using RA, it might get used as a default router by Local Fixed 231 Nodes (LFNs) attached to the visited network and cause trouble. 233 o By using NINA, the whole part of the fringe behind the MR has the 234 footprint of a single host from the visited network standpoint 235 (and moves as a single host). 237 By using NINA on top of a TD established tree, MANEMO can be made to 238 reproduce the NEMO behavior for a whole subtree by reducing to a 239 single host footprint, and retain NEMO compatibility by avoiding 240 spurious RAs. Thus, a whole subtree can move within the fringe as a 241 single host. 243 4.3. Relationship with TD 245 NINA exploits the loop-less cluster established by Tree Discovery, so 246 it does not need to provide loop avoidance. 248 With TD, MRs setup a default route up the tree via the parent Access 249 Router, and all the packets are directed by default towards the 250 clusterhead (Top Level Mobile Router or root-MR in NEMO terms). To 251 provide complete reachability, it is enough for NINA to expose the 252 prefixes down the tree from any given MR, while propagating prefixes 253 information up the tree. 255 This allows an extreme conciseness of the routing information, with 256 no topological knowledge past the first hop. That conciseness 257 enables a high degree of movement within the nested structure; in 258 particular, a movement within a subtree is not seen outside of that 259 subtree, so most of the connectivity is maintained at all times while 260 there might never be such a thing as a convergence. 262 4.4. Relationship with NEMO 264 The Reverse Routing Header (RRH) described in [18] operates in the 265 nested NEMO as a layer 3 Source Route Bridging (SRB) technique for 266 nested NEMO Route Optimization. It allows a quick reaction to inner 267 movements with the resolution of the packet; but the cost, an IPv6 268 address per packet per hop, might be deemed excessive. 270 Also, the Home Agent needs to cache the RRH in its binding cache, and 271 again, the overhead might be significant for a large deployment. 273 On the other hand, NINA establishes states in the intermediate nodes, 274 in a fashion similar to Transparent Bridging (TB), but at layer 3. 275 The integration of these 2 approaches allows switching between SRB to 276 TB models dynamically as the NINA states are populated or become 277 obsolete. To obtain this capability, the operation of an 278 intermediate MR described in [18] is altered in the following manner: 280 o If the MR has a (NINA) route to the upper entry in the RRH via the 281 source of the packet, it still updates the source of the packet 282 with its own Care-of Address, but does not save the previous 283 source as a new entry in the RRH. 285 o At best, if NINA has established states all along in a given 286 branch of the tree, the RRH for that branch has always 2 entries, 287 the first MR's Home Address, and its Care-of Address, regardless 288 of the depth of the first MR in the nested NEMO. 290 o When some MRs in the tree support NINA and some do not, the 291 resulting RRH will be only partly compressed. Also, if the NINA 292 route does not match the RRH, then the route is obsolete and the 293 source address is added to the RRH as described in [18], in order 294 to ensure a correct routing on the way back. When NINA catches 295 up, the entry will be saved again. 297 The integration of NINA and RRH can offer the best of 2 worlds: a 298 quick (per packet) resolution to the network changes, and the 299 transparent (stateful) operation when the NINA routing protocol 300 establishes the states in the nested NEMO. 302 5. Overview 304 This section provides an overview of the operation of NINA to set-up 305 MNP route state in a nested-NEMO scenario. 307 5.1. Nested NEMO 309 NINA requires the Tree Discovery protocol to build and maintain a 310 tree topology. It relies on TD to discover that a change occurs in a 311 sub-tree of the topology, and that change triggers a flow of route 312 updates for that sub-tree in the topology. 314 +---------------------+ 315 | Internet |---CN 316 +---------------|-----+ 317 / Access Router 318 MR3_HA | 319 ======?====== 320 MR1 321 | 322 ====?=============?==============?=== 323 MR5 MR2 MR6 324 | | | 325 =========== ===?========= ============= 326 MR3 327 | 328 ==|=========?== 329 LFN1 MR4 330 | 331 ========= 333 Figure 1: Nested NEMO scenario 335 Each tree that TD self-forms is considered a separate routing 336 topology. If a Mobile Router belongs to multiple of such topologies, 337 then it is expected that both the NINA signaling and the data packets 338 are flagged to follow the topology for which the packet was 339 introduced in the network. 341 NINA expects a Mobile Router to own one or more Mobile Network 342 Prefix(es) that move with the MR. With that model, it is assumed 343 that there is a single source for the advertisement of a given prefix 344 within a topology. If multiple MRs share a given MNP, some protocol 345 must take place between those MRs to make sure that one and only one 346 MR advertises a given prefix in a given tree. 348 Tree Discovery formats the nested NEMO into a loop-less logical 349 graph, thus providing loop avoidance for the NINA protocol. Each 350 time a movement occurs, TD restores the loop-less structure before 351 NINA can operate again and repaint the graph with prefixes. 353 The root-MR of a nested NEMO is selected for a number of properties, 354 the primary one being an access to the wired infrastructure. It is 355 the default sink for every node in the tree. 357 More generally, the default gateway for a Mobile Router is its parent 358 up in the tree; the more specific routes, towards the Mobile Network 359 Prefixes, are always oriented down the tree, and NINA advertisements 360 flow up the tree towards the root-MR. 362 Each NINO contains a prefix and a sequence counter. The Mobile 363 Router that owns the prefix generates the NINO for that prefix, 364 including the sequence counter associated to that prefix and that is 365 incremented each time it generates a new NINO. 367 Due to a movement, a sub-tree can be temporarily out of sequence and 368 a NINO can be received from a sub-tree where the MR was but is no 369 more, until the parents realize it is gone. But by construction of 370 the tree, there can be a single route to a given prefix, so older 371 information is always invalid. 373 A parent-MR maintains a state for each prefix it learns from NINA. 374 In particular, the last sequence number is kept. An out-of-sequence 375 NINO must be disregarded. If the NINO appears valid, it is forwarded 376 to the parent's parent in the next burst, carried by a NINA, together 377 with the parent's own prefixes. 379 6. Message Formats 381 6.1. NINA message 383 NINA extends Neighbor Discovery [2] and RFC 4191 [7] to allow an MR 384 include a prefix option in the Neighbor Advertisements (NAs). The NA 385 is a necessary exchange that allows the AR to map the IPv6 address of 386 a node with its L2 address. The prefix option is normally present in 387 Router Advertisements (RAs) only. The meaning of such an option in a 388 NA is the concept of 'network in node', so we refer to this new ND 389 option as NINO (Network In Node Option) and we name the resulting 390 message NINA (Network In Node Advertisement). 392 When Tree Discovery is used to build a tree, there can be a single 393 route to a given prefix along that tree, so the freshest information 394 is always the best for unicast routes. In order to track that, the 395 NINO includes a sequence counter to the prefix advertisement. 397 The sequence counter is incremented by the source of the NINO, that 398 is the Mobile Router that owns the MNP, each time it issues a NINA, 399 and then forwarded as is up the tree. A depth is also added for 400 tracking purposes; the depth is incremented at each hop as the NINO 401 is propagated up the tree. 403 On an egress interface, if NINA is configured, the MR: 405 o selects an Access Router (AR) as its point of attachment to the 406 network 408 o auto-configures a Care-of Address (CoA) 410 o acts as a host as opposed to a router. In particular, it refrains 411 from sending RAs 413 o sends NINAs, as unicast, to its AR only 415 o accepts unicast NINAs from any node BUT its AR 417 On an ingress interface, if NINA is configured, the MR: 419 o acts as a router, may accept visitors 421 o sends RAs with the Tree Information Option (RA-TIO) 423 o accepts NINAs from any node 425 Every NA to the AR contains a NINO. In particular, receiving a Tree 426 Discovery RA-TIO from the AR stimulates the sending of a delayed NINA 427 back, with the collection of all known prefixes (that is the prefixes 428 learned from NINO and the connected prefixes). A NINA is also sent 429 to the AR once it has been selected as new AR after a movement, or 430 when the list of advertised prefixes has changed. 432 NINA may advertise positive (prefix is present) or negative (removed) 433 NINOs. A no-NINO is stimulated by the disappearance of a prefix 434 below. This is discovered by timing out after a request (a RA-TIO) 435 or by receiving a no-NINO. A no-NINO is a NINO with a NINO Lifetime 436 of 0. 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Type | Length | Prefix Length | Reserved1 |L|4| 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | NINO Lifetime | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Reserved2 | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | NINO Depth | Reserved3 | NINO Sequence | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | | 450 + + 451 | | 452 + Prefix (Variable Length) + 453 | | 454 + + 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Type: 460 NINO (number to be assigned by IANA). 462 Length: 464 8-bit unsigned integer. The length of the option (including the 465 Type and Length fields) in units of 8 octets. 467 Prefix Length: 469 Number of valid leading bits in the IPv6 Prefix. 471 Reserved1: 473 6-bit unused field. It MUST be initialized to zero by the sender 474 and MUST be ignored by the receiver. 476 'L' bit: 478 Indicates that the prefix or address is on-link as opposed to 479 another interface of the MR. This is useful for a child MR to 480 expose its IPv4 address on its egress interface. In that case, 481 the parent can set up forwarding to all the IPv4 prefixes in the 482 NINA via that address on this link. 484 '4' bit: 486 Indicates that the Prefix field carries an IPv4 mapped address. 488 NINO Lifetime: 490 32-bit unsigned integer. The length of time in seconds (relative 491 to the time the packet is sent) that the prefix is valid for route 492 determination. A value of all one bits (0xFFFFFFFF) represents 493 infinity. A value of all zero bits (0x00000000) indicates a loss 494 of reachability. 496 Reserved2: 498 32-bit unused field. It MUST be initialized to zero by the sender 499 and MUST be ignored by the receiver. 501 NINO Depth: 503 Set to 0 by the MR that owns the MNP and issues the NINO. 504 Incremented by all MRs that propagate the NINO. 506 Reserved3: 508 8-bit unused field. It MUST be initialized to zero by the sender 509 and MUST be ignored by the receiver. 511 NINO Sequence: 513 Incremented by the MR that owns the MNP for each new NINO for that 514 prefix. Left unchanged by all MRs that propagate the NINO. A 515 lollipop mechanism is used to wrap from 0xFFFF directly to 10. 517 Prefix: 519 Variable-length field containing an IPv6 address or a prefix of an 520 IPv6 address. The Prefix Length field contains the number of 521 valid leading bits in the prefix. The bits in the prefix after 522 the prefix length (if any) are reserved and MUST be initialized to 523 zero by the sender and ignored by the receiver. 525 7. Mobile Router Operation 527 The Mobile Router operation is autonomous, based on the information 528 provided by the potential Access Routers in sight. Each MR selects 529 an AR (a MAR) in a loop-less and case-optimized fashion, and installs 530 a default route up the tree via the selected AR. The resulting tree 531 (the cluster) may never be globally stable enough to be mapped in a 532 global graph. So the adaptation to local movements must be rapid and 533 localized. 535 For NEMO flows, the Reverse Routing Header allows the update to the 536 path on a per packet basis. Hopefully, the root of the tree (the 537 clusterhead) is connected to the infrastructure where Home can be 538 reached, and can be used as a gateway to discover Home. When the 539 NEMO tunnel is established, it becomes the default route for the MR. 541 If the tree is not connected to the infrastructure or in any case if 542 Home can not be reached, MRs need an ad-hoc protocol to establish 543 local connectivity. This specification takes advantage of the TD 544 cluster and allows an MR to discover the prefixes below itself. 546 NINA information can be redistributed in a routing protocol, MANET or 547 IGP. But the MANET or the IGP SHOULD NOT be redistributed into NINA. 548 This creates a hierarchy of routing protocols where NINA routes stand 549 somewhere between connected and IGP routes. 551 NINA also allows a compression of the Reverse Routing header when the 552 routes match the topology as traced by RRH on a per packet basis. In 553 particular, if a NINA route exists to the first entry in the RRH via 554 the source of the packet, then the MR can override the source of the 555 packet with its own CoA without adding the original source to the 556 RRH. At that point, the RRH operation becomes loose, in other words 557 an hybrid between transparent (stateful) and source routing. 559 As a result: 561 o Tree Discovery establishes a tree using extended Neighbor 562 Discovery RS/RA flows. 564 o The NEMO Basic Support protocol exploits the tree to get optimally 565 out of a nested set of MRs and register Home. 567 o RRH extends the NEMO Basic Support to provide Route Optimization 568 and faster path reestablishment. 570 o NINA also extends Neighbor Discovery in order to establish quickly 571 the routes down the cluster. 573 NINA maintains abstract lists of known prefixes. A prefix entry 574 contains the following abstract information: 576 o The state of the entry: ELAPSED, PENDING, or CONFIRMED. 578 o A reference to the adjacency that was created for that prefix. 580 o A reference to the ND entry that was created for the advertiser 581 Neighbor. 583 o The IPv6 address of the advertiser Neighbor. 585 o The logical equivalent of the full NINA information. 587 o A reference to the interface of the advertiser Neighbor. 589 o A 'reported' Boolean to keep track whether this prefix was 590 reported already to the parent AR. 592 o A counter of retries to count how many RA-TIOs were sent on the 593 interface to the neighbor without reachability confirmation for 594 the prefix. 596 NINA stores the prefix entries in either one of 3 abstract lists; the 597 Connected, the Reachable and the Unreachable lists. 599 The Connected list corresponds to the MNP of the Mobile Router. 601 As long as an MR keeps receiving NINOs for a prefix timely, its 602 prefix entry is listed in the Reachable list. 604 Once scheduled to be destroyed, a prefix entry is moved to the 605 Unreachable list if the MR has a parent to which it sends NINOs, 606 otherwise the entry is cleaned up right away. The entry is removed 607 from the Unreachable list when the parent changes or when a no-NINO 608 is sent to the parent indicating the loss of the prefix. 610 NINA requires 2 timers; the DelayNA timer and the DestroyTimer. 612 o The DelayNA timer is armed upon a stimulation to send a NINA (such 613 as a TIO from the AR). When the timer is armed, all entries in 614 the Reachable list as well as all entries for Connected list are 615 set to not reported yet. 617 o The DelayNA timer has a duration that is DEF_NA_LATENCY divided by 618 2 with the tree depth. 620 o The DestroyTimer is armed when at least one entry has exhausted 621 its retries, which means that a number of RA-TIO were sent over 622 the ingress interface but that the entry was not confirmed with a 623 NINO. When the destroy timer elapses, for all exhausted entries, 624 the associated route is removed, and the entry is scheduled to be 625 destroyed. 627 o The Destroy timer has a duration of min (MAX_DESTROY_INTERVAL, 628 RA_INTERVAL). 630 7.1. Multicast TD RA messages from parent 632 When ND sends a NA to the AR, NINA extends the message with prefix 633 options for: 635 o All the prefixes that are not 'DELETED' for all the ingress 636 interfaces. 638 o All the prefixes in the removed list as no-NINO. 640 o All the prefixes in the advertised list that are not reported yet. 641 The entries are set to reported. 643 When ND receives a NA from a visitor over an ingress interface, NINOs 644 are processed in a loop. For known prefixes, the sequence counter in 645 the NINO is checked against the last received and the update is used 646 only if the sequence is newer. This filters out obsolete 647 advertisements when a prefix has moved between 2 subtrees attached to 648 a same node. 650 If a prefix is advertised as a no-NINO, the associated route is 651 removed, and the entry is transferred to the removed list. 652 Otherwise, the route table is looked up: 654 o If a preferred route to that prefix from another protocol already 655 exists, the prefix is ignored. 657 o If a new route can be created, a new prefix entry is allocated to 658 track it, as CONFIRMED, but not reported. 660 o If a NINA route existed already via the same Neighbor, it is 661 CONFIRMED. 663 o If a NINA route existed via a different Neighbor, this is 664 equivalent to a no-NINO for the previous entry followed by a new 665 NINO for the new entry. So the old entry is scheduled to be 666 destroyed, whereas the new one is installed. 668 7.2. Unicast NINA messages from child to parent 670 When sending NINA to its parent, an MR includes the NINOs about not 671 already reported prefix entries in the Reachable and Connected lists, 672 as well as no-NINOs for all the entries in the Unreachable list. 673 Depending on its policy, the receiving MR SHOULD install a route to 674 the prefix in the NINO via the link local address of the source MR 675 and it SHOULD propagate the information, either as a NINO or by means 676 of redistribution into a routing protocol. 678 The RA-TIO from the root-MR is used to synchronize the whole tree. 679 Its period is expected to range from 500ms to hours, depending on the 680 stability of the configuration and the bandwidth available. 682 When an MR receives a RA-TIO over an egress interface from the 683 current parent AR, the DelayNA is armed to force a full update. As 684 described in [6] the MR also issues a propagated RA-TIO over all its 685 ingress interfaces, after a small jitter that aims at minimizing 686 collisions of RA-TIO messages over the radio as it is propagated down 687 the tree. 689 The design choice behind this is NOT TO synchronize the parent and 690 children databases, but instead to update them regularly to cover 691 from the loss of packets. The rationale for that choice is movement. 692 If the topology can be expected to change frequently, synchronization 693 might be an excessive goal in terms of exchanges and protocol 694 complexity. This results in a simple protocol with no real peering. 696 When the MR sends a RA-TIO over an ingress interface, for all entries 697 on that interface: 699 o If the entry is CONFIRMED, it goes PENDING with the retry count 700 set to 0. 702 o If the entry is PENDING, the retry count is incremented. If it 703 reaches a maximum threshold, the entry goes ELAPSED If at least 704 one entry is ELAPSED at the end of the process: if the Destroy 705 timer is not running then it is armed with a jitter. 707 Since the DelayNA has a duration that decreases with the depth, it is 708 expected to receive all NINOs from all children before the timer 709 elapses and the full update is sent to the parent. 711 7.3. Other events 713 Finally, NINA listens to a series of events, such as: 715 o MR stopped or unable to run: NINA routes are cleaned up. NINA is 716 inactive. 718 o NINA operation stopped: All entries in the abstract lists are 719 freed. All the NINA routes are destroyed. 721 o Interface going down: for all entries in the Reachable list on 722 that interface, the associated route is removed, and the entry is 723 scheduled to be destroyed. 725 o Neighbor being removed from the ND list: if the entry is in the 726 Reachable list the associated route is removed, and the entry is 727 scheduled to be destroyed. 729 o Roaming: All entries in the Reachable list are set to not 730 'reported' and DelayNA is armed. 732 7.4. Aggregation of prefixes on a same MR 734 When deploying an MR with multiple ingress interfaces, it makes sense 735 to affect an aggregation prefix (shorter than /64) to the MR and 736 partition it as /64 prefixes over the MR interfaces. An MR that owns 737 a contiguous set of prefixes should only report the aggregation of 738 these prefixes through NINA. 740 7.5. Aggregation of prefixes by a parent acting as mobile Home 742 There are also a number of cases where a mobile aggregation is shared 743 within a toon of Mobile Routers. For instance, a toon formed by 744 firefighters and their commander. In that case, it is still possible 745 to use aggregation techniques with NINA and improve its scalability. 746 In that case, the commander is configured as the NINA aggregator for 747 the group prefix. In run time, it absorbs the individual NINO 748 information it receives from the toon members down its subtree and 749 only reports the aggregation up the TD tree. This works fine when 750 the whole toon is attached within the commander's subtree. 752 But other cases might occur for which additional support is required: 754 1. the commander is attached within the subtree of one of its toon 755 members. 757 2. A toon member is somewhere else within the TD tree. 759 3. A toon member is somewhere else in the Internet. 761 In all those cases, a node situated above the commander in the TD 762 tree but not above the toon member will see the advertisements for 763 the aggregation owned by the commander but not that of the individual 764 toon member prefix. So it will route all the packets for the toon 765 member towards the commander, but the commander will have no route to 766 the toon and will fail to forward. 768 Section 8 'Mobile Home' of RFC 4887 [21] proposes a deployment model 769 where a Mobile Router would also act as Home Agent for a mobile 770 aggregation. This method can be used in the general case 3 to ensure 771 routability to the toon member. With that method, the Home Link for 772 a toon member should be one of the commander links. The Tree 773 Discovery plug-in should favor that link so that many toon members 774 actually attach at Home. 776 If a toon member is not at Home, then it will register to its Home 777 Agent using NEMO basic support (RFC 3963 [5]). Depending of the 778 location of a source, a packet to the toon member will either go 779 directly to it, or go to its commander. If the toon member as a 780 Mobile Router is registered to its commander as its Home Agent, the 781 commander can always encapsulate the packet to the CoA of the toon 782 member using NEMO, and ensure reachability to the MR. 784 Section 2.7 of RFC 4888 [22] explains that in the specific case of 785 case 1), the commander will not be able to reach Home using plain 786 NEMO basic support, and an additional mechanism such as RRH ([18]) is 787 required to fix that issue. 789 Also specifically in case 1), the toon member will refrain from 790 adding the NINO options for its own prefixes that are aggregated in 791 the NINO option of its commander that it propagates up the TD tree. 793 7.6. Default value 795 DEF_NA_LATENCY = 150 ms 797 MAX_DESTROY_INTERVAL = 200ms 799 8. Privacy Considerations 801 It is already possible for a visiting Mobile Node (Mobile Router) to 802 autoconfigure an address that will not identify the visitor [8], 803 [23], [14]. It is also possible for a visitor to roll its CoA 804 periodically even when it stays attached to a same point, and 805 register the new addresses as it forms them. 807 CIA (Capability, Innocuousness and Anonymity) properties demand also 808 that the visited party might not be identified by the visitor. To 809 achieve that, a Mobile Router should not advertise its MNPs on its 810 links open to untrusted visitors. 812 This draft recommends that the interface that is open for untrusted 813 visitors uses unique local addresses (RFC 4193 [9]) and rolls the 814 advertised prefixes with a short lifetime. This can be achieved for 815 instance by obtaining short lived leases from the Home Agent using 816 DHCP-PD [24]. 818 Another possibility is to use strict RRH routing [18]; in that case, 819 the prefix that is presented on the link can be taken from anywhere 820 in the ULA range since it is not used for routing outside the link. 822 Alternatively, a global unique prefix obtained from an autoconf 823 solution [25], [26] or DHCPv6 prefix delegation [10] can be used as 824 well. 826 9. IANA Considerations 828 This document requires IANA to assign a number for a new ND option 829 type (NINO NA). 831 10. Security Considerations 833 Exposing the MRs' MNPs within the MFS introduces several security 834 threats that should be carefully tackled, mainly derived from the 835 fact that MRs are distributing prefixes (i.e., their MNPs) that are 836 not topologically correct within the MFS. 838 To avoid these security issues -- that might enable malicious nodes 839 to steal traffic addressed to other nodes (by spoofing their 840 prefixes) -- Mobile Routers should be provided with some security 841 mechanisms, ensuring that an MR that is advertising a certain MNP is 842 actually authorised to do that. 844 The use of L2 trusts and policies, SeND or preconfigured security 845 relationships might help in securing the mechanism described in this 846 draft. Additionally, if MRs have connectivity with their Home 847 Agents, a modified Return Routability mechanism -- extended to 848 support prefix checks (such as [27] or [28]) -- may be used to 849 provide the required authorisation, before starting to use the RO 850 shortcut within the MFS. 852 11. Acknowledgments 854 We would like to thank all the people who have provided comments on 855 this draft, specially to Ben McCarthy for his very helpful review of 856 this document. 858 12. References 860 12.1. Normative References 862 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 863 Levels", BCP 14, RFC 2119, March 1997. 865 [2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 866 for IP Version 6 (IPv6)", RFC 2461, December 1998. 868 [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 869 August 2002. 871 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 872 IPv6", RFC 3775, June 2004. 874 [5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 875 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 876 January 2005. 878 [6] Thubert, P., "Nested Nemo Tree Discovery", 879 draft-thubert-tree-discovery-05 (work in progress), April 2007. 881 [7] Draves, R. and D. Thaler, "Default Router Preferences and More- 882 Specific Routes", RFC 4191, November 2005. 884 [8] Narten, T. and R. Draves, "Privacy Extensions for Stateless 885 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 887 [9] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 888 Addresses", RFC 4193, October 2005. 890 [10] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 891 Configuration Protocol (DHCP) version 6", RFC 3633, 892 December 2003. 894 12.2. Informative References 896 [11] Manner, J. and M. Kojo, "Mobility Related Terminology", 897 RFC 3753, June 2004. 899 [12] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): 900 Routing Protocol Performance Issues and Evaluation 901 Considerations", RFC 2501, January 1999. 903 [13] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing 904 Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728, 905 February 2007. 907 [14] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 908 Neighbor Discovery (SEND)", RFC 3971, March 2005. 910 [15] Chakeres, I., "Mobile Ad hoc Network Architecture", 911 draft-ietf-autoconf-manetarch-03 (work in progress), June 2007. 913 [16] Clausen, T., "The Optimized Link State Routing Protocol version 914 2", draft-ietf-manet-olsrv2-03 (work in progress), March 2007. 916 [17] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)", 917 draft-ietf-manet-nhdp-04 (work in progress), June 2007. 919 [18] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 920 its application to Mobile Networks", 921 draft-thubert-nemo-reverse-routing-header-07 (work in 922 progress), February 2007. 924 [19] Wakikawa, R., "MANEMO Problem Statement", 925 draft-wakikawa-manemo-problem-statement-00 (work in progress), 926 February 2007. 928 [20] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 929 draft-ietf-nemo-terminology-06 (work in progress), 930 November 2006. 932 [21] Thubert, P., "NEMO Home Network models", 933 draft-ietf-nemo-home-network-models-06 (work in progress), 934 February 2006. 936 [22] Ng, C., "Network Mobility Route Optimization Problem 937 Statement", draft-ietf-nemo-ro-problem-statement-03 (work in 938 progress), September 2006. 940 [23] Narten, T., "Privacy Extensions for Stateless Address 941 Autoconfiguration in IPv6", draft-ietf-ipv6-privacy-addrs-v2-05 942 (work in progress), October 2006. 944 [24] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", 945 draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005. 947 [25] Baccelli, E., "Address Autoconfiguration for MANET: Terminology 948 and Problem Statement", draft-ietf-autoconf-statement-00 (work 949 in progress), June 2007. 951 [26] Bernardos, C. and M. Calderon, "Survey of IP address 952 autoconfiguration mechanisms for MANETs", 953 draft-bernardos-manet-autoconf-survey-00 (work in progress), 954 July 2005. 956 [27] Ng, C., "Extending Return Routability Procedure for Network 957 Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in progress), 958 October 2004. 960 [28] Bernardos, C., Soto, I., Maria, M., Fernando, F., and A. 961 Arturo, "VARON: Vehicular Ad hoc Route Optimisation for NEMO", 962 Computer Communications, vol. 30, pp. 1765-1784 , 2007. 964 Appendix A. Change Log 966 Changes from -00 to -01: 968 o Basic kiss (MR to MR over egress) sections removed. 970 o Added sections about aggregation of prefixes. 972 o Added Privacy consideration section. 974 o NINO NA message format changed. 976 o Some text cleanups. 978 Authors' Addresses 980 Pascal Thubert 981 Cisco Systems 982 Village d'Entreprises Green Side 983 400, Avenue de Roumanille 984 Batiment T3 985 Biot - Sophia Antipolis 06410 986 FRANCE 988 Phone: +33 4 97 23 26 34 989 Email: pthubert@cisco.com 991 Ryuji Wakikawa 992 Keio University and WIDE 993 5322 Endo Fujisawa Kanagawa 994 252-8520 995 JAPAN 997 Email: ryuji@sfc.wide.ad.jp 999 Carlos J. Bernardos 1000 Universidad Carlos III de Madrid 1001 Av. Universidad, 30 1002 Leganes, Madrid 28911 1003 Spain 1005 Phone: +34 91624 6236 1006 Email: cjbc@it.uc3m.es 1008 Roberto Baldessari 1009 NEC Europe Network Laboratories 1010 Kurfuersten-anlage 36 1011 Heidelberg 69115 1012 Germany 1014 Phone: +49 6221 4342167 1015 Email: roberto.baldessari@netlab.nec.de 1016 Jean Lorchat 1017 Keio University and WIDE 1018 5322 Endo Fujisawa Kanagawa 1019 252-8520 1020 JAPAN 1022 Email: lorchat@sfc.wide.ad.jp 1024 Full Copyright Statement 1026 Copyright (C) The IETF Trust (2007). 1028 This document is subject to the rights, licenses and restrictions 1029 contained in BCP 78, and except as set forth therein, the authors 1030 retain all their rights. 1032 This document and the information contained herein are provided on an 1033 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1034 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1035 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1036 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1037 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1038 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1040 Intellectual Property 1042 The IETF takes no position regarding the validity or scope of any 1043 Intellectual Property Rights or other rights that might be claimed to 1044 pertain to the implementation or use of the technology described in 1045 this document or the extent to which any license under such rights 1046 might or might not be available; nor does it represent that it has 1047 made any independent effort to identify any such rights. Information 1048 on the procedures with respect to rights in RFC documents can be 1049 found in BCP 78 and BCP 79. 1051 Copies of IPR disclosures made to the IETF Secretariat and any 1052 assurances of licenses to be made available, or the result of an 1053 attempt made to obtain a general license or permission for the use of 1054 such proprietary rights by implementers or users of this 1055 specification can be obtained from the IETF on-line IPR repository at 1056 http://www.ietf.org/ipr. 1058 The IETF invites any interested party to bring to its attention any 1059 copyrights, patents or patent applications, or other proprietary 1060 rights that may cover technology that may be required to implement 1061 this standard. Please address the information to the IETF at 1062 ietf-ipr@ietf.org. 1064 Acknowledgment 1066 Funding for the RFC Editor function is provided by the IETF 1067 Administrative Support Activity (IASA).