idnits 2.17.1 draft-thubert-nina-00.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 1054. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1065. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1078. 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 26, 2007) is 6262 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-04 -- Possible downref: Normative reference to a draft: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '7') ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '8') == Outdated reference: A later version (-19) exists of draft-ietf-manet-olsrv2-02 == Outdated reference: A later version (-15) exists of draft-ietf-manet-nhdp-01 == Outdated reference: A later version (-01) exists of draft-wakikawa-manemo-problem-statement-00 Summary: 6 errors (**), 0 flaws (~~), 5 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: August 30, 2007 Keio University 6 C. Bernardos 7 UC3M 8 R. Baldessari 9 NEC Europe 10 J. Lorchat 11 Keio University 12 February 26, 2007 14 Network In Node Advertisement 15 draft-thubert-nina-00.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 30, 2007. 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 NINA is the second of a 2-passes routing protocol; a first pass, Tree 66 Discovery, builds a loop-less structure -a tree-, and the second 67 pass, NINA, exposes the Mobile Network Prefixes (MNPs) up the tree. 68 The protocol operates as a multi-hop extension of Neighbor Discovery 69 (ND), to populate TD-based trees with prefixes, and establish routes 70 towards the MNPs down the tree, from the root-MR towards the MR that 71 owns the prefix, whereas the default route is oriented towards the 72 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. Basic kiss (MR to MR over egress) . . . . . . . . . . . . 10 94 5.2. Nested NEMO . . . . . . . . . . . . . . . . . . . . . . . 11 95 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 96 6.1. All MANEMO Mobile Routers multicast address . . . . . . . 13 97 6.2. NINO NA option . . . . . . . . . . . . . . . . . . . . . . 13 98 6.3. NINO NS option . . . . . . . . . . . . . . . . . . . . . . 17 99 7. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 19 100 7.1. NINA messages between siblings . . . . . . . . . . . . . . 21 101 7.2. Multicast TD RA messages from parent . . . . . . . . . . . 21 102 7.3. Unicast NINA messages from child to parent . . . . . . . . 22 103 7.4. Other events . . . . . . . . . . . . . . . . . . . . . . . 23 104 7.5. Default value . . . . . . . . . . . . . . . . . . . . . . 23 105 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 106 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 107 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 109 11.1. Normative References . . . . . . . . . . . . . . . . . . . 27 110 11.2. Informative References . . . . . . . . . . . . . . . . . . 27 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 112 Intellectual Property and Copyright Statements . . . . . . . . . . 31 114 1. Introduction 116 Mobile IP [3] allows transparent routing of IPv4 datagrams to mobile 117 nodes in the Internet. Mobile IPv6 (MIPv6) [4] extends this facility 118 for IPv6, and NEMO [5] enables it for mobile prefixes. In any case, 119 a mobile node is always identified by its Home Address (HoA), 120 regardless of its current point of attachment to the Internet. In 121 turn, MANET [11] allows a set of unrelated nodes and routers to 122 discover their peers and establish communication. 124 Mobile Routers (MRs) may attach to other MRs and form a Care-of 125 Address (CoA) from a Mobile Network Prefix (MNP). As a result, MRs 126 are really MARs, Mobile Access Routers, because they can accept 127 connections from other MRs on their ingress interfaces. When Mobile 128 Routers attach to other Mobile Routers with a single Care-of Address 129 in a loop-less manner, they end up building trees. This process is 130 described in Tree Discovery (TD) [6]. 132 This draft provides a minimum extension to IPv6 Neighbor Discovery 133 (ND) Neighbors Advertisements (NA) - called NINA (Network In Node 134 Advertisement) - extending RFC 4191 [9] to add the capability to 135 include a prefix option - called NINO (Network In Node Option) - in 136 the NAs. This enables an MR to learn the prefixes of all other MRs 137 down its sub-tree. Note that NINO is pronounced NEE-GNO and NINA is 138 pronounced NEE-GNA. 140 A NEMO Mobile Router has a double behavior. On its egress 141 interfaces, which are used to backhaul the traffic to the Home 142 Network and the rest of the Internet, it is seen as a Mobile Node 143 (MN), performing the IPv6 and MIPv6 host-required features such as 144 neighbor and router discovery [2]. On the (ingress) interfaces to 145 the Mobile Networks, the Mobile Router behaves as an IPv6 router with 146 support of the MIPv6 requirements on routers. This is why TD [6] 147 extends ND RA over the ingress interface of a Mobile Router whereas 148 NINA extends ND NAs to advertise over the egress interface the 149 prefixes that are reachable via the MR. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [1]. 157 Readers are expected to be familiar with all the terms defined in the 158 RFC 3753 [7], the NEMO Terminology draft [8] and the MANEMO Problem 159 Statement draft [17]. 161 NINO (Network In Node Option): a new Neighbor Discovery (ND) 162 option that adds the capability to include a prefix option in 163 Neighbor Advertisements (NAs) and Solicitations (NSs). 165 NINA (Network In Node Advertisement): a Neighbor Discovery (ND) 166 Neighbor Advertisement (NA) carrying a NINO. NINA is also used to 167 refer to the protocol itself (defined in this document). 169 3. Motivations 171 The Internet is evolving to become a more ubiquitous network, driven 172 by the low prices of wireless routers and access points and by the 173 users' requirements of connectivity anytime and anywhere. For that 174 reason, a cloud of nodes connected by wireless technology is being 175 created at the edge of the Internet. This cloud is called a MANEMO 176 Fringe Stub (MFS) in [17]. Examples of wireless technologies used 177 within a MFS are wireless metropolitan and local area network 178 protocols (WiMAX, WLAN, 802.20, etc), short distance wireless 179 technology (bluetooth, IrDA, UWB), and radio mesh networks (e.g., 180 802.11s). It is expected that networking in the MFS will be highly 181 unmanaged and ad-hoc, but at the same time will need to offer 182 excellent service availability. 184 The NEMO Basic Support protocol [5] could be used to provide global 185 reachability for a mobile access network within the MFS. 186 Analogously, the Tree-Discovery mechanism [6] could be used to avoid 187 the formation of loops in this highly unmanaged structure. However, 188 even with these two technologies in place, packet delivery within the 189 MFS can still be highly inefficient. Since Internet connectivity in 190 mobile scenarios can be costly, limited or unavailable, there is a 191 need to enable local routing between the Mobile Routers within a 192 portion of the MFS. NINA can provide this form of local routing; it 193 is an example of Route Optimization (RO) between Mobile Routers that 194 are communicating directly in a portion of the MFS. 196 4. Rationale for the proposed solution 198 4.1. Why ND based 200 NINA extends the Neighbor Discovery protocol to address the MANEMO 201 requirements listed in [17], although MANET protocols [12], [14], 202 [15] provides similar features such as local routing and Internet 203 access over multihop. 205 One of the drawbacks of MANET protocols is the question of which 206 protocol should be used. AODV, DSR, DYMO, OLSR, etc. are 207 standardized in IETF and each has distinct features, like proactive 208 and reactive. In MANEMO scenarios, Mobile Routers, mobile hosts, and 209 fixed access routers are involved, and therefore, it is highly 210 important to deploy a consistent protocol in the network. On the 211 other hand, ND is a core component of IPv6 and is supported by all 212 IPv6 nodes. All IPv6 nodes can process a NINO(s) in ND messages if 213 desired. 215 MANEMO does not require full link states of a network as OLSR does, 216 it only requires path to and from the exit router (tree root) in the 217 tree fashion. Flooding the entire network with route information is 218 a redundant process and its overhead is not negligible. ND simply 219 carries prefix information to setup the path from the tree root to 220 each mobile router/node. 222 4.2. Why NA based 224 Since MR appears as a host on the egress interface side, it is 225 legitimate to use NA in the visited network. There are two reasons 226 for that: 228 o If an MR advertises itself as a router in the visited network 229 using RA, it might get used as a default router by LFNs attached 230 to the visited network and cause trouble. 232 o By using NINA, the whole part of the fringe behind the MR has the 233 footprint of a single host from the visited network standpoint 234 (and moves as a single host). 236 By using NINA on top of a TD established tree, MANEMO can be made to 237 reproduce the NEMO behavior for a whole subtree by reducing to a 238 single host footprint, and retain NEMO compatibility by avoiding 239 spurious RAs. Thus, a whole subtree can move within the fringe as a 240 single host. 242 4.3. Relationship with TD 244 NINA exploits the loop-less cluster established by Tree Discovery, so 245 it does not need to provide loop avoidance. 247 With TD, MRs setup a default route up the tree via the parent Access 248 Router, and all the packets are directed by default towards the 249 clusterhead (Top Level Mobile Router or root-MR in NEMO terms). To 250 provide complete reachability, it is enough for NINA to expose the 251 prefixes down the tree from any given MR, while propagating prefixes 252 information up the tree. 254 This allows an extreme conciseness of the routing information, with 255 no topological knowledge past the first hop. That conciseness 256 enables a high degree of movement within the nested structure; in 257 particular, a movement within a subtree is not seen outside of that 258 subtree, so most of the connectivity is maintained at all times while 259 there might never be such a thing as a convergence. 261 4.4. Relationship with NEMO 263 The Reverse Routing Header (RRH) described in [16] operates in the 264 nested NEMO as a layer 3 Source Route Bridging (SRB) technique for 265 nested NEMO Route Optimization. It allows a quick reaction to inner 266 movements with the resolution of the packet; but the cost, an IPv6 267 address per packet per hop, might be deemed excessive. 269 Also, the Home Agent needs to cache the RRH in its binding cache, and 270 again, the overhead might be significant for a large deployment. 272 On the other hand, NINA establishes states in the intermediate nodes, 273 in a fashion similar to Transparent Bridging (TB), but at layer 3. 274 The integration of these 2 approaches allows switching between SRB to 275 TB models dynamically as the NINA states are populated or become 276 obsolete. To obtain this capability, the operation of an 277 intermediate MR described in [16] is altered in the following manner: 279 o If the MR has a (NINA) route to the upper entry in the RRH via the 280 source of the packet, it still updates the source of the packet 281 with its own Care-of Address, but does not save the previous 282 source as a new entry in the RRH. 284 o At best, if NINA has established states all along in a given 285 branch of the tree, the RRH for that branch has always 2 entries, 286 the first MR's Home Address, and its Care-of Address, regardless 287 of the depth of the first MR in the nested NEMO. 289 o When some MRs in the tree support NINA and some do not, the 290 resulting RRH will be only partly compressed. Also, if the NINA 291 route does not match the RRH, then the route is obsolete and the 292 source address is added to the RRH as described in [16], in order 293 to ensure a correct routing on the way back. When NINA catches 294 up, the entry will be saved again. 296 The integration of NINA and RRH can offer the best of 2 worlds: a 297 quick (per packet) resolution to the network changes, and the 298 transparent (stateful) operation when the NINA routing protocol 299 establishes the states in the nested NEMO. 301 5. Overview 303 This section provides an overview of the operation of NINA to set-up 304 MNP route state in two different scenarios: a non-nested NEMO-to-NEMO 305 communication and a nested-NEMO one. 307 5.1. Basic kiss (MR to MR over egress) 309 A basic scenario where NINA can be used occurs when two or more MRs 310 are attached with their egress interfaces on the same link but do not 311 have connectivity to the infrastructure network (Figure 1). This 312 scenario includes, for example, the case of MRs equipped with short- 313 range communication technology (e.g. WLAN 802.11) that find 314 themselves in their communication range but are isolated from the 315 Internet. The NEMO Basic Support protocol [5] does not allow LFNs to 316 communicate, as it requires that the Home Agent is reachable and that 317 data packets go through it. By exchanging NINA messages, the MRs 318 expose their Mobile Network Prefixes to each other. Consequently, 319 MRs can add in their routing table a temporary route for MNPs exposed 320 by other MRs, which allows data packets to be exchanged between LFNs. 322 ---+-------------------+-------------+------ 323 | | | 324 +--+--+ +--+--+ +--+--+ 325 | MR1 | | MR2 | | MR3 | 326 +---+-+ +-+---+ +--+--+ 327 | | | 328 -+--+--- -+--+-- ---+--+-- 329 | | | 330 +--+---+ +--+---+ +---+--+ 331 | LFN1 | | LFN2 | | LFN3 | 332 +------+ +------+ +------+ 334 Figure 1: Basic Kiss scenario 336 A new multicast group is created (all MANEMO Mobile Routers, see 337 Section 6.1). An MR that needs to know all MNPs on link will 338 multicast a NINA NS to that group with a link scope. Reversely, an 339 MR that wishes to advertise its MNPs to all its siblings on link will 340 multicast a NINA containing information about all the MNPs it manages 341 to that group with a link scope. A NINA sent to siblings can contain 342 information regarding its own MNPs and only its own MNPs (i.e. it 343 MUST NOT contain information about MNPs managed by others than the MR 344 sending the NINA). This information MUST NOT be propagated by the 345 siblings. For that purpose, the flag in the NINO ('P' bit, see 346 Section 6.2) MUST be set to 0. 348 MRs that want to advertise their MNPs to all of their siblings, in 349 addition to answering to NINA NS messages sent to the all MANEMO 350 Mobile Routers multicast address, SHOULD also send periodically 351 unsolicited NINAs to this link-scoped multicast group. This enables 352 information about sibling MNPs to expire (i.e. time out) when MRs 353 disappear from the network. 355 5.2. Nested NEMO 357 NINA requires the Tree Discovery protocol to build and maintain a 358 tree topology. It relies on TD to discover that a change occurs in a 359 sub-tree of the topology, and that change triggers a flow of route 360 updates for that sub-tree in the topology. 362 +---------------------+ 363 | Internet |---CN 364 +---------------|-----+ 365 / Access Router 366 MR3_HA | 367 ======?====== 368 MR1 369 | 370 ====?=============?==============?=== 371 MR5 MR2 MR6 372 | | | 373 =========== ===?========= ============= 374 MR3 375 | 376 ==|=========?== 377 LFN1 MR4 378 | 379 ========= 381 Figure 2: Nested NEMO scenario 383 Each tree that TD self-forms is considered a separate routing 384 topology. If a Mobile Router belongs to multiple of such topologies, 385 then it is expected that both the NINA signaling and the data packets 386 are flagged to follow the topology for which the packet was 387 introduced in the network. 389 NINA expects a Mobile Router to own one or more Mobile Network 390 Prefix(es) that move with the MR. With that model, it is assumed 391 that there is a single source for the advertisement of a given prefix 392 within a topology. If multiple MRs share a given MNP, some protocol 393 must take place between those MRs to make sure that one and only one 394 MR advertises a given prefix in a given tree. 396 Tree Discovery formats the nested NEMO into a loop-less logical 397 graph, thus providing loop avoidance for the NINA protocol. Each 398 time a movement occurs, TD restores the loop-less structure before 399 NINA can operate again and repaint the graph with prefixes. 401 The root-MR of a nested NEMO is selected for a number of properties, 402 the primary one being an access to the wired infrastructure. It is 403 the default sink for every node in the tree. 405 More generally, the default gateway for a Mobile Router is its parent 406 up in the tree; the more specific routes, towards the Mobile Network 407 Prefixes, are always oriented down the tree, and NINA advertisements 408 flow up the tree towards the root-MR. 410 Each NINO contains a prefix and a sequence counter. The Mobile 411 Router that owns the prefix generates the NINO for that prefix, 412 including the sequence counter associated to that prefix and that is 413 incremented each time it generates a new NINO. 415 Due to a movement, a sub-tree can be temporarily out of sequence and 416 a NINO can be received from a sub-tree where the MR was but is no 417 more, until the parents realize it is gone. But by construction of 418 the tree, there can be a single route to a given prefix, so older 419 information is always invalid. 421 A parent-MR maintains a state for each prefix it learns from NINA. 422 In particular, the last sequence number is kept. An out-of-sequence 423 NINO must be disregarded. If the NINO appears valid, it is forwarded 424 to the parent's parent in the next burst, carried by a NINA, together 425 with the parent's own prefixes. 427 6. Message Formats 429 6.1. All MANEMO Mobile Routers multicast address 431 RFC 4291 [10] defines the IPv6 Addressing Model and in particular 432 Multicast Addresses. 434 Multicast addresses have the following format: 436 | 8 | 4 | 4 | 112 bits | 437 +------ -+----+----+---------------------------------------------+ 438 |11111111|flgs|scop| group ID | 439 +--------+----+----+---------------------------------------------+ 441 MANEMO requires a permanently-assigned multicast address: the MANEMO 442 Mobile Routers Group (IANA TBD 199?). As a result: 444 o FF02:0:0:0:0:0:0:(199?) means all MANEMO Mobile Routers on the 445 same link as the sender. 447 6.2. NINO NA option 449 NINO is a new option of ND Neighbors Advertisements. This 450 specification extends RFC 4191 [9] and adds the capability to include 451 a prefix option in the Neighbor Advertisements (NAs). The NA is a 452 necessary exchange that allows the AR to map the IPv6 address of a 453 node with its L2 address. The prefix option is normally present in 454 Router Advertisements (RAs) only. The meaning of such an option in a 455 NA is the concept of 'network in node', so we refer to the option as 456 NINO (Network In Node Option) and we name the resulting message NINA 457 (Network In Node Advertisement). 459 When Tree Discovery is used to build a tree, there can be a single 460 route to a given prefix along that tree, so the freshest information 461 is always the best for unicast routes. In order to track that, the 462 NINO includes a sequence counter to the prefix advertisement. 464 The sequence counter is incremented by the source of the NINO, that 465 is the Mobile Router that owns the MNP, each time it issues a NINA, 466 and then forwarded as is up the tree. A depth is also added for 467 tracking purposes; the depth is incremented at each hop as the NINO 468 is propagated up the tree. 470 On an egress interface, if NINA is configured, the MR: 472 o selects an Access Router (AR) as its point of attachment to the 473 network 475 o auto-configures a Care-of Address (CoA) 477 o acts as a host as opposed to a router. In particular, it refrains 478 from sending RAs 480 o sends NINAs, as unicast, to its AR only, with the propagate ('P') 481 bit set in the NINOs indicating that the NINO can be propagated up 482 the tree 484 o sends NINAs as solicited or unsolicited unicast or multicast to 485 siblings, with the propagate ('P') bit reset in the NINOs 486 indicating that the NINO cannot be propagated up the tree 488 o accepts unicast NINAs from any node BUT its AR 490 o optionally solicits multicast NINAs from all MANEMO MRs 492 o optionally accepts multicast NINAs (note, multicast NINAs 493 advertise only CONNECTED routes) 495 On an ingress interface, if NINA is configured, the MR: 497 o acts as a router, may accept visitors 499 o sends RAs with the Tree Information Option (RA-TIO) 501 o accepts NINAs from any node 503 Every NA to the AR contains a NINO. In particular, receiving a Tree 504 Discovery RA-TIO from the AR stimulates the sending of a delayed NINA 505 back, with the collection of all known prefixes (that is the prefixes 506 learned from NINO and the connected prefixes). A NINA is also sent 507 to the AR once it has been selected as new AR after a movement, or 508 when the list of advertised prefixes has changed. 510 NINA may advertise positive (prefix is present) or negative (removed) 511 NINOs. A no-NINO is stimulated by the disappearance of a prefix 512 below. This is discovered by timing out after a request (a RA-TIO) 513 or by receiving a no-NINO. A no-NINO is a NINO with a Route lifetime 514 of 0. 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Type | Length | IPv6 PL | IPv4 PL | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Route Lifetime | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | NINO Depth |6|4|P|L| | NINO Sequence | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | IPv4 Prefix | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | | 528 + + 529 | | 530 + IPv6 Prefix + 531 | | 532 + + 533 | | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Type: 538 NINO NA (number to be assigned by IANA) 540 Length: 542 8-bit unsigned integer. The length of the option (including the 543 Type and Length fields) in units of 8 octets. 545 IPv6 PL: 547 Number of valid leading bits in the IPv6 Prefix. 549 IPv4 PL: 551 Number of valid leading bits in the IPv4 Prefix. 553 Route Lifetime: 555 32-bit unsigned integer. The length of time in seconds (relative 556 to the time the packet is sent) that the prefix is valid for route 557 determination. A value of all one bits (0xFFFFFFFF) represents 558 infinity. A value of all zero bits (0x00000000) indicates a loss 559 of reachability. 561 NINO Depth: 563 Set to 0 by the MR that owns the MNP and issues the NINO. 564 Incremented by all MRs that propagate the NINO. 566 '6' bit: 568 Indicates that the IPv6 prefix is valid. 570 '4' bit: 572 Indicates that the IPv4 prefix is valid. 574 'P' bit: 576 Set only in a parent-child relationship, this flag indicates that 577 the NINO can be propagated up the tree. 579 'L' bit: 581 Indicates that the prefix or address is on-link as opposed to 582 another interface of the MR. This is useful for a child MR to 583 expose its IPv4 address on its egress interface. In that case, 584 the parent can set up forwarding to all the IPv4 prefixes in the 585 NINA via that address on this link. 587 NINO Sequence: 589 Incremented by the MR that owns the MNP for each new NINO for that 590 prefix. Left unchanged by all MRs that propagate the NINO. A 591 lollipop mechanism is used to wrap from 0xFFFF directly to 10. 593 IPv4 Prefix: 595 4-byte field containing an IPv4 address or a prefix of an IP 596 address. The IPv4 PL field contains the number of valid leading 597 bits in the prefix. The bits in the prefix after the prefix 598 length (if any) are reserved and MUST be initialized to zero by 599 the sender and ignored by the receiver. 601 IPv6 Prefix: 603 Variable-length field containing an IPv6 address or a prefix of an 604 IPv6 address. The IPv6 PL field contains the number of valid 605 leading bits in the prefix. The bits in the prefix after the 606 prefix length (if any) are reserved and MUST be initialized to 607 zero by the sender and ignored by the receiver. 609 6.3. NINO NS option 611 NINA messages MAY be solicited or unsolicited. In particular, for 612 privacy reasons, MRs may disable sending of unsolicited NINAs and 613 send only NINA to other nodes or MRs that requested it. This allows 614 the solicited MRs to decide whether or not to reveal its MNP. 615 Definition of policies for revealing MNP is out of scope of this 616 document. 618 As opposed to standard Neighbor Discovery [2], NINO Neighbor 619 Solicitations aim at resolving an MNP into an IPv6 address (MR link 620 local address) and not a known IPv6 address into a link-layer 621 address. Therefore, a NINA NS is sent to the All MANEMO MRs 622 multicast address and optionally contains the target MNP in a NINO NS 623 option. 625 An MR receiving a NINA NS compares its MNP with the one specified in 626 the NINO NS option. If the MNP matches the requested one and privacy 627 policies allow that, the MR sends a unicast NINA message to the 628 sender. 630 When there is no NINA NS option in the NS, the MR adds NINOs to its 631 NAs based on its policy. The NINA NS message MAY contain also a NINO 632 to inform other MRs about its MNP. 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Type | Length | Prefix Length | |4| | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Requested IPv4 prefix | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | | 642 + + 643 | | 644 + Requested IPv6 Prefix + 645 | | 646 + + 647 | | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Type: 652 NINO NS (number to be assigned by IANA). 654 Length: 656 8-bit unsigned integer. The length of the option (including the 657 Type and Length fields) in units of 8 octets. This is set to 1 658 for an IPv4 query and to 3 for an IPv6 query. 660 Prefix Length: 662 Number of valid leading bits in the IPv4/IPv6 Requested Prefix. 664 '4' bit: 666 If set to 1, it indicates that the target (requested) prefix is an 667 IPv4 prefix. If set to 0, it indicates that the target 668 (requested) prefix is an IPv6 prefix. 670 Requested IPv4 Prefix: 672 The IPv4 MNP that the sender wants to resolve into an IPv4 673 address. 675 Requested IPv6 Prefix: 677 The IPv6 MNP that the sender wants to resolve into an IPv6 address 678 (MR link local address). 680 7. Mobile Router Operation 682 The Mobile Router operation is autonomous, based on the information 683 provided by the potential Access Routers in sight. Each MR selects 684 an AR (a MAR) in a loop-less and case-optimized fashion, and installs 685 a default route up the tree via the selected AR. The resulting tree 686 (the cluster) may never be globally stable enough to be mapped in a 687 global graph. So the adaptation to local movements must be rapid and 688 localized. 690 For NEMO flows, the Reverse Routing Header allows the update to the 691 path on a per packet basis. Hopefully, the root of the tree (the 692 clusterhead) is connected to the infrastructure where Home can be 693 reached, and can be used as a gateway to discover Home. When the 694 NEMO tunnel is established, it becomes the default route for the MR. 696 If the tree is not connected to the infrastructure or in any case if 697 Home can not be reached, MRs need an ad-hoc protocol to establish 698 local connectivity. This specification takes advantage of the TD 699 cluster and allows an MR to discover the prefixes below itself. 701 NINA information can be redistributed in a routing protocol, MANET or 702 IGP. But the MANET or the IGP SHOULD NOT be redistributed into NINA. 703 This creates a hierarchy of routing protocols where NINA routes stand 704 somewhere between connected and IGP routes. 706 NINA also allows a compression of the Reverse Routing header when the 707 routes match the topology as traced by RRH on a per packet basis. In 708 particular, if a NINA route exists to the first entry in the RRH via 709 the source of the packet, then the MR can override the source of the 710 packet with its own CoA without adding the original source to the 711 RRH. At that point, the RRH operation becomes loose, in other words 712 an hybrid between transparent (stateful) and source routing. 714 As a result: 716 o Tree Discovery establishes a tree using extended Neighbor 717 Discovery RS/RA flows. 719 o The NEMO Basic Support protocol exploits the tree to get optimally 720 out of a nested set of MRs and register Home. 722 o RRH extends the NEMO Basic Support to provide Route Optimization 723 and faster path reestablishment. 725 o NINA also extends Neighbor Discovery in order to establish quickly 726 the routes down the cluster. 728 NINA maintains abstract lists of known prefixes. A prefix entry 729 contains the following abstract information: 731 o The state of the entry: ELAPSED, PENDING, or CONFIRMED. 733 o A reference to the adjacency that was created for that prefix. 735 o A reference to the ND entry that was created for the advertiser 736 Neighbor. 738 o The IPv6 address of the advertiser Neighbor. 740 o The logical equivalent of the full NINA information. 742 o A reference to the interface of the advertiser Neighbor. 744 o A 'reported' Boolean to keep track whether this prefix was 745 reported already to the parent AR. 747 o A counter of retries to count how many RA-TIOs were sent on the 748 interface to the neighbor without reachability confirmation for 749 the prefix. 751 NINA stores the prefix entries in either one of 3 abstract lists; the 752 Connected, the Reachable and the Unreachable lists. 754 The Connected list corresponds to the MNP of the Mobile Router. 756 As long as an MR keeps receiving NINOs for a prefix timely, its 757 prefix entry is listed in the Reachable list. 759 Once scheduled to be destroyed, a prefix entry is moved to the 760 Unreachable list if the MR has a parent to which it sends NINOs, 761 otherwise the entry is cleaned up right away. The entry is removed 762 from the Unreachable list when the parent changes or when a no-NINO 763 is sent to the parent indicating the loss of the prefix. 765 NINA requires 2 timers; the DelayNA timer and the Destroy Timer. 767 o The DelayNA timer is armed upon a stimulation to send a NINA (such 768 as a TIO from the AR). When the timer is armed, all entries in 769 the Reachable list as well as all entries for Connected list are 770 set to not reported yet. 772 o The DelayNA timer has a duration that is DEF_NA_LATENCY divided by 773 2 with the tree depth. 775 o The Destroy timer is armed when at least one entry has exhausted 776 its retries, which means that a number of RA-TIO were sent over 777 the ingress interface but that the entry was not confirmed with a 778 NINO. When the destroy timer elapses, for all exhausted entries, 779 the associated route is removed, and the entry is scheduled to be 780 destroyed. 782 o The Destroy timer has a duration of min (MAX_DESTROY_INTERVAL, 783 RA_INTERVAL). 785 7.1. NINA messages between siblings 787 When sending NINA to siblings, an MR includes the NINOs corresponding 788 to the prefix entries in the Connected list, with the 'P' bit set to 789 0. 791 Depending on its policy, the receiving MR MAY install a route to the 792 prefix in the NINO via the link local address of the source MR but it 793 SHOULD NOT propagate the information, either as a NINO or by means of 794 redistribution into a routing protocol, since the 'P' bit is not set. 796 7.2. Multicast TD RA messages from parent 798 When ND sends a NA to the AR, NINA extends the message with prefix 799 options for: 801 o All the prefixes that are not 'DELETED' for all the ingress 802 interfaces. 804 o All the prefixes in the removed list as no-NINO. 806 o All the prefixes in the advertised list that are not reported yet. 807 The entries are set to reported. 809 When ND receives a NA from a visitor over an ingress interface, NINOs 810 are processed in a loop. For known prefixes, the sequence counter in 811 the NINO is checked against the last received and the update is used 812 only if the sequence is newer. This filters out obsolete 813 advertisements when a prefix has moved between 2 subtrees attached to 814 a same node. 816 If a prefix is advertised as a no-NINO, the associated route is 817 removed, and the entry is transferred to the removed list. 818 Otherwise, the route table is looked up: 820 o If a preferred route to that prefix from another protocol already 821 exists, the prefix is ignored. 823 o If a new route can be created, a new prefix entry is allocated to 824 track it, as CONFIRMED, but not reported. 826 o If a NINA route existed already via the same Neighbor, it is 827 CONFIRMED. 829 o If a NINA route existed via a different Neighbor, this is 830 equivalent to a no-NINO for the previous entry followed by a new 831 NINO for the new entry. So the old entry is scheduled to be 832 destroyed, whereas the new one is installed. 834 7.3. Unicast NINA messages from child to parent 836 When sending NINA to its parent, an MR includes the NINOs about not 837 already reported prefix entries in the Reachable and Connected lists, 838 as well as no-NINOs for all the entries in the Unreachable list. The 839 'P' bit in the NINOs is set, indicating that the parent can propagate 840 the NINOs up the tree. Depending on its policy, the receiving MR 841 SHOULD install a route to the prefix in the NINO via the link local 842 address of the source MR and it SHOULD propagate the information, 843 either as a NINO or by means of redistribution into a routing 844 protocol. 846 The RA-TIO from the root-MR is used to synchronize the whole tree. 847 Its period is expected to range from 500ms to hours, depending on the 848 stability of the configuration and the bandwidth available. 850 When an MR receives a RA-TIO over an egress interface from the 851 current parent AR, the DelayNA is armed to force a full update. As 852 described in [6] the MR also issues a propagated RA-TIO over all its 853 ingress interfaces, after a small jitter that aims at minimizing 854 collisions of RA-TIO messages over the radio as it is propagated down 855 the tree. 857 The design choice behind this is NOT TO synchronize the parent and 858 children databases, but instead to update them regularly to cover 859 from the loss of packets. The rationale for that choice is movement. 860 If the topology can be expected to change frequently, synchronization 861 might be an excessive goal in terms of exchanges and protocol 862 complexity. This results in a simple protocol with no real peering. 864 When the MR send a RA-TIO over an ingress interface, for all entries 865 on that interface: 867 o If the entry is CONFIRMED, it goes PENDING with the retry count 868 set to 0. 870 o If the entry is PENDING, the retry count is incremented. If it 871 reaches a maximum threshold, the entry goes ELAPSED If at least 872 one entry is ELAPSED at the end of the process: if the Destroy 873 timer is not running then it is armed with a jitter. 875 Since the DelayNA has a duration that decreases with the depth, it is 876 expected to receive all NINOs from all children before the timer 877 elapses and the full update is sent to the parent. 879 7.4. Other events 881 Finally, NINA listens to a series of events, such as: 883 o MR stopped or unable to run: NINA routes are cleaned up. NINA is 884 inactive. 886 o NINA operation stopped: All entries in the abstract lists are 887 freed. All the NINA routes are destroyed. 889 o Interface going down: for all entries in the Reachable list on 890 that interface, the associated route is removed, and the entry is 891 scheduled to be destroyed. 893 o Neighbor being removed from the ND list: if the entry is in the 894 Reachable list the associated route is removed, and the entry is 895 scheduled to be destroyed. 897 o Roaming: All entries in the Reachable list are set to not 898 'reported' and DelayNA is armed. 900 7.5. Default value 902 DEF_NA_LATENCY = 150 ms 904 MAX_DESTROY_INTERVAL = 200ms 906 8. Acknowledgments 908 We would like to thank all the people who have provided comments on 909 this draft, specially to Ben McCarthy for his very helpful review of 910 this document. 912 9. IANA Considerations 914 This document requires IANA to define a permanently-assigned 915 multicast address: the MANEMO Mobile Routers Group (Section 6.1). 916 Additionally, 2 new ND option types should be defined for NINO NA and 917 NINO NS messages. 919 10. Security Considerations 921 The MANEMO Basic kiss (MR to MR over egress) scenario can be secured 922 by SeND [13]. An MR can prove ownership of its prefix by the same 923 certificate on egress as it could already on ingress. 925 The nested NEMO scenario has the same security concerns that ND/RFC 926 4191 without SeND. In order to secure this scenario, L2 trusts and 927 policies are required. 929 11. References 931 11.1. Normative References 933 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 934 Levels", BCP 14, RFC 2119, March 1997. 936 [2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 937 for IP Version 6 (IPv6)", RFC 2461, December 1998. 939 [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 940 August 2002. 942 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 943 IPv6", RFC 3775, June 2004. 945 [5] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 946 "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 947 January 2005. 949 [6] Thubert, P., "Nested Nemo Tree Discovery", 950 draft-thubert-tree-discovery-04 (work in progress), 951 November 2006. 953 [7] Manner, J. and M. Kojo, "Mobility Related Terminology", 954 RFC 3753, June 2004. 956 [8] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 957 draft-ietf-nemo-terminology-06 (work in progress), 958 November 2006. 960 [9] Draves, R. and D. Thaler, "Default Router Preferences and More- 961 Specific Routes", RFC 4191, November 2005. 963 [10] Hinden, R. and S. Deering, "IP Version 6 Addressing 964 Architecture", RFC 4291, February 2006. 966 11.2. Informative References 968 [11] Corson, M. and J. Macker, "Mobile Ad hoc Networking (MANET): 969 Routing Protocol Performance Issues and Evaluation 970 Considerations", RFC 2501, January 1999. 972 [12] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing 973 Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728, 974 February 2007. 976 [13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 977 Neighbor Discovery (SEND)", RFC 3971, March 2005. 979 [14] Clausen, T., "The Optimized Link-State Routing Protocol version 980 2", draft-ietf-manet-olsrv2-02 (work in progress), June 2006. 982 [15] Clausen, T., "MANET Neighborhood Discovery Protocol (NHDP)", 983 draft-ietf-manet-nhdp-01 (work in progress), February 2007. 985 [16] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and 986 its application to Mobile Networks", 987 draft-thubert-nemo-reverse-routing-header-07 (work in 988 progress), February 2007. 990 [17] Wakikawa, R., "MANEMO Problem Statement", 991 draft-wakikawa-manemo-problem-statement-00 (work in progress), 992 February 2007. 994 Authors' Addresses 996 Pascal Thubert 997 Cisco Systems 998 Village d'Entreprises Green Side 999 400, Avenue de Roumanille 1000 Batiment T3 1001 Biot - Sophia Antipolis 06410 1002 FRANCE 1004 Phone: +33 4 97 23 26 34 1005 Email: pthubert@cisco.com 1007 Ryuji Wakikawa 1008 Keio University and WIDE 1009 5322 Endo Fujisawa Kanagawa 1010 252-8520 1011 JAPAN 1013 Email: ryuji@sfc.wide.ad.jp 1015 Carlos J. Bernardos 1016 Universidad Carlos III de Madrid 1017 Av. Universidad, 30 1018 Leganes, Madrid 28911 1019 Spain 1021 Phone: +34 91624 6236 1022 Email: cjbc@it.uc3m.es 1024 Roberto Baldessari 1025 NEC Europe Network Laboratories 1026 Kurfuersten-anlage 36 1027 Heidelberg 69115 1028 Germany 1030 Phone: +49 6221 4342167 1031 Email: roberto.baldessari@netlab.nec.de 1032 Jean Lorchat 1033 Keio University and WIDE 1034 5322 Endo Fujisawa Kanagawa 1035 252-8520 1036 JAPAN 1038 Email: lorchat@sfc.wide.ad.jp 1040 Full Copyright Statement 1042 Copyright (C) The IETF Trust (2007). 1044 This document is subject to the rights, licenses and restrictions 1045 contained in BCP 78, and except as set forth therein, the authors 1046 retain all their rights. 1048 This document and the information contained herein are provided on an 1049 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1050 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1051 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1052 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1053 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1054 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1056 Intellectual Property 1058 The IETF takes no position regarding the validity or scope of any 1059 Intellectual Property Rights or other rights that might be claimed to 1060 pertain to the implementation or use of the technology described in 1061 this document or the extent to which any license under such rights 1062 might or might not be available; nor does it represent that it has 1063 made any independent effort to identify any such rights. Information 1064 on the procedures with respect to rights in RFC documents can be 1065 found in BCP 78 and BCP 79. 1067 Copies of IPR disclosures made to the IETF Secretariat and any 1068 assurances of licenses to be made available, or the result of an 1069 attempt made to obtain a general license or permission for the use of 1070 such proprietary rights by implementers or users of this 1071 specification can be obtained from the IETF on-line IPR repository at 1072 http://www.ietf.org/ipr. 1074 The IETF invites any interested party to bring to its attention any 1075 copyrights, patents or patent applications, or other proprietary 1076 rights that may cover technology that may be required to implement 1077 this standard. Please address the information to the IETF at 1078 ietf-ipr@ietf.org. 1080 Acknowledgment 1082 Funding for the RFC Editor function is provided by the IETF 1083 Administrative Support Activity (IASA).