idnits 2.17.00 (12 Aug 2021) /tmp/idnits19491/draft-thubert-nina-02.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 1091. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1102. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1109. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1115. 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 (February 4, 2008) is 5220 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 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-06 -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 3633 (ref. '9') (Obsoleted by RFC 8415) == Outdated reference: draft-ietf-manet-olsrv2 has been published as RFC 7181 == Outdated reference: draft-ietf-manet-nhdp has been published as RFC 6130 -- Obsolete informational reference (is this intentional?): RFC 4941 (ref. '22') (Obsoleted by RFC 8981) == Outdated reference: A later version (-04) exists of draft-ietf-autoconf-statement-03 == Outdated reference: A later version (-05) exists of draft-bernardos-manet-autoconf-survey-02 Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 9 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: August 7, 2008 Keio University 6 C. Bernardos 7 UC3M 8 R. Baldessari 9 NEC Europe 10 J. Lorchat 11 Keio University 12 February 4, 2008 14 Network In Node Advertisement 15 draft-thubert-nina-02.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 August 7, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 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 6.2. NINO IPv4 option . . . . . . . . . . . . . . . . . . . . . 15 97 7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 16 98 7.1. Multicast TD RA messages from parent . . . . . . . . . . . 18 99 7.2. Unicast NINA messages from child to parent . . . . . . . . 19 100 7.3. Other events . . . . . . . . . . . . . . . . . . . . . . . 19 101 7.4. Aggregation of prefixes on a same MR . . . . . . . . . . . 20 102 7.5. Aggregation of prefixes by a parent acting as mobile 103 Home . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 104 7.6. Default value . . . . . . . . . . . . . . . . . . . . . . 21 105 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 22 106 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 107 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 108 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 109 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 110 12.1. Normative References . . . . . . . . . . . . . . . . . . . 26 111 12.2. Informative References . . . . . . . . . . . . . . . . . . 26 112 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 114 Intellectual Property and Copyright Statements . . . . . . . . . . 32 116 1. Introduction 118 Mobile IP [3] allows transparent routing of IPv4 datagrams to mobile 119 nodes in the Internet. Mobile IPv6 (MIPv6) [4] extends this facility 120 for IPv6, and NEMO [5] enables it for mobile prefixes. In any case, 121 a mobile node is always identified by its Home Address (HoA), 122 regardless of its current point of attachment to the Internet. In 123 turn, MANET [11], [14] allows a set of unrelated nodes and routers to 124 discover their peers and establish communication. 126 Mobile Routers (MRs) may attach to other MRs and form a Care-of 127 Address (CoA) from a Mobile Network Prefix (MNP). As a result, MRs 128 are really MARs, Mobile Access Routers, because they can accept 129 connections from other MRs on their ingress interfaces. When Mobile 130 Routers attach to other Mobile Routers with a single Care-of Address 131 in a loop-less manner, they end up building trees. This process is 132 described in Tree Discovery (TD) [6]. 134 This draft provides a minimum extension to IPv6 Neighbor Discovery 135 (ND) Neighbors Advertisements (NA) - called NINA (Network In Node 136 Advertisement) - extending RFC 4861 [2] and RFC 4191 [7] to add the 137 capability to include a prefix option - called NINO (Network In Node 138 Option) - in the NAs. This enables an MR to learn the prefixes of 139 all other MRs down its sub-tree. Note that NINO is pronounced NEE- 140 GNO and NINA is pronounced NEE-GNA. 142 A NEMO Mobile Router has a double behavior. On its egress 143 interfaces, which are used to backhaul the traffic to the Home 144 Network and the rest of the Internet, it is seen as a Mobile Node 145 (MN), performing the IPv6 and MIPv6 host-required features such as 146 neighbor and router discovery [2]. On the (ingress) interfaces to 147 the Mobile Networks, the Mobile Router behaves as an IPv6 router with 148 support of the MIPv6 requirements on routers. This is why TD [6] 149 extends ND RA over the ingress interface of a Mobile Router whereas 150 NINA extends ND NAs to advertise over the egress interface the 151 prefixes that are reachable via the MR. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [1]. 159 Readers are expected to be familiar with all the terms defined in the 160 RFC 3753 [10], the NEMO Terminology draft [19] and the MANEMO Problem 161 Statement draft [18]. 163 NINO (Network In Node Option): a new Neighbor Discovery (ND) 164 option that adds the capability to include a prefix option in 165 Neighbor Advertisements (NAs). 167 NINA (Network In Node Advertisement): a Neighbor Discovery (ND) 168 Neighbor Advertisement (NA) carrying a NINO. NINA is also used to 169 refer to the protocol itself (defined in this document). 171 3. Motivations 173 The Internet is evolving to become a more ubiquitous network, driven 174 by the low prices of wireless routers and access points and by the 175 users' requirements of connectivity anytime and anywhere. For that 176 reason, a cloud of nodes connected by wireless technology is being 177 created at the edge of the Internet. This cloud is called a MANEMO 178 Fringe Stub (MFS) in [18]. Examples of wireless technologies used 179 within a MFS are wireless metropolitan and local area network 180 protocols (WiMAX, WLAN, 802.20, etc), short distance wireless 181 technology (bluetooth, IrDA, UWB), and radio mesh networks (e.g., 182 802.11s). It is expected that networking in the MFS will be highly 183 unmanaged and ad-hoc, but at the same time will need to offer 184 excellent service availability. 186 The NEMO Basic Support protocol [5] could be used to provide global 187 reachability for a mobile access network within the MFS. 188 Analogously, the Tree-Discovery mechanism [6] could be used to avoid 189 the formation of loops in this highly unmanaged structure. However, 190 even with these two technologies in place, packet delivery within the 191 MFS can still be highly inefficient. Since Internet connectivity in 192 mobile scenarios can be costly, limited or unavailable, there is a 193 need to enable local routing between the Mobile Routers within a 194 portion of the MFS. NINA can provide this form of local routing; it 195 is an example of Route Optimization (RO) between Mobile Routers that 196 are communicating directly in a portion of the MFS. 198 4. Rationale for the proposed solution 200 4.1. Why ND based 202 NINA extends the Neighbor Discovery protocol to address the MANEMO 203 requirements listed in [18], although MANET protocols [12], [15], 204 [16] provides similar features such as local routing and Internet 205 access over multihop. 207 One of the drawbacks of MANET protocols is the question of which 208 protocol should be used. AODV, DSR, DYMO, OLSR, etc. are 209 standardized in IETF and each has distinct features, like proactive 210 and reactive. In MANEMO scenarios, Mobile Routers, mobile hosts, and 211 fixed access routers are involved, and therefore, it is highly 212 important to deploy a consistent protocol in the network. On the 213 other hand, ND is a core component of IPv6 and is supported by all 214 IPv6 nodes. All IPv6 nodes can process a NINO(s) in ND messages if 215 desired. 217 MANEMO does not require full link states of a network as OLSR does, 218 it only requires path to and from the exit router (tree root) in the 219 tree fashion. Flooding the entire network with route information is 220 a redundant process and its overhead is not negligible. ND simply 221 carries prefix information to setup the path from the tree root to 222 each mobile router/node. 224 4.2. Why NA based 226 Since an MR appears as a host on the egress interface side, it is 227 legitimate to use NA in the visited network. There are two reasons 228 for that: 230 o If an MR advertises itself as a router in the visited network 231 using RA, it might get used as a default router by Local Fixed 232 Nodes (LFNs) attached to the visited network and cause trouble. 234 o By using NINA, the whole part of the fringe behind the MR has the 235 footprint of a single host from the visited network standpoint 236 (and moves as a single host). 238 By using NINA on top of a TD established tree, MANEMO can be made to 239 reproduce the NEMO behavior for a whole subtree by reducing to a 240 single host footprint, and retain NEMO compatibility by avoiding 241 spurious RAs. Thus, a whole subtree can move within the fringe as a 242 single host. 244 4.3. Relationship with TD 246 NINA exploits the loop-less cluster established by Tree Discovery, so 247 it does not need to provide loop avoidance. 249 With TD, MRs setup a default route up the tree via the parent Access 250 Router, and all the packets are directed by default towards the 251 clusterhead (Top Level Mobile Router or root-MR in NEMO terms). To 252 provide complete reachability, it is enough for NINA to expose the 253 prefixes down the tree from any given MR, while propagating prefixes 254 information up the tree. 256 This allows an extreme conciseness of the routing information, with 257 no topological knowledge past the first hop. That conciseness 258 enables a high degree of movement within the nested structure; in 259 particular, a movement within a subtree is not seen outside of that 260 subtree, so most of the connectivity is maintained at all times while 261 there might never be such a thing as a convergence. 263 4.4. Relationship with NEMO 265 The Reverse Routing Header (RRH) described in [17] operates in the 266 nested NEMO as a layer 3 Source Route Bridging (SRB) technique for 267 nested NEMO Route Optimization. It allows a quick reaction to inner 268 movements with the resolution of the packet; but the cost, an IPv6 269 address per packet per hop, might be deemed excessive. 271 Also, the Home Agent needs to cache the RRH in its binding cache, and 272 again, the overhead might be significant for a large deployment. 274 On the other hand, NINA establishes states in the intermediate nodes, 275 in a fashion similar to Transparent Bridging (TB), but at layer 3. 276 The integration of these 2 approaches allows switching between SRB to 277 TB models dynamically as the NINA states are populated or become 278 obsolete. To obtain this capability, the operation of an 279 intermediate MR described in [17] is altered in the following manner: 281 o If the MR has a (NINA) route to the upper entry in the RRH via the 282 source of the packet, it still updates the source of the packet 283 with its own Care-of Address, but does not save the previous 284 source as a new entry in the RRH. 286 o At best, if NINA has established states all along in a given 287 branch of the tree, the RRH for that branch has always 2 entries, 288 the first MR's Home Address, and its Care-of Address, regardless 289 of the depth of the first MR in the nested NEMO. 291 o When some MRs in the tree support NINA and some do not, the 292 resulting RRH will be only partly compressed. Also, if the NINA 293 route does not match the RRH, then the route is obsolete and the 294 source address is added to the RRH as described in [17], in order 295 to ensure a correct routing on the way back. When NINA catches 296 up, the entry will be saved again. 298 The integration of NINA and RRH can offer the best of 2 worlds: a 299 quick (per packet) resolution to the network changes, and the 300 transparent (stateful) operation when the NINA routing protocol 301 establishes the states in the nested NEMO. 303 5. Overview 305 This section provides an overview of the operation of NINA to set-up 306 MNP route state in a nested-NEMO scenario. 308 5.1. Nested NEMO 310 NINA requires the Tree Discovery protocol to build and maintain a 311 tree topology. It relies on TD to discover that a change occurs in a 312 sub-tree of the topology, and that change triggers a flow of route 313 updates for that sub-tree in the topology. 315 +---------------------+ 316 | Internet |---CN 317 +---------------|-----+ 318 / Access Router 319 MR3_HA | 320 ======?====== 321 MR1 322 | 323 ====?=============?==============?=== 324 MR5 MR2 MR6 325 | | | 326 =========== ===?========= ============= 327 MR3 328 | 329 ==|=========?== 330 LFN1 MR4 331 | 332 ========= 334 Figure 1: Nested NEMO scenario 336 Each tree that TD self-forms is considered a separate routing 337 topology. If a Mobile Router belongs to multiple of such topologies, 338 then it is expected that both the NINA signaling and the data packets 339 are flagged to follow the topology for which the packet was 340 introduced in the network. 342 NINA expects a Mobile Router to own one or more Mobile Network 343 Prefix(es) that move with the MR. With that model, it is assumed 344 that there is a single source for the advertisement of a given prefix 345 within a topology. If multiple MRs share a given MNP, some protocol 346 must take place between those MRs to make sure that one and only one 347 MR advertises a given prefix in a given tree. 349 Tree Discovery formats the nested NEMO into a loop-less logical 350 graph, thus providing loop avoidance for the NINA protocol. Each 351 time a movement occurs, TD restores the loop-less structure before 352 NINA can operate again and repaint the graph with prefixes. 354 The root-MR of a nested NEMO is selected for a number of properties, 355 the primary one being an access to the wired infrastructure. It is 356 the default sink for every node in the tree. 358 More generally, the default gateway for a Mobile Router is its parent 359 up in the tree; the more specific routes, towards the Mobile Network 360 Prefixes, are always oriented down the tree, and NINA advertisements 361 flow up the tree towards the root-MR. 363 Each NINO contains a prefix and a sequence counter. The Mobile 364 Router that owns the prefix generates the NINO for that prefix, 365 including the sequence counter associated to that prefix and that is 366 incremented each time it generates a new NINO. 368 Due to a movement, a sub-tree can be temporarily out of sequence and 369 a NINO can be received from a sub-tree where the MR was but is no 370 more, until the parents realize it is gone. But by construction of 371 the tree, there can be a single route to a given prefix, so older 372 information is always invalid. 374 A parent-MR maintains a state for each prefix it learns from NINA. 375 In particular, the last sequence number is kept. An out-of-sequence 376 NINO must be disregarded. If the NINO appears valid, it is forwarded 377 to the parent's parent in the next burst, carried by a NINA, together 378 with the parent's own prefixes. 380 6. Message Formats 382 6.1. NINA message 384 NINA extends Neighbor Discovery [2] and RFC 4191 [7] to allow an MR 385 include a prefix option in the Neighbor Advertisements (NAs). The NA 386 is a necessary exchange that allows the AR to map the IPv6 address of 387 a node with its L2 address. The prefix option is normally present in 388 Router Advertisements (RAs) only. The meaning of such an option in a 389 NA is the concept of 'network in node', so we refer to this new ND 390 option as NINO (Network In Node Option) and we name the resulting 391 message NINA (Network In Node Advertisement). 393 When Tree Discovery is used to build a tree, there can be a single 394 route to a given prefix along that tree, so the freshest information 395 is always the best for unicast routes. In order to track that, the 396 NINO includes a sequence counter to the prefix advertisement. 398 The sequence counter is incremented by the source of the NINO, that 399 is the Mobile Router that owns the MNP, each time it issues a NINA, 400 and then forwarded as is up the tree. A depth is also added for 401 tracking purposes; the depth is incremented at each hop as the NINO 402 is propagated up the tree. 404 On an egress interface, if NINA is configured, the MR: 406 o selects an Access Router (AR) as its point of attachment to the 407 network 409 o auto-configures a Care-of Address (CoA) 411 o acts as a host as opposed to a router. In particular, it refrains 412 from sending RAs 414 o sends NINAs, as unicast, to its AR only 416 o accepts unicast NINAs from any node BUT its AR 418 On an ingress interface, if NINA is configured, the MR: 420 o acts as a router, may accept visitors 422 o sends RAs with the Tree Information Option (RA-TIO) 424 o accepts NINAs from any node 426 Every NA to the AR contains a NINO. In particular, receiving a Tree 427 Discovery RA-TIO from the AR stimulates the sending of a delayed NINA 428 back, with the collection of all known prefixes (that is the prefixes 429 learned from NINO and the connected prefixes). A NINA is also sent 430 to the AR once it has been selected as new AR after a movement, or 431 when the list of advertised prefixes has changed. 433 NINA may advertise positive (prefix is present) or negative (removed) 434 NINOs. A no-NINO is stimulated by the disappearance of a prefix 435 below. This is discovered by timing out after a request (a RA-TIO) 436 or by receiving a no-NINO. A no-NINO is a NINO with a NINO Lifetime 437 of 0. 439 0 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Type | Length | Prefix Length |L| Reserved1 |4| 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | NINO Lifetime | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Reserved2 | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | NINO Depth | Reserved3 | NINO Sequence | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | | 451 + + 452 | | 453 + Prefix (Variable Length) + 454 | | 455 + + 456 | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Type: 461 NINO (number to be assigned by IANA). 463 Length: 465 8-bit unsigned integer. The length of the option (including the 466 Type and Length fields) in units of 8 octets. 468 Prefix Length: 470 Number of valid leading bits in the IPv6 Prefix. 472 Reserved1: 474 6-bit unused field. It MUST be initialized to zero by the sender 475 and MUST be ignored by the receiver. 477 'L' bit: 479 Indicates that the prefix or address is on-link as opposed to 480 another interface of the MR. This is useful for a child MR to 481 expose its IPv4 address on its egress interface. In that case, 482 the parent can set up forwarding to all the IPv4 prefixes in the 483 NINA via that address on this link. 485 '4' bit: 487 Indicates that the Prefix field carries an IPv4 mapped address. 489 NINO Lifetime: 491 32-bit unsigned integer. The length of time in seconds (relative 492 to the time the packet is sent) that the prefix is valid for route 493 determination. A value of all one bits (0xFFFFFFFF) represents 494 infinity. A value of all zero bits (0x00000000) indicates a loss 495 of reachability. 497 Reserved2: 499 32-bit unused field. It MUST be initialized to zero by the sender 500 and MUST be ignored by the receiver. 502 NINO Depth: 504 Set to 0 by the MR that owns the MNP and issues the NINO. 505 Incremented by all MRs that propagate the NINO. 507 Reserved3: 509 8-bit unused field. It MUST be initialized to zero by the sender 510 and MUST be ignored by the receiver. 512 NINO Sequence: 514 Incremented by the MR that owns the MNP for each new NINO for that 515 prefix. Left unchanged by all MRs that propagate the NINO. A 516 lollipop mechanism is used to wrap from 0xFFFF directly to 10. 518 Prefix: 520 Variable-length field containing an IPv6 address or a prefix of an 521 IPv6 address. The Prefix Length field contains the number of 522 valid leading bits in the prefix. The bits in the prefix after 523 the prefix length (if any) are reserved and MUST be initialized to 524 zero by the sender and ignored by the receiver. 526 6.2. NINO IPv4 option 528 NINA is defined for both IPv4 and IPv6 address families. 530 For IPv4, a new NINO IPv4 option is introduced to be included in RA 531 and NA messages, for a node to advertise its IPv4 address on the 532 interface where the ND message is issued. 534 The NINO IPv4 option can be included in an RA by the sending router 535 to expose its IPv4 address to the attached visitors, so they can 536 install a default route via that address and use the sending router 537 as default gateway. 539 The option can also be included in a NA by a visiting node to expose 540 its IPv4 address to the Attachment Router; this address is used as 541 next hop by the AR as it installs routes via the visiting node 542 towards the IPv4 prefixes contained in the NINOs and passed as mapped 543 addresses in the NA message. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Type | Length | Reserved | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | IPv4 address on sending interface | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Type: 555 NINO IPv4 (number to be assigned by IANA). 557 Length: 559 8-bit unsigned integer. The length of the option (including the 560 Type and Length fields) in units of 8 octets. 562 Reserved: 564 8-bit unused field. It MUST be initialized to zero by the sender 565 and MUST be ignored by the receiver. 567 IPv4 address on sending interface: 569 32-bit field containing the IPv4 address of the sending interface. 571 7. Mobile Router Operation 573 The Mobile Router operation is autonomous, based on the information 574 provided by the potential Access Routers in sight. Each MR selects 575 an AR (a MAR) in a loop-less and case-optimized fashion, and installs 576 a default route up the tree via the selected AR. The resulting tree 577 (the cluster) may never be globally stable enough to be mapped in a 578 global graph. So the adaptation to local movements must be rapid and 579 localized. 581 For NEMO flows, the Reverse Routing Header allows the update to the 582 path on a per packet basis. Hopefully, the root of the tree (the 583 clusterhead) is connected to the infrastructure where Home can be 584 reached, and can be used as a gateway to discover Home. When the 585 NEMO tunnel is established, it becomes the default route for the MR. 587 If the tree is not connected to the infrastructure or in any case if 588 Home can not be reached, MRs need an ad-hoc protocol to establish 589 local connectivity. This specification takes advantage of the TD 590 cluster and allows an MR to discover the prefixes below itself. 592 NINA information can be redistributed in a routing protocol, MANET or 593 IGP. But the MANET or the IGP SHOULD NOT be redistributed into NINA. 594 This creates a hierarchy of routing protocols where NINA routes stand 595 somewhere between connected and IGP routes. 597 NINA also allows a compression of the Reverse Routing header when the 598 routes match the topology as traced by RRH on a per packet basis. In 599 particular, if a NINA route exists to the first entry in the RRH via 600 the source of the packet, then the MR can override the source of the 601 packet with its own CoA without adding the original source to the 602 RRH. At that point, the RRH operation becomes loose, in other words 603 an hybrid between transparent (stateful) and source routing. 605 As a result: 607 o Tree Discovery establishes a tree using extended Neighbor 608 Discovery RS/RA flows. 610 o The NEMO Basic Support protocol exploits the tree to get optimally 611 out of a nested set of MRs and register Home. 613 o RRH extends the NEMO Basic Support to provide Route Optimization 614 and faster path reestablishment. 616 o NINA also extends Neighbor Discovery in order to establish quickly 617 the routes down the cluster. 619 NINA maintains abstract lists of known prefixes. A prefix entry 620 contains the following abstract information: 622 o The state of the entry: ELAPSED, PENDING, or CONFIRMED. 624 o A reference to the adjacency that was created for that prefix. 626 o A reference to the ND entry that was created for the advertiser 627 Neighbor. 629 o The IPv6 address of the advertiser Neighbor. 631 o The logical equivalent of the full NINA information. 633 o A reference to the interface of the advertiser Neighbor. 635 o A 'reported' Boolean to keep track whether this prefix was 636 reported already to the parent AR. 638 o A counter of retries to count how many RA-TIOs were sent on the 639 interface to the neighbor without reachability confirmation for 640 the prefix. 642 NINA stores the prefix entries in either one of 3 abstract lists; the 643 Connected, the Reachable and the Unreachable lists. 645 The Connected list corresponds to the MNP of the Mobile Router. 647 As long as an MR keeps receiving NINOs for a prefix timely, its 648 prefix entry is listed in the Reachable list. 650 Once scheduled to be destroyed, a prefix entry is moved to the 651 Unreachable list if the MR has a parent to which it sends NINOs, 652 otherwise the entry is cleaned up right away. The entry is removed 653 from the Unreachable list when the parent changes or when a no-NINO 654 is sent to the parent indicating the loss of the prefix. 656 NINA requires 2 timers; the DelayNA timer and the DestroyTimer. 658 o The DelayNA timer is armed upon a stimulation to send a NINA (such 659 as a TIO from the AR). When the timer is armed, all entries in 660 the Reachable list as well as all entries for Connected list are 661 set to not reported yet. 663 o The DelayNA timer has a duration that is DEF_NA_LATENCY divided by 664 2 with the tree depth. 666 o The DestroyTimer is armed when at least one entry has exhausted 667 its retries, which means that a number of RA-TIO were sent over 668 the ingress interface but that the entry was not confirmed with a 669 NINO. When the destroy timer elapses, for all exhausted entries, 670 the associated route is removed, and the entry is scheduled to be 671 destroyed. 673 o The Destroy timer has a duration of min (MAX_DESTROY_INTERVAL, 674 RA_INTERVAL). 676 7.1. Multicast TD RA messages from parent 678 When ND sends a NA to the AR, NINA extends the message with prefix 679 options for: 681 o All the prefixes that are not 'DELETED' for all the ingress 682 interfaces. 684 o All the prefixes in the removed list as no-NINO. 686 o All the prefixes in the advertised list that are not reported yet. 687 The entries are set to reported. 689 When ND receives a NA from a visitor over an ingress interface, NINOs 690 are processed in a loop. For known prefixes, the sequence counter in 691 the NINO is checked against the last received and the update is used 692 only if the sequence is newer. This filters out obsolete 693 advertisements when a prefix has moved between 2 subtrees attached to 694 a same node. 696 If a prefix is advertised as a no-NINO, the associated route is 697 removed, and the entry is transferred to the removed list. 698 Otherwise, the route table is looked up: 700 o If a preferred route to that prefix from another protocol already 701 exists, the prefix is ignored. 703 o If a new route can be created, a new prefix entry is allocated to 704 track it, as CONFIRMED, but not reported. 706 o If a NINA route existed already via the same Neighbor, it is 707 CONFIRMED. 709 o If a NINA route existed via a different Neighbor, this is 710 equivalent to a no-NINO for the previous entry followed by a new 711 NINO for the new entry. So the old entry is scheduled to be 712 destroyed, whereas the new one is installed. 714 7.2. Unicast NINA messages from child to parent 716 When sending NINA to its parent, an MR includes the NINOs about not 717 already reported prefix entries in the Reachable and Connected lists, 718 as well as no-NINOs for all the entries in the Unreachable list. 719 Depending on its policy, the receiving MR SHOULD install a route to 720 the prefix in the NINO via the link local address of the source MR 721 and it SHOULD propagate the information, either as a NINO or by means 722 of redistribution into a routing protocol. 724 The RA-TIO from the root-MR is used to synchronize the whole tree. 725 Its period is expected to range from 500ms to hours, depending on the 726 stability of the configuration and the bandwidth available. 728 When an MR receives a RA-TIO over an egress interface from the 729 current parent AR, the DelayNA is armed to force a full update. As 730 described in [6] the MR also issues a propagated RA-TIO over all its 731 ingress interfaces, after a small jitter that aims at minimizing 732 collisions of RA-TIO messages over the radio as it is propagated down 733 the tree. 735 The design choice behind this is NOT TO synchronize the parent and 736 children databases, but instead to update them regularly to cover 737 from the loss of packets. The rationale for that choice is movement. 738 If the topology can be expected to change frequently, synchronization 739 might be an excessive goal in terms of exchanges and protocol 740 complexity. This results in a simple protocol with no real peering. 742 When the MR sends a RA-TIO over an ingress interface, for all entries 743 on that interface: 745 o If the entry is CONFIRMED, it goes PENDING with the retry count 746 set to 0. 748 o If the entry is PENDING, the retry count is incremented. If it 749 reaches a maximum threshold, the entry goes ELAPSED If at least 750 one entry is ELAPSED at the end of the process: if the Destroy 751 timer is not running then it is armed with a jitter. 753 Since the DelayNA has a duration that decreases with the depth, it is 754 expected to receive all NINOs from all children before the timer 755 elapses and the full update is sent to the parent. 757 7.3. Other events 759 Finally, NINA listens to a series of events, such as: 761 o MR stopped or unable to run: NINA routes are cleaned up. NINA is 762 inactive. 764 o NINA operation stopped: All entries in the abstract lists are 765 freed. All the NINA routes are destroyed. 767 o Interface going down: for all entries in the Reachable list on 768 that interface, the associated route is removed, and the entry is 769 scheduled to be destroyed. 771 o Neighbor being removed from the ND list: if the entry is in the 772 Reachable list the associated route is removed, and the entry is 773 scheduled to be destroyed. 775 o Roaming: All entries in the Reachable list are set to not 776 'reported' and DelayNA is armed. 778 7.4. Aggregation of prefixes on a same MR 780 When deploying an MR with multiple ingress interfaces, it makes sense 781 to affect an aggregation prefix (shorter than /64) to the MR and 782 partition it as /64 prefixes over the MR interfaces. An MR that owns 783 a contiguous set of prefixes should only report the aggregation of 784 these prefixes through NINA. 786 7.5. Aggregation of prefixes by a parent acting as mobile Home 788 There are also a number of cases where a mobile aggregation is shared 789 within a toon of Mobile Routers. For instance, a toon formed by 790 firefighters and their commander. In that case, it is still possible 791 to use aggregation techniques with NINA and improve its scalability. 792 In that case, the commander is configured as the NINA aggregator for 793 the group prefix. In run time, it absorbs the individual NINO 794 information it receives from the toon members down its subtree and 795 only reports the aggregation up the TD tree. This works fine when 796 the whole toon is attached within the commander's subtree. 798 But other cases might occur for which additional support is required: 800 1. the commander is attached within the subtree of one of its toon 801 members. 803 2. A toon member is somewhere else within the TD tree. 805 3. A toon member is somewhere else in the Internet. 807 In all those cases, a node situated above the commander in the TD 808 tree but not above the toon member will see the advertisements for 809 the aggregation owned by the commander but not that of the individual 810 toon member prefix. So it will route all the packets for the toon 811 member towards the commander, but the commander will have no route to 812 the toon and will fail to forward. 814 Section 8 'Mobile Home' of RFC 4887 [20] proposes a deployment model 815 where a Mobile Router would also act as Home Agent for a mobile 816 aggregation. This method can be used in the general case 3 to ensure 817 routability to the toon member. With that method, the Home Link for 818 a toon member should be one of the commander links. The Tree 819 Discovery plug-in should favor that link so that many toon members 820 actually attach at Home. 822 If a toon member is not at Home, then it will register to its Home 823 Agent using NEMO basic support (RFC 3963 [5]). Depending of the 824 location of a source, a packet to the toon member will either go 825 directly to it, or go to its commander. If the toon member as a 826 Mobile Router is registered to its commander as its Home Agent, the 827 commander can always encapsulate the packet to the CoA of the toon 828 member using NEMO, and ensure reachability to the MR. 830 Section 2.7 of RFC 4888 [21] explains that in the specific case of 831 case 1), the commander will not be able to reach Home using plain 832 NEMO basic support, and an additional mechanism such as RRH ([17]) is 833 required to fix that issue. 835 Also specifically in case 1), the toon member will refrain from 836 adding the NINO options for its own prefixes that are aggregated in 837 the NINO option of its commander that it propagates up the TD tree. 839 7.6. Default value 841 DEF_NA_LATENCY = 150 ms 843 MAX_DESTROY_INTERVAL = 200ms 845 8. Privacy Considerations 847 It is already possible for a visiting Mobile Node (Mobile Router) to 848 autoconfigure an address that will not identify the visitor [22], 849 [13]. It is also possible for a visitor to roll its CoA periodically 850 even when it stays attached to a same point, and register the new 851 addresses as it forms them. 853 CIA (Capability, Innocuousness and Anonymity) properties demand also 854 that the visited party might not be identified by the visitor. To 855 achieve that, a Mobile Router should not advertise its MNPs on its 856 links open to untrusted visitors. 858 This draft recommends that the interface that is open for untrusted 859 visitors uses unique local addresses (RFC 4193 [8]) and rolls the 860 advertised prefixes with a short lifetime. This can be achieved for 861 instance by obtaining short lived leases from the Home Agent using 862 DHCP-PD [23]. 864 Another possibility is to use strict RRH routing [17]; in that case, 865 the prefix that is presented on the link can be taken from anywhere 866 in the ULA range since it is not used for routing outside the link. 868 Alternatively, a global unique prefix obtained from an autoconf 869 solution [24], [25] or DHCPv6 prefix delegation [9] can be used as 870 well. 872 9. IANA Considerations 874 This document requires IANA to assign a number for a new ND option 875 type (NINO NA). 877 10. Security Considerations 879 Exposing the MRs' MNPs within the MFS introduces several security 880 threats that should be carefully tackled, mainly derived from the 881 fact that MRs are distributing prefixes (i.e., their MNPs) that are 882 not topologically correct within the MFS. 884 To avoid these security issues -- that might enable malicious nodes 885 to steal traffic addressed to other nodes (by spoofing their 886 prefixes) -- Mobile Routers should be provided with some security 887 mechanisms, ensuring that an MR that is advertising a certain MNP is 888 actually authorized to do that. 890 The use of L2 trusts and policies, SeND or preconfigured security 891 relationships might help in securing the mechanism described in this 892 draft. Additionally, if MRs have connectivity with their Home 893 Agents, a modified Return Routability mechanism -- extended to 894 support prefix checks (such as [26] or [27]) -- may be used to 895 provide the required authorization, before starting to use the RO 896 shortcut within the MFS. 898 11. Acknowledgments 900 We would like to thank all the people who have provided comments on 901 this draft, specially to Ben McCarthy for his very helpful review of 902 this document. 904 12. References 906 12.1. Normative References 908 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 909 Levels", BCP 14, RFC 2119, March 1997. 911 [2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 912 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 913 September 2007. 915 [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 916 August 2002. 918 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 919 IPv6", RFC 3775, June 2004. 921 [5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 922 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 923 January 2005. 925 [6] Thubert, P., "Nested Nemo Tree Discovery", 926 draft-thubert-tree-discovery-06 (work in progress), July 2007. 928 [7] Draves, R. and D. Thaler, "Default Router Preferences and More- 929 Specific Routes", RFC 4191, November 2005. 931 [8] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 932 Addresses", RFC 4193, October 2005. 934 [9] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 935 Configuration Protocol (DHCP) version 6", RFC 3633, 936 December 2003. 938 12.2. Informative References 940 [10] Manner, J. and M. Kojo, "Mobility Related Terminology", 941 RFC 3753, June 2004. 943 [11] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): 944 Routing Protocol Performance Issues and Evaluation 945 Considerations", RFC 2501, January 1999. 947 [12] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing 948 Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728, 949 February 2007. 951 [13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 952 Neighbor Discovery (SEND)", RFC 3971, March 2005. 954 [14] Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc 955 Network Architecture", draft-ietf-autoconf-manetarch-07 (work 956 in progress), November 2007. 958 [15] Clausen, T., "The Optimized Link State Routing Protocol version 959 2", draft-ietf-manet-olsrv2-04 (work in progress), July 2007. 961 [16] Clausen, T., Dearlove, C., and J. Dean, "MANET Neighborhood 962 Discovery Protocol (NHDP)", draft-ietf-manet-nhdp-05 (work in 963 progress), December 2007. 965 [17] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 966 its application to Mobile Networks", 967 draft-thubert-nemo-reverse-routing-header-07 (work in 968 progress), February 2007. 970 [18] Wakikawa, R., "Problem Statement and Requirements for MANEMO", 971 draft-wakikawa-manemo-problem-statement-01 (work in progress), 972 July 2007. 974 [19] Ernst, T. and H-Y. Lach, "Network Mobility Support 975 Terminology", RFC 4885, July 2007. 977 [20] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network 978 Mobility Home Network Models", RFC 4887, July 2007. 980 [21] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network Mobility 981 Route Optimization Problem Statement", RFC 4888, July 2007. 983 [22] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions 984 for Stateless Address Autoconfiguration in IPv6", RFC 4941, 985 September 2007. 987 [23] Droms, R. and P. Thubert, "DHCPv6 Prefix Delegation for NEMO", 988 draft-droms-nemo-dhcpv6-pd-02 (work in progress), April 2005. 990 [24] Baccelli, E., Mase, K., Ruffino, S., and S. Singh, "Address 991 Autoconfiguration for MANET: Terminology and Problem 992 Statement", draft-ietf-autoconf-statement-03 (work in 993 progress), January 2008. 995 [25] Bernardos, C., Calderon, M., and H. Moustafa, "Survey of IP 996 address autoconfiguration mechanisms for MANETs", 997 draft-bernardos-manet-autoconf-survey-02 (work in progress), 998 October 2007. 1000 [26] Ng, C., "Extending Return Routability Procedure for Network 1001 Prefix (RRNP)", draft-ng-nemo-rrnp-00 (work in progress), 1002 October 2004. 1004 [27] Bernardos, C., Soto, I., Maria, M., Fernando, F., and A. 1005 Arturo, "VARON: Vehicular Ad hoc Route Optimisation for NEMO", 1006 Computer Communications, vol. 30, pp. 1765-1784 , 2007. 1008 Appendix A. Change Log 1010 Changes from -01 to -02: 1012 o NINA IPv4 support: added IPv4 NINO ND option. 1014 o References updated. 1016 o Updated the location of the 'L' bit in the NINO NA option, to 1017 match format of RFC 4861. 1019 Changes from -00 to -01: 1021 o Basic kiss (MR to MR over egress) sections removed. 1023 o Added sections about aggregation of prefixes. 1025 o Added Privacy consideration section. 1027 o NINO NA message format changed. 1029 o Some text cleanups. 1031 Authors' Addresses 1033 Pascal Thubert 1034 Cisco Systems 1035 Village d'Entreprises Green Side 1036 400, Avenue de Roumanille 1037 Batiment T3 1038 Biot - Sophia Antipolis 06410 1039 FRANCE 1041 Phone: +33 4 97 23 26 34 1042 Email: pthubert@cisco.com 1044 Ryuji Wakikawa 1045 Keio University and WIDE 1046 5322 Endo Fujisawa Kanagawa 1047 252-8520 1048 JAPAN 1050 Email: ryuji@sfc.wide.ad.jp 1052 Carlos J. Bernardos 1053 Universidad Carlos III de Madrid 1054 Av. Universidad, 30 1055 Leganes, Madrid 28911 1056 Spain 1058 Phone: +34 91624 6236 1059 Email: cjbc@it.uc3m.es 1061 Roberto Baldessari 1062 NEC Europe Network Laboratories 1063 Kurfuersten-anlage 36 1064 Heidelberg 69115 1065 Germany 1067 Phone: +49 6221 4342167 1068 Email: roberto.baldessari@netlab.nec.de 1069 Jean Lorchat 1070 Keio University and WIDE 1071 5322 Endo Fujisawa Kanagawa 1072 252-8520 1073 JAPAN 1075 Email: lorchat@sfc.wide.ad.jp 1077 Full Copyright Statement 1079 Copyright (C) The IETF Trust (2008). 1081 This document is subject to the rights, licenses and restrictions 1082 contained in BCP 78, and except as set forth therein, the authors 1083 retain all their rights. 1085 This document and the information contained herein are provided on an 1086 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1087 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1088 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1089 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1090 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1091 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1093 Intellectual Property 1095 The IETF takes no position regarding the validity or scope of any 1096 Intellectual Property Rights or other rights that might be claimed to 1097 pertain to the implementation or use of the technology described in 1098 this document or the extent to which any license under such rights 1099 might or might not be available; nor does it represent that it has 1100 made any independent effort to identify any such rights. Information 1101 on the procedures with respect to rights in RFC documents can be 1102 found in BCP 78 and BCP 79. 1104 Copies of IPR disclosures made to the IETF Secretariat and any 1105 assurances of licenses to be made available, or the result of an 1106 attempt made to obtain a general license or permission for the use of 1107 such proprietary rights by implementers or users of this 1108 specification can be obtained from the IETF on-line IPR repository at 1109 http://www.ietf.org/ipr. 1111 The IETF invites any interested party to bring to its attention any 1112 copyrights, patents or patent applications, or other proprietary 1113 rights that may cover technology that may be required to implement 1114 this standard. Please address the information to the IETF at 1115 ietf-ipr@ietf.org. 1117 Acknowledgment 1119 Funding for the RFC Editor function is provided by the IETF 1120 Administrative Support Activity (IASA).