idnits 2.17.00 (12 Aug 2021) /tmp/idnits35508/draft-ietf-nemo-basic-support-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 202: '...lag 'R' in the Binding Update. It MAY...' RFC 2119 keyword, line 310: '...Mobile Node, and MUST NOT forward pack...' RFC 2119 keyword, line 317: '... addition to what is defined in [1]. The receiver MUST skip and...' RFC 2119 keyword, line 379: '... now. The value MUST be initialized t...' RFC 2119 keyword, line 380: '... the sender, and MUST be ignored by th...' (52 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (September 2003) is 6823 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) == Unused Reference: '9' is defined on line 1042, but no explicit reference was found in the text == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 == Outdated reference: draft-ietf-mobileip-mipv6-ha-ipsec has been published as RFC 3776 ** Obsolete normative reference: RFC 2402 (ref. '4') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2401 (ref. '5') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2460 (ref. '6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '7') (Obsoleted by RFC 4861) == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 == Outdated reference: draft-ietf-nemo-requirements has been published as RFC 4886 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NEMO Working Group Vijay Devarapalli 2 INTERNET DRAFT Nokia 3 Category: Standards Track Ryuji Wakikawa 4 Expires March 2004 Keio University 5 Alexandru Petrescu 6 Motorola 7 Pascal Thubert 8 Cisco Systems 9 September 2003 11 Nemo Basic Support Protocol 12 draft-ietf-nemo-basic-support-01.txt 14 Status of This Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes the Nemo Basic Support protocol to support 37 network mobility as the mobile network attaches to different points 38 in the Internet. The protocol is based on extensions to Mobile 39 IPv6 and allows for session continuity for every node in the mobile 40 network as the network moves. It also allows every node in the 41 mobile network to be reachable while moving around. The Mobile 42 Router, which connects the network to the Internet, runs the NEMO 43 Basic Support protocol with its Home Agent. The protocol is designed 44 in such a way that network mobility is transparent to the nodes 45 inside the mobile network. 47 Contents 49 Status of This Memo 1 51 Abstract 1 53 1. Introduction 4 55 2. Terminology 5 57 3. Overview of the Nemo Protocol 6 59 4. Message Formats 9 60 4.1. Binding Update . . . . . . . . . . . . . . . . . . . . . 9 61 4.2. Binding Acknowledgement . . . . . . . . . . . . . . . . . 9 62 4.3. Mobile Network Prefix Option . . . . . . . . . . . . . . 10 63 4.4. Mobile Network Prefix Length Option . . . . . . . . . . . 11 65 5. Mobile Router Operation 13 66 5.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 13 67 5.2. Sending Binding Updates . . . . . . . . . . . . . . . . . 13 68 5.3. Receiving Binding Acknowledgements . . . . . . . . . . . 14 69 5.4. Error Processing . . . . . . . . . . . . . . . . . . . . 15 70 5.5. Establishment of Bi-directional Tunnel . . . . . . . . . 16 71 5.6. Neighbour Discovery for Mobile Router . . . . . . . . . . 17 72 5.7. Multicast Groups for Mobile Router . . . . . . . . . . . 17 74 6. Home Agent Operation 18 75 6.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 18 76 6.1.1. Binding Cache . . . . . . . . . . . . . . . . . . 18 77 6.1.2. Prefix Table . . . . . . . . . . . . . . . . . . 18 78 6.2. Mobile Network Prefix Registration . . . . . . . . . . . 19 79 6.3. Advertising Mobile Network Reachability . . . . . . . . . 20 80 6.4. Establishment of Bi-directional Tunnel . . . . . . . . . 21 81 6.5. Forwarding Packets . . . . . . . . . . . . . . . . . . . 21 82 6.6. Sending Binding Acknowledgements . . . . . . . . . . . . 22 83 6.7. Mobile Network Prefix De-Registration . . . . . . . . . . 22 85 7. Support for Dynamic Routing Protocols 23 87 8. Security Considerations 25 89 9. IANA Considerations 25 91 10. Contributors 25 92 11. Acknowledgements 26 94 A. Examples of Operation 28 96 B. Changes from Previous Version 31 98 Addresses 32 99 1. Introduction 101 This document describes protocol extensions to Mobile IPv6 (MIPv6) 102 [1] to enable support for network mobility. The extensions provide 103 backward compatibility with Mobile IPv6, and in particular, a Nemo 104 compliant Home Agent can operate as a MIPv6 Home Agent as well. 106 The Nemo Basic Support works in such a way that session continuity is 107 ensured for all the nodes in the mobile network even as the Mobile 108 Router changes its point of attachment to the Internet. It also 109 provides connectivity and reachability for all nodes in the mobile 110 network as the network moves. The solution supports both Local Fixed 111 Nodes [8] and Mobile Nodes in the Mobile Network. 113 Within the context of this document, the definition of a Mobile 114 Router extends that of a Mobile IPv6 [1] Mobile Node, by adding 115 the capability of routing between its point of attachment (Care-of 116 Address) and a subnet which moves with the Mobile Router. 118 The solution described in this document requires setting up a 119 bi-directional tunnel between the Mobile Router and its Home Agent. 120 This tunnel is set up when the Mobile Router sends a successful 121 Binding Update to its Home Agent, informing the Home Agent of its 122 current point of attachment. 124 All traffic between the nodes in the Mobile Network and Correspondent 125 Nodes passes through the Home Agent. This document does not describe 126 how to route optimize this traffic. 128 The terminology document [8] describes Nested Mobility as a scenario 129 where a Mobile Router allows another Mobile Router to attach to its 130 mobile network. There could be arbitrary levels of nested mobility. 131 The operation of each Mobile Router remains the same whether the 132 Mobile Router attaches to another Mobile Router or to a fixed Access 133 Router on the Internet. The solution described here does not place 134 any restriction on the number of levels for nested mobility. But it 135 should be noted that this might introduce significant overhead on 136 the data packets as each level of nestedness introduces another IPv6 137 header encapsulation. 139 2. Terminology 141 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [2]. 145 There is a separate NEMO terminology document [8], which defines the 146 terms related to Network Mobility used in the document. 148 Prefix Table 150 It is a list of a Mobile Network Prefixes indexed 151 by the Home Address of a Mobile Router. The prefix table 152 is managed by the Home Agent and is used by the Home Agent 153 to determine which Mobile Network Prefixes are owned 154 a particular Mobile Router. This is an optional data 155 structure. 157 3. Overview of the Nemo Protocol 159 A Mobile Network is a network segment or subnet which can move 160 and attach to arbitrary points in the Internet. A Mobile Network 161 does not allow any transit traffic and can only be accessed via 162 specific gateways called Mobile Routers that manage its movement. 163 A Mobile Router does not distribute the Mobile Network routes to 164 the infrastructure at its point of attachment (i.e. in the visited 165 network). Instead, it maintains a bidirectional tunnel to a Home 166 Agent that advertises an aggregation of Mobile Networks to the 167 infrasructure. The Mobile Router is also the default gateway for the 168 Mobile Network. 170 A Mobile Network can also consist of multiple and nested subnets. A 171 router with no support for mobility may be permanently attached to 172 a Mobile Network for local distribution. Also, Mobile Routers may 173 be attached to Mobile Networks owned by different Mobile Routers and 174 form a graph. In particular, with Basic Nemo Support, each Mobile 175 Router is attached to another Mobile Network by a single interface, 176 and if loops are avoided, the graph is a tree. 178 A Mobile Router has an unique Home Address through which it is always 179 reachable. The Home Address is configured from a prefix that is 180 aggregated and advertised by its Home Agent. The prefix could either 181 be the prefix advertised on the home link or the prefix delegated to 182 the Mobile Router. The Mobile Router can have more than one Home 183 Address if there are multiple prefixes in the home link. The Mobile 184 Router also advertises one or more prefixes in the mobile network 185 attached to it. The actual mechanism for allocating these Mobile 186 Network Prefixes is outside the scope of this specification. 188 When the Mobile Router moves away from the home link and attaches 189 to a new access router, it acquires a Care-of Address from the 190 visited link. The Mobile Router at any time can appear and behave 191 as a Mobile Host or a Mobile Router. If the Mobile Router wants 192 connectivity, reachability and session continuity for nodes in the 193 Mobile Network, it acts as a Mobile Router. In either case, as soon 194 as the Mobile Router acquires a Care-of Address, it immediately sends 195 a Binding Update to its Home Agent as described in [1]. When the 196 Home Agent receives this Binding Update it creates a binding cache 197 entry binding the Mobile Router's Home Address to its Care-of address 198 at the current point of attachment. 200 If the Mobile Router wishes to act as a Mobile Router and provide 201 connectivity to nodes in the Mobile Network, it indicates this to 202 the Home Agent by setting a flag 'R' in the Binding Update. It MAY 203 also include information about the Mobile Network Prefix in the 204 Binding Update using one of the modes described in section 5.2, so 205 that the Home Agent can forward packets meant for nodes in the mobile 206 network to the Mobile Router. Two new Mobility Header Options are 207 described in this document to carry prefix information. These new 208 options are described in section 4.3 and section 4.4. If the Mobile 209 Network has more than one IPv6 prefix and wants the Home Agent to 210 setup forwarding for all these prefixes, it includes multiple prefix 211 information options in a single Binding Update. The Home Agent sets 212 up forwarding for each of these prefixes to the Mobile Router's 213 Care-of Address. In some scenarios the Home Agent already knows 214 which prefixes are owned by a Mobile Router. In these scenarios, the 215 Mobile Router does not include any prefix information in the Binding 216 Update. The Home Agent sets up forwarding for all prefixes owned by 217 the Mobile Router, when it receives a Binding Update from the mobile 218 router with the router flag 'R' set. 220 The Home Agent acknowledges the Binding Update by sending a Binding 221 Acknowledgement to the Mobile Router. A positive acknowledgement 222 means that the HA has set up forwarding for the Mobile Network. 223 Once the binding process completes, a bi-directional tunnel is 224 established between the Home Agent and the Mobile Router. The tunnel 225 end points are Mobile Router's Care-of Address and the Home Agent's 226 address. If a packet with a source address belonging to the Mobile 227 Network Prefix is received from the Mobile Network, the Mobile Router 228 reverse-tunnels the packet to the Home Agent through this tunnel. 229 This reverse-tunneling is done by using IP-in-IP encapsulation [3]. 230 The Home Agent decapsulates this packet and forwards it to the 231 Correspondent Node. The Mobile Router is however free to use route 232 optimization as described in [1] for packet originated by the Mobile 233 Router itself. 235 When a data packet is sent by a Correspondent Node to a node in the 236 Mobile Network, it gets routed to the Home Agent which currently 237 has the binding for the Mobile Router. It is expected that the 238 Mobile Router's network prefix would be aggregated at the Home Agent, 239 which advertises the resulting aggregation. Alternatively, the Home 240 Agent may receive the data packets meant for the Mobile Network 241 by advertising routes to the Mobile Network prefix. The actual 242 mechanism by which these routes are advertised is outside the scope 243 of this document. When the Home Agent receives a data packet meant 244 for a node in the mobile network, it tunnels the packet to Mobile 245 Router's current Care-of address. The Mobile Router decapsulates 246 the packet and forwards it onto the interface where the Mobile 247 Network is connected. The Mobile Router before decapsulating the 248 tunneled packet, has to check if the Source address on the outer IPv6 249 header is the Home Agent's address. It also has to make sure the 250 destination address on the inner IPv6 header belongs to one of its 251 Mobile Network Prefixes before forwarding the packet to the Mobile 252 Network. 254 The Mobile Network could consist of nodes which are Local Fixed 255 Nodes, Local Mobile Nodes and Visiting Mobile Nodes [8]. The 256 protocol described here ensures complete transparency of network 257 mobility to the Local Fixed Nodes. Visiting Mobile Nodes are those 258 nodes which are Mobile Nodes as described in Mobile IPv6. Visiting 259 Mobile Nodes treat the Mobile Network as just a normal IPv6 access 260 network and run the Mobile IPv6 protocol. 262 It is also possible for the Mobile Router and the Home Agent to run 263 a routing protocol through the bi-directional tunnel. In that case, 264 the Mobile Router need not include prefix information in the Binding 265 Update. Instead the Home Agent uses the routing protocol updates to 266 setup forwarding for the Mobile Network. When running the routing 267 protocol it is required that the bi-directional tunnel be treated as 268 a tunnel interface. The tunnel interface is included as the list of 269 interfaces on which routing protocol is active. The Mobile Router 270 should be configured not to run the routing protocol on its egress 271 interface when it is away from the home link. 273 Finally, the Home Agent may be configured with static routes to the 274 Mobile Network Prefix via the Mobile Router's Home Address. In that 275 case, the routes are set independently of the binding flows and the 276 returning Home of a Mobile Router. The benefit is that such movement 277 does not induce any additional signalling in the form of routing 278 updates in the Home Network. The drawback of that model is that the 279 routes are present even if the related Mobile Routers that are not 280 reachable (at Home or bound) at a given point of time. 282 4. Message Formats 284 4.1. Binding Update 286 A new flag `R' is included in the Binding Update to indicate to the 287 Home Agent if the Binding Update is coming from a Mobile Router 288 and not from a mobile node. The rest of the Binding Update format 289 remains the same as defined in [1]. 291 0 1 2 3 292 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Sequence # | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 |A|H|L|K|R| Reserved | Lifetime | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | | 299 . . 300 . Mobility options . 301 . . 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Mobile Router Flag (R) 307 The Mobile Router Flag is set to indicate to the Home Agent 308 that the Binding Update is from a Mobile Router. If the flag 309 is set to 0, the Home Agent assumes that the Mobile Router is 310 just behaving as a Mobile Node, and MUST NOT forward packets 311 destined for the mobile network to the Mobile Router. 313 Mobility Options 315 Variable length field which can include zero or more mobility 316 options. This document defines two new mobility options in 317 addition to what is defined in [1]. The receiver MUST skip and 318 ignore any options which it does not understand. 320 4.2. Binding Acknowledgement 322 There is no change in the Binding Acknowledgement format from what 323 is used in Mobile IPv6 [1]. However, this document introduces the 324 following new status values for the binding acknowledgement. 326 Status 327 2 Mobile Router Binding Update accepted 329 140 Mobile Router Operation not permitted 331 141 Invalid Prefix 333 142 Not Authorized for Prefix 335 143 Forwarding Setup failed 337 Status values less than 128 indicate that the Binding Update was 338 processed successfully by the receiving nodes. Values greater than 339 128 indicate that the Binding Update was rejected by the receiving 340 node. 342 4.3. Mobile Network Prefix Option 344 The Mobile Network Prefix Option is included in the Binding Update 345 to indicate to the Home Agent the prefix information for the mobile 346 network. There could be multiple Mobile Network Prefix Options 347 if the Mobile Router has more than one IPv6 prefix in the Mobile 348 Network and wants the Home Agent to forward packets for each of these 349 prefixes to the Mobile Router's current location. 351 The Mobile Network Prefix Option has an alignment requirement of 352 8n+4. Its format is as follows. 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Type | Length | Reserved | Prefix Length | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | | 360 + + 361 | | 362 + Mobile Network Prefix + 363 | | 364 + + 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Type 370 TBA 372 Length 374 8 bit unsigned integer indicating the length in octets of the 375 option excluding the type and length fields. Set to 18. 377 Reserved 379 This field is unused for now. The value MUST be initialized to 380 zero by the sender, and MUST be ignored by the receiver. 382 Prefix Length 384 8 bit unsigned integer indicating the prefix length of the IPv6 385 prefix contained in the option. 387 Mobile Network Prefix 389 A 16 byte field contains the Mobile Network Prefix. 391 4.4. Mobile Network Prefix Length Option 393 The Mobile Network Prefix Length Option can be used by the Mobile 394 Router if the Mobile Network Prefix can be deduced from the Home 395 Address of the Mobile Router. If there is only one Mobile Network 396 Prefix owned by the Mobile Router, using this option helps in 397 saving 16 bytes in the Binding Update by not including the prefix 398 information. 400 There can only be one instance of this option in a Binding Update. 401 The Mobile Network Prefix Option cannot be present in the Binding 402 Update if this option is present. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type | Length | Reserved | Prefix Length | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Type 412 TBA 414 Length 416 8 bit unsigned integer indicating the length in octets of the 417 option excluding the type and length field. Set to 2. 419 Reserved 421 This field is unused for now. The value MUST be initialized to 422 zero by the sender, and MUST be ignored by the receiver. 424 Prefix Length 426 8 bit unsigned integer indicating the prefix length of the IPv6 427 prefix from which the Home Address included in the Binding 428 Update was configured. 430 5. Mobile Router Operation 432 Mobile Router operation is derived largely from the combined 433 behaviors of a Host, of a Router [6], and of a Mobile Node [1] (also 434 please see definition of a Mobile Host in [8]). 436 A Mobile Node can act in two different ways: (1) as a Mobile Host 437 (in which case the Mobile IPv6 Home Agent doesn't maintain any prefix 438 information related to the Mobile Host's Home Address, but does 439 maintain a binding cache entry related to the Mobile Host's Home 440 Address) and (2) as a Mobile Router (in which case, in addition to 441 maintaining the binding cache entry corresponding to the Mobile 442 Router Home Address, the Mobile IPv6 Home Agent also maintains 443 forwarding information related to prefixes assigned to the mobile 444 network). The distinction between the the two modes is represented 445 by the value of the Mobile Router flag 'R'. 447 5.1. Data Structures 449 Like a Mobile Host, a Mobile Router also maintains a Binding Update 450 List, described in section 11.1 of Mobile IPv6 specification[1]. The 451 Binding Update list is a conceptual data structure which records 452 information that is sent in the Binding Updates. There is one entry 453 per each destination that the Mobile Router is currently sending 454 Binding Updates to. 456 This document introduces a new Prefix Information field in the 457 Binding Update list structure. This field is used to store any 458 prefix information that the Mobile Router includes in the Binding 459 Update. If the Mobile Router sets the Mobile Router flag 'R' in the 460 Binding Update, but does not include any prefix information in it 461 (implicit mode), this field is set to null. 463 Similar to a Mobile Host, a Mobile Router stores the information 464 regarding status of flags of the Binding Update, in the corresponding 465 Binding Update List entry. This document introduces a new mobile 466 router flag 'R' for this entry. The status of this flag is stored in 467 the Binding Update list whenever a Binding Update is sent. 469 A Mobile Router also maintains a Home Agent list populated according 470 to the same procedure as a Mobile Host. 472 5.2. Sending Binding Updates 474 A Mobile Router sends Binding Updates to its Home Agent according to 475 the same procedures that a Mobile Host uses. The Mobile Router uses 476 one of the following modes to instruct the Home Agent to determine 477 the prefixes owned by the Mobile Router. In all three modes, the 478 Mobile Router sets the Mobile Router flag 'R'. 480 Implicit: 482 In this mode, the Mobile Router does not include either a 483 Mobile Network Prefix Option or a Mobile Network Prefix Length 484 Option in the Binding Update (but it does include the Home 485 Address Option in the Destination Options header, as all Mobile 486 Hosts do). The Home Agent can use any mechanism (not defined 487 in this document) to determine the Mobile Network Prefix(es) 488 owned by the Mobile Router and setup forwarding for the Mobile 489 Network. One example would be manual configuration at the 490 Home Agent mapping the Mobile Router's Home Address to the 491 information required for setting up forwarding for the Mobile 492 Network. 494 Explicit Network: 496 In this mode, the Mobile Router includes one or more Mobile 497 Network Prefix Options in the Binding Update. These options 498 contain information about the Mobile Network Prefix(es) 499 configured on the mobile network. 501 Explicit Prefix Length: 503 In this mode, the Mobile Router instructs the Home Agent to 504 derive the Mobile Network Prefix by using: (1) the Home 505 Address in the Home Address Option carried in the Destination 506 Options header of the same packet that carries the Mobility 507 Header containing this Binding Update and (2) the prefix length 508 carried in the Mobile Network Prefix Length Option. In this 509 case, Mobile Router includes one and only one Mobile Network 510 Prefix Length Option. It MUST NOT include a Mobile Network 511 Prefix Option if this method is used. 513 If the Mobile Router flag is set, Home Registration flag 'H' MUST be 514 set. 516 5.3. Receiving Binding Acknowledgements 518 The Mobile Router receives Binding Acknowledgements from the 519 Home Agent, corresponding to the Binding Updates it sent. If the 520 Binding Acknowledgement status is set to '2' (Mobile Router Binding 521 Update accepted), the Mobile Router assumes that the Home Agent has 522 successfully processed the Binding Update and has set up forwarding 523 for the Mobile Network.The Mobile Router can then start using the 524 bi-directional tunnel for reverse tunneling traffic from the mobile 525 network. 527 5.4. Error Processing 529 If the Binding Acknowledgement status is set to a value between 128 530 and 140, the Mobile Router takes necessary actions as described in 531 the Mobile IPv6 specification [1]. 533 If the Binding Acknowlegement status is set to '0' (Binding Update 534 accepted), the Mobile Router concludes that the Home Agent which 535 processed the Binding Update is a MIPv6 Home Agent that has not 536 implemented support for Mobile Routers. It should send a similar 537 Binding Update to another Home Agent on the link. If no Home Agent 538 replies positively then the Mobile Router MUST refrain from sending 539 any Binding Update with the Mobile Router flag set to any home agent 540 on the home link and log the information. 542 If the Mobile Router sent a Binding Update to the Home Agent in 543 implicit mode (i.e. the prefix field in the Binding Update list 544 entry is null) then the Mobile Router interprets only the error 545 status '140' (Mobile Router Operation not permitted) and '143' 546 (Forwarding Setup failed) For this Binding Update, the Mobile Router 547 MUST discard Binding Acknowledgements with codes '141' and '142'. 549 For the same Binding Update, if the status is '140', then the Mobile 550 Router should send a similar Binding Update (implicit mode) to 551 another Home Agent on the same home link. If no Home Agent replies 552 positively then the Mobile Router MUST refrain from sending any 553 Binding Update with the Mobile Router flag set to any Home Agent on 554 the home link, and log the information. 556 For the same Binding Update, if the status is '143', then the Mobile 557 Router should send a similar Binding Update (implicit mode) to 558 another Home Agent on the same home link. If no Home Agent replies 559 positively then Mobile Router SHOULD refrain from sending this 560 Binding Update to any Home Agent on the home link, and MAY send 561 Binding Updates in another mode (e.g. explicitly include a prefix) 562 to a Home Agent on the same home link. 564 If the Mobile Router sent a Binding Update to Home Agent in any other 565 mode than implicit mode (i.e. the prefix field in the Binding Update 566 list entry is not null) then the Mobile Router interprets only the 567 error status '141' (Invalid Prefix) and '142' (Not Authorized for 568 Prefix). For this Binding Update, the Mobile Router MUST discard 569 Binding Acknowledgements with codes '140' and '143'. 571 For the same Binding Update, if the status is set to '141', then the 572 Mobile Router should send a similar Binding Update (same explicit 573 prefix(es) or prefix lengths) to another Home Agent on the same home 574 link. If no Home Agent replies positively then Mobile Router SHOULD 575 refrain from sending this Binding Updates to any Home Agent on the 576 home link. At this point, Mobile Router MAY try to obtain and own a 577 prefix by the same means that it initially got attributed the Invalid 578 Prefix in question. Alternatively, Mobile Router MAY send Binding 579 Updates in another mode (e.g. implicit mode) to a Home Agent on the 580 same home link. 582 For the same Binding Update, if the status is set to '142', then the 583 Mobile Router should send a similar Binding Update (same explicit 584 prefix(es) or prefix lens) to another Home Agent on the same home 585 link. If no Home Agent replies positively then Mobile Router SHOULD 586 refrain from sending this Binding Updates to any Home Agent on the 587 home link. Additionally, the Home Agent MUST stop advertising 588 the respective prefix(es) in the mobile network with associated 589 Router Advertisements, and modify its own forwarding information 590 accordingly. Following this, the Mobile Router MAY send Binding 591 Updates in another mode (e.g. implicit) to a Home Agent on the same 592 home link. 594 If at the end of this Error Processing procedure the Mobile Router 595 has tried every available modes of sending Binding Updates and still 596 has not received a positive Binding Acknowledgement (status value 597 between 0 and 127) for this Home Address from any Home Agent on its 598 home link, then the Mobile Router MUST stop sending Binding Updates 599 with the Mobile Router flag set for this Home Address and log the 600 information. 602 In all the above cases, the Mobile Router MUST conclude that the Home 603 Agent did not create a binding cache entry for the Mobile Router's 604 Home Address. 606 5.5. Establishment of Bi-directional Tunnel 608 When a successful Binding Acknowledgement with status set to '2' 609 (Mobile Router Binding Update accepted) is received, the Mobile 610 Router set up its endpoint of the bi-directional tunnel. 612 The bi-directional tunnel between Mobile Router and Home Agent allows 613 packets to flow in both directions between these entities, while the 614 Mobile Router is connected to a Visited Link. The bi-directional 615 tunnel involves two virtual links [3]: one virtual link has the 616 address of the tunnel entry point as the Care-of Address of the 617 Mobile Router and the tunnel exit point as the address of the 618 Home Agent; the other virtual link has as tunnel entry point the 619 Home Agent address and as tunnel exit point the Care-of Address 620 of the Mobile Router. Both addresses are unicast addresses. All 621 IPv6 traffic to and from the Mobile Network is sent through this 622 bi-directional tunnel. 624 A Mobile Router MAY limit the number of mobile routers that attach to 625 its mobile network (the number of levels in the nested aggregation) 626 by means of setting the Tunnel Encapsulation Limit field of the 627 Tunnel Encapsulation option. 629 A Mobile Router uses the Tunnel Hop Limit that is normally assigned 630 to routers (not to hosts). See [3]. 632 5.6. Neighbour Discovery for Mobile Router 634 A Mobile Router MAY be configured to send Router Advertisements and 635 reply to Router Solicitations on the interface attached to the home 636 link. The value of the Router Lifetime field MUST be set to zero to 637 prevent other nodes from configuring the Mobile Router as the default 638 router. 640 A Mobile Router SHOULD NOT send unsolicited Router Advertisements 641 and SHOULD NOT reply to Router Solicitations on any egress interface 642 when that interface is attached to a visited link. However, the 643 Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor 644 Solicitations received on the egress interface, for topologically 645 correct addresses. 647 A Mobile Router MUST NOT ignore Router Advertisements received on 648 the egress interface. The received Router Advertisements MAY be 649 used for address configuration, default router selection or movement 650 detection. 652 5.7. Multicast Groups for Mobile Router 654 When at home, the Mobile Router joins the multicast group All Routers 655 Address with scopes '1' interface-local (on the home-advertising 656 interface) and '2' link-local on any of its egress interfaces. When 657 in a visited network, the Mobile Router MUST NOT join the above 658 multicast groups on the corresponding interface. 660 6. Home Agent Operation 662 In order for a Mobile Router to operate correctly, the Home Agent 663 MUST satisfy all the requirements listed in section 8.4 of [1]. The 664 Home Agent MUST implement all the modes described in Section 5.2. 666 6.1. Data Structures 668 6.1.1. Binding Cache 670 The Home Agent maintains Binding Cache Entries for each Mobile Router 671 that is currently registered with the Home Agent. The Binding Cache 672 is a conceptual data structure described in detail in [1]. 674 The Home Agent might need to store the Mobile Network Prefixes 675 associated with a Mobile Router in the corresponding Binding Cache 676 Entry. This is required if the Binding Update (that created the 677 Binding Cache Entry) contained explicit prefix information. This 678 information can be used later to cleanup routes installed in explicit 679 mode, when the Binding Cache Entry is removed, and to maintain the 680 routing table, for instance should the routes be manually removed. 682 The Home Agent also stores the status of the Mobile Router Flag 'R' 683 in the Binding Cache entry. 685 6.1.2. Prefix Table 687 In some deployment scenarios it may be necessary for the Home Agent 688 to prevent a misbehaving Mobile Router from claiming mobile network 689 prefixes belonging to another Mobile Router. The Home Agent can 690 prevent such attacks if it maintains a Prefix Table and verifies the 691 Prefix Information provided by the Mobile Router against the entries 692 in the Prefix Table. However, this verification is done only if the 693 Binding Update contained explicit prefix information in the form of 694 either the Mobile Network Prefix Option or the Mobile Network Prefix 695 Length Option. 697 Each entry in the Prefix Table conceptually contains the following 698 fields: 700 - The Home Address of the Mobile Router. This field is used as the 701 key for searching the pre-configured prefix table. 703 - The Mobile Network Prefix of the Mobile Router associated with 704 the Home Address. 706 6.2. Mobile Network Prefix Registration 708 The Home Agent processes the Binding Update as described in section 709 10.3.1 of the Mobile IPv6 specification [1]. This section describes 710 the processing of the Binding Update if the Mobile Router (R) flag is 711 set. The Home Agent performs the following check in addition. 713 - The Home Registration (H) flag MUST be set. If not, the 714 Home Agent MUST reject the Binding Update and send a Binding 715 Acknowledgement with status set to 140. Note: The basic support 716 does not allow sending Binding Update for a Mobile Network Prefix 717 to correspondent nodes (for route optimization). 719 - If the Mobile Network Prefix Length option is present in 720 the Binding Update, then there MUST be only one instance of 721 this option in the Binding Update. Also the Mobile Network 722 Prefix Option MUST NOT be present in the same Binding Update. 723 Otherwise, the Home Agent MUST discard the Binding Update and 724 send an ICMP Parameter Problem, Code 0, message to the Mobile 725 Router. 727 If the Home Agent does not reject the Binding Update as described 728 above, then it retrieves the Mobile Network Prefix information as 729 described below. 731 - If a Mobile Network Prefix Length Option is present in the 732 Binding Update, the Home Address in the Home Address destination 733 option MUST be an Home Address. In that case, the Mobile Network 734 Prefix is obtained from that Home Address and the prefix length 735 in the Mobile Network Prefix Length Option. 737 If the Home Agent verfies the prefix information with the Prefix 738 Table and the check fails, the Home Agent MUST discard the 739 Binding Update and send a Binding Acknowldegement with status set 740 to 142 (Not Authorized for Prefix). 742 - If a Mobile Network Prefix Option is present in the Binding 743 Update, the prefix information for the mobile network prefix is 744 retrieved from the Mobile Network Prefix field and the Prefix 745 Length field of the option. If the Binding Update contains more 746 than one option, the Home Agent MUST set up forwarding for all of 747 the Mobile Network Prefixes. If the Home Agent fails to setup 748 forwarding to all the prefixes listed in the Binding Update, then 749 it MUST NOT forward traffic to any of the prefixes, reject the 750 Binding Update and send a Binding Acknowledgement with status set 751 to 141 (Invalid Prefix). 753 If the Home Agent verifies the prefix information with the Prefix 754 Table and the check fails, the Home Agent MUST discard the 755 Binding Update and send a Binding Acknowldegement with status set 756 to 142 (Not Authorized for Prefix). 758 - If there are no options in the Binding Update, the Home Agent 759 uses manual pre-configured information to determine the prefixes 760 assigned to the Mobile Router and for setting up forwarding for 761 the Mobile Network. If there is no information that the Home 762 Agent can use, it MUST reject the Binding Update and send a 763 Binding Acknowledgement with status set to 143 (Forwarding Setup 764 failed). 766 If the Lifetime specified in the Binding Update is zero or the 767 specified Care-of address matches the Home Address in the Binding 768 Update, then this is a request to delete the cached binding for 769 the home address and specified Mobile Network Prefixes. The 770 Binding Update is processed according to the procedure described in 771 section 6.7. 773 If all checks are passed, the Home Agent creates a binding cache 774 entry for Mobile Router's Home Address, or updates the binding cache 775 entry if it already exists. Otherwise, the Home Agent MUST NOT 776 register the binding of the Mobile Router's Home Address. 778 The Home Agent defends the Mobile Router's Home Address through Proxy 779 Neighbor Discovery by multicasting onto the home like a Neighbor 780 Advertisement message on behalf of the mobile router. All fields in 781 each such Neighbor Advertisement message SHOULD be set in the same 782 way they would be set by the mobile router itself if sending this 783 Neighbor Advertisement while at home, as described in [7], with the 784 exception that the Router (R) bit in the Advertisement MUST be set if 785 the Mobile Router (R) flag has been set in the Binding Update. 787 The Home Agent also creates a bi-directional tunnel to the mobile 788 router for the requested Mobile Network Prefix, or update an existing 789 bi-directional tunnel as described in section 6.4. 791 6.3. Advertising Mobile Network Reachability 793 In order to be able to receive packets meant for the mobile network, 794 the Home Agent advertises reachability to the mobile network. If the 795 Home Link is configured with a prefix that is an aggregation and if 796 the Mobile Network Prefix is aggregated under that prefix, then the 797 routing updates advertising reachability to the mobile network are 798 sent only on the Home Link. If the Home Agent is the only default 799 router on the Home Link, routes to the Mobile Network Prefix get 800 aggregated naturally under the Home Agent and the Home Agent does not 801 have to do anything special. 803 If the Home Agent receives routing updates through a dynamic routing 804 protocol from the Mobile Router, those routes are propagated by 805 the routing protocol running on the Home Agent on the relevant 806 interfaces. 808 6.4. Establishment of Bi-directional Tunnel 810 The establishment and operation of the bi-directional tunnel is 811 implementation specific. However, all implementations MUST be 812 capable of the following operations. 814 - The Home Agent can tunnel packets meant for the mobile network 815 prefix to the Mobile Router's current location, the Care-of 816 Address of the Mobile Router. 818 - The Home Agent can accept packets tunneled by the Mobile Router 819 with source address of the outer IPv6 header set to the Care-of 820 Address of the Mobile Router. 822 6.5. Forwarding Packets 824 When the Home Agent receives a data packet destined for the mobile 825 network, it fowards the packet to the Mobile Router through the 826 bi-directional tunnel. The Home Agent either uses only the routing 827 table, only the Binding Cache or a combination of routing table 828 and Binding Cache to route packets to the mobile network. This is 829 implementation specific. Two examples are shown below. 831 1. The Home Agent maintains a route to the Mobile Network Prefix 832 with the next hop set to the Mobile Router's Home Address. When 833 the Home Agent tries to forward the packet to the next hop, it 834 finds a binding cache entry for the home address. Then the Home 835 Agent extracts the Mobile Router's Care-of address and tunnels 836 the packet to the Care-of address. 838 2. The Home Agent maintains a route to the Mobile Network Prefix 839 with the outgoing interface set to the bi-directional tunnel 840 interface between the Home Agent and the Mobile Router. For 841 this purpose, the Home Agent MUST treat this tunnel as a tunnel 842 interface. When the packets are forwarded through the tunnel 843 interface, they get encapsulated automatically with the source 844 address and destination address in the outer IPv6 header set to 845 the Home Agent's address and the Mobile Router's Care-of address, 846 respectively. 848 6.6. Sending Binding Acknowledgements 850 A Home Agent serving a Mobile Router sends Binding Acknowledgements 851 according to the same rules it uses for sending Binding 852 Acknowledgements to Mobile Hosts, with the following enhancements. 854 The Home Agent sets the status code in the Binding Acknowledgement 855 to '2' (Mobile Router Binding Update accepted) in order to indicate 856 to the Mobile Router that it accepted the Binding Update, set up the 857 tunnel endpoint and the necessary forwarding information. 859 If the Home Agent is configured not to support mobile routers, it 860 sets the status code in the Binding Acknowledgement to '140' (Mobile 861 Router Operation not permitted). 863 If one or more prefixes received in the Binding Update are invalid 864 and the Home Agent cannot setup forwarding for the prefixes, the Home 865 Agent sets the status code in the Binding Acknowledgement to '141' 866 (Invalid Prefix) in order to indicate this to the Mobile Router. 868 If the Mobile Router is not authorized to use this Home Address to 869 forward packets for one or more prefixes that are present in the 870 Binding Update, the Home Agent sets the status code in the Binding 871 Acknowledgement to '142' (Not Authorized for Prefix) in order to 872 indicate this. 874 The Home Agent sets the status code to 143 (Forwarding Setup 875 failed) if it is unable to determine the information needed to setup 876 forwarding for the Mobile Network. This is used in the Implicit mode 877 where the Mobile Router does not include any prefix information in 878 the Binding Update. 880 6.7. Mobile Network Prefix De-Registration 882 The Mobile Router de-registers with the Home Agent by sending a 883 Binding Update with the lifetime set to zero. When the Home Agent 884 successfully processes the de-registration BU, it deletes the Binding 885 Cache Entry for the Mobile Router's Home Address and stops proxying 886 the Home Address. This is described in detail in the Mobile IPv6 887 specification [1]. 889 In addition, the Home Agent also removes the bi-directional tunnel 890 and stops forwarding packets to the mobile network. The HA should 891 keep all necessary information to clean up whichever routes it 892 installed, whether they come from implicit or explicit source. 894 7. Support for Dynamic Routing Protocols 896 In the solution described so far, forwarding to the Mobile Network 897 at the Home Agent is set up when the Home Agent receives a Binding 898 Update from the Mobile Router. An alternative to this is for the 899 Home Agent and the Mobile Router to run a intra-domain routing 900 protocol like RIPng [10] and OSPF [11] through the bi-directional 901 tunnel. The Mobile Router can continue running the same routing 902 protocol that it was running when it was attached to the home link. 904 This feature is very useful when the Mobile Network is large with 905 multiple subnets containing different IPv6 prefixes. Routing changes 906 in the Mobile Network are propagated to the Home Agent quickly. 907 Routing changes in the home link are also propogated to the Mobile 908 Router very quickly. 910 When the Mobile Router is attached to the home link, it runs a 911 routing protocol by sending routing updates through its egress 912 interface. When the mobile router moves and attaches to a visited 913 network, it MUST stop sending routing updates on the interface with 914 which it attaches to the visited link. This is very important so 915 that IPv6 prefixes specific to the Mobile Network do not leak into 916 the visited network. The Mobile Router then starts sending routing 917 protocol messages through the bi-directional tunnel towards the Home 918 Agent. Most routing protocols use link local addresses as source 919 addresses for the routing information messages. The Mobile Router is 920 allowed to use link local addresses for the inner IPv6 header of an 921 encapsulated packet. But these messages after decapsulation MUST NOT 922 be forwarded to another link by either the Mobile Router or the Home 923 Agent. 925 When the Home Agent receives the encapsulated routing protocol 926 message, it processes the inner packets and updates its routing table 927 accordingly. The next hop information in these routing entries is 928 filled with the Mobile Router's link local address with the outgoing 929 interface set to the bi-directional tunnel. 931 Similary, the Home Agent also sends routing updates through the 932 bi-directional tunnel to the Mobile Router. The Mobile Router 933 processes these routing protocol messages and updates its routing 934 table. For all routes advertised by the Home Agent, the Mobile 935 Router sets the outgoing interface to the bi-directional tunnel to 936 the Home Agent. 938 When the Mobile Router and the Home Agent exchange routes through 939 a dynamic routing protocol, the Mobile Router should be careful in 940 including the same mobile network prefixes in the Binding Update to 941 the HA and in the routing protocol updates. The HA depending on its 942 configuration might not add routes based on the prefix information in 943 the Binding Updates at all, and might use only the routing protocol 944 updates. Moreover, including the same prefix information in both the 945 Binding Update and the routing protocol update is redundant. 947 The tunneled routing messages MUST be authenticated and encrypted by 948 using IPsec ESP [4] in tunnel mode. 950 8. Security Considerations 952 All signaling messages between the Mobile Router and the Home Agent 953 MUST be authenticated by IPsec [5]. The use of IPsec to protect 954 Mobile IPv6 signaling messages is described in detail in the HA-MN 955 IPsec specification [2]. The signaling messages described in this 956 document just extend Mobile IPv6 messages and do not require any 957 changes to what is described in the HA-MN IPsec specification. 959 The Home Agent has to verify that packets received through the 960 bi-directional tunnel belong to the Mobile Network. This check is 961 necessary in order to prevent nodes from using the Home Agent to 962 launch attacks that would have otherwise been prevented by ingress 963 filtering. The source address of the outer IPv6 header MUST be set 964 the Mobile Router's current Care-of address. The source address of 965 the inner IPv6 header MUST belong to the Mobile Network Prefix owned 966 by the Mobile Router. 968 When the Mobile Router is running a dynamic routing protocol as 969 described in section 7, it injects routing update messages into the 970 Home Link. The Home Agent MUST verify that the Mobile Router is 971 allowed to send routing updates before processing the messages and 972 propagating the routing information. 974 Please refer to the Mobile IPv6 specification [1] for security 975 considerations when the Mobile Router operates as a Mobile Host. 977 9. IANA Considerations 979 This document defines two new Mobility Header Options. 981 - Mobile Network Prefix Option. 983 - Mobile Network Prefix Length Option. 985 These options are described in section 4.3 and section 4.4. The type 986 values for these options need to assigned from the same space used by 987 the mobility options defined in [1] 989 10. Contributors 991 We would like to acknowledge Ludovic Bellier, Claude Castelluccia, 992 Thierry Ernst, Miguel Catalina-Gallego, Christophe Janneteau, T.J. 993 Kniveton, Hong-Yon Lach, Jari T. Malinen, Koshiro Mitsuya, Alexis 994 Olivereau, Charles E. Perkins and Keisuke Uehara, for their work on 995 earlier proposals for Network Mobility. This document inherits a lot 996 of ideas from these proposals. 998 11. Acknowledgements 1000 We thank all members of the NEMO Working Group, and of the preceding 1001 MONET BoF for fruitful discussions on the mailing list and at IETF 1002 meetings. 1004 Kent Leung, Marco Molteni and Patrick Wetterwald for their work on 1005 Network Mobility for IPv4 and IPv6. 1007 Tim Leinmueller for many insightful remarks and implementation 1008 aspects. 1010 Normative References 1012 [1] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6. 1013 Internet Draft, IETF. draft-ietf-mobileip-ipv6-24.txt (work in 1014 progress). June 2003. 1016 [2] J. Arkko, V. Devarapalli and F. Dupont. Using IPsec to Protect 1017 Mobile IPv6 Signaling between Mobile Nodes and Home Agents. 1018 Internet Draft, IETF. draft-ietf-mobileip-mipv6-ha-ipsec-06.txt 1019 (work in progress). June 2003. 1021 [3] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 1022 Specification. RFC 2473, IETF. December 1998. 1024 [4] S. Kent and R. Atkinson. IP Encapsulating Security Payload 1025 (ESP). RFC 2402, IETF. November 1998. 1027 [5] S. Kent and R. Atkinson. Security Architecture for the Internet 1028 Protocol. RFC 2401, IETF. November 1998. 1030 [6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1031 Specification. RFC 2460, IETF. December 1998. 1033 [7] T. Narten, E. Nordmark and W. Simpson. Neighbour Discovery for 1034 IP Version 6 (IPv6). RFC 2461, IETF. December 1998. 1036 Informative References 1038 [8] T. Ernst and H.-Y. Lach. Network Mobility Support Terminology. 1039 Internet Draft, IETF. draft-ietf-nemo-terminology-00.txt (work 1040 in progress). May 2003. 1042 [9] T. Ernst. Network Mobility Support Goals and Requirements. 1043 Internet Draft, IETF. draft-ietf-nemo-requirements-01.txt (work 1044 in progress). May 2003. 1046 [10] G. Malkin and R. Minnear. RIPng for IPv6. RFC 2080, IETF. 1047 January 1997. 1049 [11] R. Coltun, D. Ferguson and J. Moy. OSPF for IPv6. RFC 2470, 1050 IETF. December 1999. 1052 A. Examples of Operation 1054 This section tries to illustrate the NEMO protocol using a Mobile 1055 Router and a Mobile Node belonging to different administrative 1056 domains. The Mobile Router's mobile network consists of a Local 1057 Fixed Node (LFN) and a Local Fixed Router (LFR) [8]. The LFR has 1058 an access link to which other Mobile Nodes or Mobile Routers could 1059 attach to. 1061 Figure 1 depicts the scenario where both the Mobile Router and the 1062 Mobile Node are at home. 1064 +----+ +-------+ 1065 | MN | | HA_MN | 1066 +--+-+ 1:: +---+---+ 1067 2+-------------+3 1068 | 1069 | 1070 +-------+2 2:: +-------------------+ 3:: 2+-------+ 1071 | CN_MN |------| Internet |------| CN_MR | 1072 +-------+ +-------------------+ +-------+ 1073 4:: | 1074 | 1075 2+-------------+3 1076 +--+-+ +---+---+ 1077 | MR | | HA_MR | 1078 +--+-+ +-------+ 1079 5:: |1 1080 ---------- 1081 2| |3 1082 +--+-+ +--+-+ 1083 | LFN| | LFR| 1084 +--+-+ +--+-+ 1085 6:: |1 1086 ---------- 1088 Figure 1: Mobile Router and Mobile Node at home. 1090 The Mobile Router then moves away from the home link and attaches to 1091 a visited link. This is shown in Figure 2. The Mobile Router sends 1092 a Binding Update to HA_MR when it attaches to a visited link and 1093 configures a Care-of Addres. HA_MR creates a binding cache entry for 1094 the Mobile Router's Home Address and also sets up forwarding for the 1095 prefixes on the mobile network. 1097 +----+ +-------+ 1098 | MN | | HA_MN | 1099 +--+-+ 1:: +---+---+ 1100 2+-------------+3 1101 | 1102 | 1103 +-------+2 2:: +-------------------+ 3:: 2+-------+ 1104 | CN_MN |------| Internet |------| CN_MR | 1105 +-------+ ++------------------+ +-------+ 1106 | 7:: 4:: | 4::2->7::2 1107 | | 1108 2+ +3 1109 +--+-+ +---+---+ 1110 | MR | | HA_MR | 4::2->7::2 1111 +--+-+ +-------+ 5::/prefixlen -> forward 1112 5:: |1 to MR 1113 ---------- 6::/prefixlen -> forward 1114 2| |3 to MR 1115 +--+-+ +--+-+ 1116 | LFN| | LFR| 1117 +--+-+ +--+-+ 1118 6:: |1 1119 ---------- 1121 Figure 2: Mobile Router on a Visited Link. 1123 Figure 3 shows the Mobile Node moving away from its home link and 1124 attaching to the Mobile Router. The Mobile Node configures a Care-of 1125 Address from the prefix advertised on the mobile network and sends a 1126 Binding Update to its Home Agent (HA_MN) and its Correspondent Node 1127 (CN_MN). Both HA_MN and CN_MN create binding cache entries for the 1128 Mobile Node's Home Address. 1130 +-------+ 1131 | HA_MN | 1::2->6::2 1132 1:: +---+---+ 1133 ---------|3 1134 | 1135 | 1136 +-------+2 2:: +-------------------+ 3:: 2+-------+ 1137 | CN_MN |------| Internet |------| CN_MR | 1138 +-------+ ++------------------+ +-------+ 1139 1::2->6::2 | 7:: 4:: | 4::2->7::2 1140 | | 1141 2+ +3 1142 +--+-+ +---+---+ 1143 | MR | | HA_MR | 4::2->7::2 1144 +--+-+ +-------+ 5::/prefixlen -> forward 1145 5:: |1 to MR 1146 ---------- 6::/prefixlen -> forward 1147 2| |3 to MR 1148 +--+-+ +--+-+ 1149 | LFN| | LFR| 1150 +--+-+ +--+-+ 1151 6:: |1 1152 --------+- 1153 |2 1154 +--+-+ 1155 | MN | 1156 +----+ 1158 Figure 3: Mobile Node attached to Mobile 1159 Router on a Visited Link 1161 B. Changes from Previous Version 1163 The following changes have been made to this document from version 00 1165 - Clarified that Router flag must be set in the Proxy Neighbor 1166 Advertisement sent for a Mobile Router by the Home Aagent. 1167 (Issue 1). 1169 - Clarified that if the Router flag in the Binding Update is set, 1170 then the HA should assume that the Mobile Router wants to be 1171 treated as a mobile node. (Issue 3). 1173 - Added text to make it clear that the Home Agent must perform 1174 ingress filtering on all packets reverse tunneled by the Mobile 1175 Router. (Issue 3). 1177 - Extended Home Network concept has been removed from this 1178 document. (Issue 5). 1180 - Added text to clarify differences between Implicit mode and 1181 running a dynamic routing protocol. (Issue 6). 1183 - Clarified that Prefix Table is used only in explicit mode. In 1184 Implicit mode the Prefix Table is not used. (Issue 7 and 12). 1186 - Added text to specify the Home Agent must support all modes. The 1187 Mobile Router needs to support only one mode. (Issue 11). 1189 - Added text to support interoperability between a Mobile Router 1190 and a legacy MIPv6 Home Agent. (Issue 15). 1192 Authors Addresses 1194 Vijay Devarapalli 1195 Nokia Research Center 1196 313 Fairchild Drive 1197 Mountain View, CA 94043 1198 USA 1199 Email: vijay.devarapalli@nokia.com 1201 Ryuji Wakikawa 1202 Keio University and WIDE 1203 5322 Endo Fujisawa Kanagawa 1204 252-8520 Japan 1205 Email: ryuji@sfc.wide.ad.jp 1207 Alexandru Petrescu 1208 Motorola Labs 1209 Parc les Algorithmes Saint Aubin 1210 Gif-sur-Yvette 91193 1211 France 1212 Email: Alexandru.Petrescu@motorola.com 1214 Pascal Thubert 1215 Cisco Systems Technology Center 1216 Village d'Entreprises Green Side 1217 400, Avenue Roumanille 1218 Biot - Sophia Antipolis 06410 1219 France 1220 Email: pthubert@cisco.com 1222 Full Copyright Statement 1224 Copyright (C) The Internet Society (2003). All Rights Reserved. 1226 This document and translations of it may be copied and furnished to 1227 others, and derivative works that comment on or otherwise explain it 1228 or assist in its implementation may be prepared, copied, published 1229 and distributed, in whole or in part, without restriction of any 1230 kind, provided that the above copyright notice and this paragraph 1231 are included on all such copies and derivative works. However, 1232 this document itself may not be modified in any way, such as by 1233 removing the copyright notice or references to the Internet Society 1234 or other Internet organizations, except as needed for the purpose 1235 of developing Internet standards in which case the procedures 1236 for copyrights defined in the Internet Standards process must be 1237 followed, or as required to translate it into languages other than 1238 English. 1240 The limited permissions granted above are perpetual and will not be 1241 revoked by the Internet Society or its successors or assignees. 1243 This document and the information contained herein is provided on an 1244 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1245 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1246 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1247 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1248 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1250 Acknowledgement 1252 Funding for the RFC Editor function is currently provided by the 1253 Internet Society.