idnits 2.17.1 draft-ietf-nemo-basic-support-00.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 351: '... addition to what is defined [1]. The receiver MUST skip and...' RFC 2119 keyword, line 511: '... MUST use one of the following modes...' RFC 2119 keyword, line 545: '...ngth Option. It MUST not include a Mo...' RFC 2119 keyword, line 548: '...t, The Mobile Router MUST also set the...' RFC 2119 keyword, line 576: '... SHOULD send a similar Binding Updat...' (44 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: In this mode, the Mobile Router instructs the Home Agent to derive the Mobile Network Prefix by using: (1) the Home Address in the Home Address Option carried in the Destination Options header of the same packet that carries the Mobility Header containing this Binding Update and (2) the prefix length carried in the Mobile Network Prefix Length Option. In this case, Mobile Router includes one and only one Mobile Network Prefix Length Option. It MUST not include a Mobile Network Prefix Option if this method is used. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - If the Mobile Network Prefix Length option is present in the Binding Update, then there MUST be only one instance of this option in the Binding Update. Also the Mobile Network Prefix Option MUST not be present in the same Binding Update. Otherwise, the Home Agent MUST discard the Binding Update and send an ICMP Parameter Problem, Code 0, message to the Mobile Router == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: - If a Mobile Network Prefix Option is present in the Binding Update, the prefix information for the mobile network prefix is retrieved from the Mobile Network Prefix field and the Prefix Length field of the option. If the Binding Update contains more than one option, the Home Agent MUST set up forwarding for all of the Mobile Network Prefixes. Otherwise the Home Agent MUST not forward traffic to any of the prefixes, reject the Binding Update and send a Binding Acknowledgement with status set to 141 (Invalid Prefix). -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 1120, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-22 == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-00 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '2') == Outdated reference: A later version (-06) exists of draft-ietf-mobileip-mipv6-ha-ipsec-05 ** Obsolete normative reference: RFC 2402 (ref. '5') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2460 (ref. '8') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '9') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3344 (ref. '10') (Obsoleted by RFC 5944) Summary: 10 errors (**), 0 flaws (~~), 9 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 21 June 2003 Ryuji Wakikawa 4 Category: Standards Track Keio University 5 Alexandru Petrescu 6 Motorola 7 Pascal Thubert 8 Cisco Systems 10 Nemo Basic Support Protocol 11 draft-ietf-nemo-basic-support-00.txt 13 Status of This Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document describes a protocol to support network mobility as the 36 mobile network attaches to different points in the Internet. The 37 protocol allows for session continuity for every node in the mobile 38 network as the network moves. It also allows every node in the 39 mobile network to be reachable while moving around. The protocol is 40 based on extensions to Mobile IPv6 [1]. The Mobile Router [2] which 41 connects the network to the Internet runs the NEMO protocol with its 42 Home Agent. The protocol is designed in such a way that network 43 mobility is transparent to the nodes inside the mobile network. 45 Contents 47 Status of This Memo 1 49 Abstract 1 51 1. Introduction 4 53 2. Terminology 5 55 3. Overview of the NEMO Protocol 7 57 4. Message Formats 10 58 4.1. Binding Update . . . . . . . . . . . . . . . . . . . . . 10 59 4.2. Binding Acknowledgement . . . . . . . . . . . . . . . . . 10 60 4.3. Mobile Network Prefix Option . . . . . . . . . . . . . . 11 61 4.4. Mobile Network Prefix Length Option . . . . . . . . . . . 12 63 5. Mobile Router Operation 14 64 5.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 14 65 5.2. Sending Binding Updates . . . . . . . . . . . . . . . . . 15 66 5.3. Receiving Binding Acknowledgements . . . . . . . . . . . 15 67 5.4. Error Processing . . . . . . . . . . . . . . . . . . . . 16 68 5.5. Establishment of Bi-directional Tunnel . . . . . . . . . 17 69 5.6. Neighbour Discovery for Mobile Router . . . . . . . . . . 18 70 5.7. Multicast Groups for Mobile Router . . . . . . . . . . . 18 72 6. Home Agent Operation 19 73 6.1. Prefix Table . . . . . . . . . . . . . . . . . . . . . . 19 74 6.2. Mobile Network Prefix Registration . . . . . . . . . . . 19 75 6.3. Advertising Mobile Network Reachability . . . . . . . . . 21 76 6.4. Establishment of Bi-directional Tunnel . . . . . . . . . 21 77 6.5. Forwarding Packets . . . . . . . . . . . . . . . . . . . 21 78 6.6. Sending Binding Acknowledgements . . . . . . . . . . . . 22 79 6.7. Mobile Network Prefix De-Registration . . . . . . . . . . 23 81 7. Extended Home Network 24 83 8. Support for Dynamic Routing Protocols 26 85 9. Use of IPsec to protect the Signaling Messages 27 87 10. Security Considerations 28 89 11. IANA Considerations 28 90 12. Contributors 28 92 13. Acknowledgements 28 94 A. Examples of Operation 31 96 Addresses 34 97 1. Introduction 99 This document describes protocol extensions to Mobile IPv6 (MIPv6) 100 [1] to enable support for network mobility. The extensions provide 101 a backward compatibility with Mobile IPv6, and in particular, a Nemo 102 compliant Home Agent can operate as a MIPv6 Home Agent as well. 104 The Nemo Basic Support works in such a way that session continuity is 105 ensured for all the nodes in the mobile network even as the Mobile 106 Router changes its point of attachment to the Internet. It also 107 provides connectivity and reachability for all nodes in the mobile 108 network as the network moves. The solution supports both Local Fixed 109 Nodes [2] and Mobile Nodes in the Mobile Metwork. 111 Within the context of this document, the definition of a Mobile 112 Router extends that of a Mobile IPv6 [1] Mobile Node, by adding 113 the capability of routing between its point of attachment (Care-of 114 Address) and a subnet which moves with the Mobile Router. 116 The solution described in this document requires setting up a 117 bi-directional tunnel between the Mobile Router and its Home Agent. 118 This tunnel is set up when the Mobile Router sends a successful 119 Binding Update to its Home Agent, informing the Home Agent of its 120 current point of attachment. 122 All traffic between the nodes in the Mobile Network and Correspondent 123 Nodes passes through the Home Agent. This document does not describe 124 how to route optimize this traffic. Route Optimization will be dealt 125 with in later specifications. 127 IPsec is used to secure all signalling messages between the Mobile 128 Router and its Home Agent. The use of IPsec to protect the signaling 129 messages is described in [3]. This document does not introduce any 130 additional requirements as far as the use of IPsec is concerned. 132 The terminology document [2] describes Nested Mobility as a scenario 133 where a Mobile Router allows another Mobile Router to attach to its 134 mobile network. There could be arbitrary levels of nested mobility. 135 The operation of each Mobile Router remains the same whether the 136 Mobile Router attaches to another Mobile Router or to a fixed Access 137 Router on the Internet. The solution described here does not place 138 any restriction on the number of levels for nested mobility. But 139 it should be noted that this might introduce important overhead on 140 the data packets as each level of nestedness introduces another IPv6 141 header encapsulation. 143 2. Terminology 145 There is a separate NEMO terminology document [2], which defines the 146 terms related to Network Mobility used in the document. 148 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [2]. 152 Prefix Table 154 It is a list of a mobile network prefixes indexed 155 by the extended Home Address of a Mobile Router. The 156 prefix table is managed by the Home Agent. When a Home 157 Agent receives a Binding Update without any options, 158 it searches a correspondent Mobile Network prefix in 159 the prefix table, keying with the Home Address of the 160 requesting Mobile Router. This is an optional data 161 structure. 163 Mobile Network Prefix 165 The IPv6 prefix advertised in the Mobile Network 166 by one or more Mobile Routers. There could be multiple 167 prefixes in the Mobile Network. 169 extended Home Network Prefix 171 The aggregation of one or more Home Network and 172 Mobile Network prefixes. The extended Home Network 173 is generally the granularity that is exposed by the 174 Home Agents to the routing infrastructure over routing 175 protocols. 177 extended Home Network 179 The network associated with the extended Home 180 Network Prefix. The extended Home Network may be physical 181 or virtual. 183 extended Home Address 185 The Home Address is derived from the Home Network 186 prefix. The extended Home Address is taken from the 187 extended Home Network. More precisely, the extended Home 188 Address can be either from the Home Network or from one of 189 the Mobile Router's Mobile Network prefixes. The extended 190 Home Address inherits from the properties of the Home 191 Address and can be used for registration to the Home Agent 192 as described in this document. 194 3. Overview of the NEMO Protocol 196 A Mobile Network is a network segment or subnet which can move 197 and attach to arbitrary points in the Internet. A Mobile Network 198 does not allow any transit traffic and can only be accessed via 199 specific Gateways called Mobile Routers that manage its movement. 200 A Mobile Router does not distribute the Mobile Network routes to 201 the infrastructure at its point of attachment (i.e. in the visited 202 network). Instead, it maintains a bidirectional tunnel to a Home 203 Agent that advertises an aggregation of Mobile Networks to the 204 infrasructure. The Mobile Router is also the default gateway for the 205 Mobile Network. 207 A Mobile Network can also consist of multiple and nested subnets. In 208 particular, a router with no support for mobility may be permanently 209 attached to a Mobile Network for local distribution. Also, Mobile 210 Routers may be attached to Mobile Networks owned by different Mobile 211 Routers and form a graph. In particular, with Basic Nemo Support, 212 each Mobile Router is attached to another Mobile Network by a single 213 interface, and if loops are avoided, the graph is a tree. 215 A Mobile Router has an unique Home Address through which it is always 216 reachable. The Home Address is configured from a prefix that is 217 aggregated and advertised by its Home Agent. The prefix could either 218 be the prefix advertised on the home link or the prefix delegated 219 to the Mobile Router. This is described in detail in Section 7. 220 The Mobile Router can have more than one Home Address if there 221 are multiple prefixes in the home link. The Mobile Router also 222 advertises one or more prefixes in the mobile network attached to it. 223 The actual mechanism for allocating these Mobile Network Prefixes is 224 outside the scope of this specification. However, it is recommended 225 that these prefixes are allocated in such a manner that they can be 226 aggregated under the home link. 228 When the Mobile Router moves away from the home link and attaches 229 to a new access router, it acquires a Care-of Address from the 230 visited link. The Mobile Router at any time can appear and behave 231 as a Mobile Host or a Mobile Router. If the Mobile Router wants 232 connectivity, rechability and session continuity for nodes in the 233 Mobile Network, it acts as a Mobile Router. In either case, as soon 234 as the Mobile Router acquires a Care-of Address, it immediately sends 235 a Binding Update to its Home Agent as described in [1]. When the 236 Home Agent receives this Binding Update it creates a binding cache 237 entry binding the Mobile Router's Home Address to its Care-of address 238 at the current point of attachment. 240 If the Mobile Router wishes to act as a Mobile Router and provide 241 connectivity to nodes in the Mobile Network, it indicates this to 242 the Home Agent by setting a flag 'R' in the Binding Update. It also 243 includes information about the Mobile Network Prefix in the Binding 244 Update using one of the modes described in Section 5.2, so that 245 the Home Agent can forward packets meant for nodes in the mobile 246 network to the Mobile Router. Two new Mobility Header Options are 247 described in this document to carry prefix information. These new 248 options are described in Section 4.3 and section 4.4. If the Mobile 249 Network has more than one IPv6 prefix and wants the Home Agent to 250 setup forwarding for all these prefixes, it includes multiple prefix 251 information options in a single Binding Update. The Home Agent sets 252 up forwarding for each of these prefixes to the Mobile Router's 253 Care-of Address. In some scenarios the Home Agent already knows 254 which prefixes are owned by a Mobile Router. In these scenarios, the 255 Mobile Router does not include any prefix information in the Binding 256 Update. The Home Agent sets up forwarding for all prefixes owned by 257 the Mobile Router, when it receives a Binding Update from the mobile 258 router. 260 If the Home Agent successfully processes the Binding Update and 261 sets up forwarding for the Mobile Network Prefix, it sends a 262 Binding Acknowledgement to the Mobile Router. Once the binding 263 process completes, a bi-directional tunnel is established between 264 the Home Agent and the Mobile Router. The tunnel end points are 265 Mobile Router's Care-of Address and the Home Agent's address. If 266 a packet with a source address belonging to the Mobile Network 267 Prefix is received from the Mobile Network, the Mobile Router 268 reverse-tunnels the packet to the Home Agent through this tunnel. 269 This reverse-tunneling is done by using IP-in-IP encapsulation [4]. 270 The Home Agent decapsulates this packet and forwards it to the CN. 271 The Mobile Router is however free to use route optimization as 272 described in [1] for packet originated by the Mobile Router itself. 274 When a data packet is sent by a Correspondent Node to a node in the 275 Mobile Network, it gets routed to the Home Agent which currently 276 has the binding for the Mobile Router. It is expected that the 277 Mobile Router's network prefix would be aggregated at the Home 278 Agent, which advertises the resulting aggregation. Alternatively, 279 the Home Agent may receive the data packets meant for the Mobile 280 Network by advertising routes to the Mobile Network prefix. The 281 actual mechanism by which these routes are advertised is outside 282 the scope of this document for now. When the Home Agent receives a 283 data packet meant for a node in the mobile network, it tunnels the 284 packet to Mobile Router's current Care-of address. The Mobile Router 285 decapsulates the packet and forwards it onto the link where the 286 Mobile Network is connected. 288 The Mobile Network could consist of nodes which are Local Fixed 289 Nodes, Local Mobile Nodes and Visiting Mobile Nodes [2]. The 290 protocol described here ensures complete transparency of network 291 mobility to the Local Fixed Nodes. Visiting Mobile Nodes are those 292 nodes which are Mobile Nodes as described in Mobile IPv6. Visiting 293 Mobile Nodes treat the Mobile Network as just a normal IPv6 access 294 network and run the Mobile IPv6 protocol. 296 It is also possible for the Mobile Router and the Home Agent to 297 run a routing protocol through the bi-directional tunnel. The 298 Mobile Router need not include prefix information in the Binding 299 Update. Instead the Home Agent uses the routing protocol updates to 300 setup forwarding for the Mobile Network. When running the routing 301 protocol it is required that the bi-directional tunnel be treated as 302 a tunnel interface. The tunnel interface is included as the list of 303 interfaces on which routing protocol is active. The Mobile Router 304 should be careful to not run the routing protocol on its egress 305 interface when it is away from the home link. 307 Finally, the Home Agent(s) may be configured with static routes to 308 the Mobile Network Prefix via the Mobile Router home address.. In 309 that case, the routes are set independently of the binding flows and 310 the returning Home of a Mobile Router. The benefit is that such 311 movement does not induce any additional signalling in the form of 312 routing updates in the Home Network. The drawback of that model is 313 that the routes are present even if the Mobile Routers that are not 314 reachable (at Home or bound) at a given point of time. 316 4. Message Formats 318 4.1. Binding Update 320 A new flag `R' is included in the Binding Update to indicate to the 321 Home Agent if the Binding Update is coming from a Mobile Router 322 and not from a mobile node. The rest of the Binding Update format 323 remains the same as defined in [1]. 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Sequence # | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 |A|H|L|K|R| Reserved | Lifetime | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 . . 334 . Mobility options . 335 . . 336 | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Mobile Router Flag(R) 341 The Mobile Router Flag is set to indicate to the Home Agent 342 that the Binding Update is from a Mobile Router. If the flag 343 is set to 0, the Home Agent assumes that the Mobile Router is 344 just behaving as a Mobile Node, and should not forward packets 345 destined for the mobile network to the Mobile Router. 347 Mobility Options 349 Variable length field which can include zero or more mobility 350 options. This document defines two new mobility options in 351 addition to what is defined [1]. The receiver MUST skip and 352 ignore any options which it does not understand. 354 4.2. Binding Acknowledgement 356 There is no change in the Binding Acknowledgement format from what 357 is used in Mobile IPv6 [1]. However, this document introduces the 358 following new status values for the binding acknowledgement. 360 Status 361 140 Mobile Router Operation not permitted 363 141 Invalid Prefix 365 142 Not Authorized for Prefix 367 143 Mobile Network Prefix information unavailable. 369 Status values less than 128 indicate that the Binding Update was 370 processed successfully by the receiving nodes. Values greater than 371 128 indicate that the Binding Update was rejected by the receiving 372 node. 374 4.3. Mobile Network Prefix Option 376 The Mobile Network Prefix Option is included in the Binding Update 377 to indicate to the Home Agent the prefix information for the mobile 378 network. There could be multiple Mobile Network Prefix Options 379 if the Mobile Router has more than one IPv6 prefix in the Mobile 380 Network and wants the Home Agent to forward packets for each of these 381 prefixes to the Mobile Router's current location. 383 The Mobile Network Prefix Option has an alignment requirement of 384 8n+4. Its format is as follows. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type | Length | Reserved | Prefix Length | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | | 392 + + 393 | | 394 + Mobile Network Prefix + 395 | | 396 + + 397 | | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Type 402 TBD 404 Length 406 8 bit unsigned integer indicating the length in octets of the 407 option excluding the type and length fields. Set to 18. 409 Reserved 411 Set to 0. Ignored for now. 413 Prefix Length 415 8 bit unsigned integer indicating the length of the IPv6 prefix 416 contained in the option. 418 Mobile Network Prefix 420 A 16 byte field contains the Mobile Network Prefix. 422 4.4. Mobile Network Prefix Length Option 424 The Mobile Network Prefix Length Option can be used by the Mobile 425 Router if the Mobile Network Prefix can be deduced from the Home 426 Address of the Mobile Router. If there is only one Mobile Network 427 Prefix owned by the Mobile Router, using this option helps in 428 saving 16 bytes in the Binding Update by not including the prefix 429 information. 431 There can only be one instance of this option in a Binding Update. 432 The Mobile Network Prefix Option cannot be present in the Binding 433 Update if this option is present. 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Type | Length | Reserved | Prefix Length | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Type 443 TBD 445 Length 447 8 bit unsigned integer indicating the length in octets of the 448 option excluding the type and length field. Set to 2. 450 Reserved 452 Set to 0. Ignored for now. 454 Prefix Length 456 8 bit unsigned integer indicating the length of the IPv6 prefix 457 contained in the option 459 5. Mobile Router Operation 461 Mobile Router operation is derived largely from the combined 462 behaviors of a Host, of a Router [8], and of a Mobile Node [1] (also 463 please see definition of a Mobile Host in [2] and the definition of 464 an IPv4 Mobile Node [10]). 466 A Mobile Node can act in two different ways: (1) as a Mobile Host 467 (in which case the Mobile IPv6 Home Agent doesn't maintain any prefix 468 information related to the Mobile Host's Home Address, but does 469 maintain a binding cache entry related to the Mobile Host's Home 470 Address) and (2) as a Mobile Router (in which case, in addition to 471 maintaining the binding cache entry corresponding to the Mobile 472 Router Home Address, the Mobile IPv6 Home Agent also maintains 473 forwarding information related to prefixes assigned to the Mobile 474 Network). The distinction between the the two modes is represented 475 by the value of the 'R' bit. 477 Mobile Router uses various data structures, exchanges specific 478 binding messages with Home Agent, performs a specific Neighbour 479 Discovery behavior and joins certain multicast groups. 481 5.1. Data Structures 483 Like a Mobile Host, a Mobile Router also maintains a Binding Update 484 List, described in section 11.1 of Mobile IPv6 specification[1]. The 485 Binding Update list is a conceptual data structure which records 486 information that is sent in the Binding Updates. There is one entry 487 per each destination that the Mobile Router is currently sending 488 Binding Updates to. 490 This document introduces a new Prefix Information field in the 491 Binding Update list structure. This field is used to store any 492 prefix information that the Mobile Router includes in the Binding 493 Update. If the Mobile Router sets the 'R' bit in the Binding Update, 494 but does not include any prefix information in it (implicit mode), 495 this field is set to null. 497 Similar to a Mobile Host, a Mobile Router also stores the information 498 regarding status of flags of the Binding Update, in the corresponding 499 Binding Update List entry. Additionally, this document introduces a 500 new mobile router flag 'R' for this entry. The status of this flag 501 is stored in the Binding Update list whenever a Binding Update is 502 sent. 504 Similarly to a Mobile Host, a Mobile Router maintains a Home Agent 505 list populated according to the same procedure as a Mobile Host. 507 5.2. Sending Binding Updates 509 A Mobile Router will send Binding Updates to its Home Agent according 510 to the same procedures that a Mobile Host uses. The Mobile Router 511 MUST use one of the following modes to instruct the Home Agent to 512 determine the Mobile Network prefix. In all three modes, the Mobile 513 Router sets the 'R' bit to 1. 515 Implicit: 517 In this mode, the Mobile Router does not include either a 518 Mobile Network Prefix Option or a Mobile Network Prefix Length 519 Option in the Binding Update (but it does include the Home 520 Address Option in the Destination Options header, as all Mobile 521 Hosts do). The Home Agent can use any mechanism (not defined 522 in this document) to determine the Mobile Network Prefix(es) 523 owned the Mobile Router. One of the well known mechanisms is 524 where the Home Agent maintains a Pre-configured Prefix Table 525 listing all the Mobile Network prefixes owned by a particular 526 Mobile Router. This table is keyed on the Home Address of the 527 Mobile Router. 529 Explicit: 531 In this mode, the Mobile Router includes one or more Mobile 532 Network Prefix Options in the Binding Update. These options 533 contain information about the Mobile Network Prefix(es) 534 configured on the Mobile Network. 536 Explicit combined: 538 In this mode, the Mobile Router instructs the Home Agent to 539 derive the Mobile Network Prefix by using: (1) the Home 540 Address in the Home Address Option carried in the Destination 541 Options header of the same packet that carries the Mobility 542 Header containing this Binding Update and (2) the prefix length 543 carried in the Mobile Network Prefix Length Option. In this 544 case, Mobile Router includes one and only one Mobile Network 545 Prefix Length Option. It MUST not include a Mobile Network 546 Prefix Option if this method is used. 548 If the Mobile Router flag is set, The Mobile Router MUST also set the 549 Home Registration flag 'H'. 551 5.3. Receiving Binding Acknowledgements 553 The Mobile Router receives Binding Acknowledgements from the Home 554 Agent, corresponding to the Binding Updates it sent. If the Binding 555 Acknowledgement status is set to a value less than 128, the Mobile 556 Router assumes that the Binding Update was processed succesfully 557 by the Home Agent. The Mobile Router can then start using the 558 bi-directional tunnel for reverse tunneling traffic from the mobile 559 network. 561 5.4. Error Processing 563 If the Binding Acknowledgement status is set to a value between 128 564 and 140, the Mobile Router takes necessary actions as described in 565 the Mobile IPv6 specification [1]. 567 If the Mobile Router sent a Binding Update to the Home Agent in 568 implicit mode (i.e. the prefix field in the Binding Update list 569 entry is null) then the Mobile Router interprets only the error 570 status '140' (Mobile Router Operation not permitted) and '143' 571 (Mobile Network Prefix information unavailable). For this Binding 572 Update, the Mobile Router will discard Binding Acknowledgements with 573 codes '141' and '142', and log the information. 575 For the same Binding Update, if the status is '140', Mobile Router 576 SHOULD send a similar Binding Update (implicit mode) to another Home 577 Agent on the same home link. If no Home Agent replies positively 578 then the Mobile Router MUST refrain from sending any Binding Update 579 with the 'R' bit set to any Home Agent on the home link, and log the 580 information. 582 For the same Binding Update, if the status is '143', Mobile Router 583 SHOULD send a similar Binding Update (implicit mode) to another Home 584 Agent on the same home link. If no Home Agent replies positively 585 then Mobile Router SHOULD refrain from sending this Binding Update 586 to any Home Agent on the home link, and MAY send Binding Updates in 587 another mode (e.g. explicitly include a prefix) to a Home Agent on 588 the same home link. 590 If the Mobile Router sent a Binding Update to Home Agent in any other 591 mode than implicit mode (i.e. the prefix field in the Binding Update 592 list entry is not null) then the Mobile Router interprets only the 593 error status '141' (Invalid Prefix) and '142' (Not Authorized for 594 Prefix). For this Binding Update, the Mobile Router will discard 595 Binding Acknowledgements with codes '140' and '143', and log the 596 information. 598 For the same Binding Update, if the status is set to '141', then the 599 Mobile Router should send a similar Binding Update (same explicit 600 prefix(es) or prefix lens) to another Home Agent on the same home 601 link. If no Home Agent replies positively then Mobile Router SHOULD 602 refrain from sending this Binding Updates to any Home Agent on the 603 home link. At this point, Mobile Router MAY try try to obtain and 604 own a prefix by the same means that it initially got attributed the 605 Invalid Prefix in question. Alternatively, Mobile Router MAY send 606 Binding Updates in another mode (e.g. implicit mode) to a Home Agent 607 on the same home link. 609 For the same Binding Update, if the status is set to '142', then the 610 Mobile Router should send a similar Binding Update (same explicit 611 prefix(es) or prefix lens) to another Home Agent on the same home 612 link. If no Home Agent replies positively then Mobile Router SHOULD 613 refrain from sending this Binding Updates to any Home Agent on the 614 home link. Additionally, the Home Agent MUST stop advertising 615 the respective prefix(es) in the mobile network with associated 616 Router Advertisements, and modify its own forwarding information 617 accordingly. Following this, the Mobile Router MAY send Binding 618 Updates in another mode (e.g. implicit) to a Home Agent on the same 619 home link. 621 If at the end of this Error Processing procedure the Mobile Router 622 has tried every available modes of sending Binding Updates and still 623 has not received a positive Binding Acknowledgement (status valued 0) 624 for this Home Address from any Home Agent on its home link, then the 625 Mobile Router MUST stop sending Binding Updates with the 'R' bit set 626 for this Home Address and log the information. 628 In all the above cases, the Mobile Router should assume that the Home 629 Agent did not create a binding cache entry for the Mobile Router's 630 home address. 632 5.5. Establishment of Bi-directional Tunnel 634 Only when a successful Binding Acknowledgement ('Status' field valued 635 0) is received will the Mobile Router set up its endpoint of the 636 bi-directional tunnel. 638 The bi-directional tunnel between Mobile Router and Home Agent allows 639 packets to flow in both directions between these entities, while the 640 Mobile Router is connected to a Visisted Link. The bi-directional 641 tunnel involves two virtual links [4]: one virtual link has the 642 address of the tunnel entry point as the Care-of Address of the 643 Mobile Router and the tunnel exit point as the address of the Home 644 Agent; the other virtual link has as tunnel entry point the Home 645 Agent address and as tunnel exit point the Care-of Address of the 646 Mobile Router. Both addresses are unicast addresses. 648 Packets sent by the nodes in the mobile network (including the Mobile 649 Router) and addressed to any nodes other than nodes in the mobile 650 network are encapsulated by Mobile Router and decapsulated by the 651 Home Agent. Packets sent by any nodes other than nodes in the mobile 652 network and addressed to nodes in the mobile network are encapsulated 653 by the Home Agent and decapsulated by the Mobile Router. 655 A Mobile Router MAY limit the number of mobile routers that attach to 656 its mobile network (the number of levels in the nested aggregation) 657 by means of setting the Tunnel Encapsulation Limit field of the 658 Tunnel Encapsulation option. 660 A Mobile Router uses the Tunnel Hop Limit that is normally assigned 661 to routers (not to hosts); see IANA numbers. 663 Following the successful setup of the bi-directional tunnel on the 664 Mobile Router, the forwarding information on the Mobile Router is 665 updated such as to allow forwarding of packets as described above. 667 5.6. Neighbour Discovery for Mobile Router 669 A Mobile Router MAY be configured to send Router Advertisements and 670 reply to Router Solicitations on the interface attached to the home 671 link. The value of the Router Lifetime field MUST be set to zero to 672 prevent other nodes from configuring the Mobile Router as the default 673 router. 675 A Mobile Router SHOULD NOT send unsolicited Router Advertisements 676 and SHOULD NOT reply to Router Solicitations on any egress interface 677 when that interface is attached to any other link than the home link. 678 However, the Mobile Router SHOULD reply with Neighbor Advertisements 679 to Neighbor Solicitations received on the egress interface, for 680 topologically correct addresses. 682 A Mobile Router MAY use the received Router Advertisements on the 683 interface connected to the home link, but only for logging and 684 administrative purposes. Only when that interface is connected to 685 a visisted link, the Mobile Router uses information in the received 686 Router Advertisements for purposes other than logging; this includes 687 address configuration, setting up a default route and movement 688 detection. 690 5.7. Multicast Groups for Mobile Router 692 When at home, the Mobile Router joins the multicast group All Routers 693 Address with scopes '1' interface-local (on the home-advertising 694 interface), '2' link-local and '5' site-local on any of its egress 695 interfaces. When in a visited network, the Mobile Router MUST NOT 696 join any of the above groups on the respective interface. 698 6. Home Agent Operation 700 In order for a Mobile Router to operate correctly, the home agent 701 MUST satisfy all the requirements listed in Section 8.4 of [1]. 703 6.1. Prefix Table 705 In some scenarios, the Home Agent might need to maintain a Prefix 706 Table of Mobile Routers and the IPv6 prefixes owned by Mobile 707 Routers. The Home Agent MUST maintain this table if the Mobile 708 Routers operate under the implicit mode where they do not include any 709 prefix information in the Binding Updates. 711 Each entry in the Prefix Table conceptually contains the following 712 fields: 714 - The Home Address of the Mobile Router. This field is used as the 715 key for searching the pre-configured prefix table. 717 - The Mobile Network prefix of the Mobile Router associated with 718 the Home Address. 720 In some deployment scenarios it is important that the Home Agent 721 prevents a misbehaving Mobile Router from claiming Mobile Network 722 Prefixes belonging to another Mobile Router. The Home Agent can 723 prevent such attacks if it maintains the Prefix Table and verifies 724 the Prefix Information provided by the Mobile Router against the 725 entries in the Prefix Table. 727 6.2. Mobile Network Prefix Registration 729 The Home Agent processes the Binding Update as described in Section 730 10.3.1 of the Mobile IPv6 specification. This section describes the 731 processing of the Binding Update if the Mobile Router (R) flag is 732 set. The Home Agent performs the following check in addition. 734 - The Binding Update MUST be authenticated by IPsec according to 735 Section 5.1 of [1]. 737 - The Home Registration (H) bit MUST be set. If not, the 738 Home Agent MUST reject the Binding Update and send a Binding 739 Acknowledgement with status set to 140. Note: The basic support 740 does not allow sending Binding Update for a Mobile Network prefix 741 to correspondent nodes (for route optimization).. 743 - If the Mobile Network Prefix Length option is present in 744 the Binding Update, then there MUST be only one instance of 745 this option in the Binding Update. Also the Mobile Network 746 Prefix Option MUST not be present in the same Binding Update. 747 Otherwise, the Home Agent MUST discard the Binding Update and 748 send an ICMP Parameter Problem, Code 0, message to the Mobile 749 Router 751 If the home agent does not reject the Binding Update as described 752 above, then it retrieves the Mobile Network Prefix information as 753 described below. 755 - If a Mobile Network Prefix Length Option is present in the 756 Binding Update, the Home Address in the Home Address destination 757 option MUST be an extended Home Address. In that case, the 758 Mobile Network Prefix is obtained from that Home Address and the 759 prefix length in the Mobile Network Prefix Length Option. 761 If the Home Agent verfies the prefix information with the Prefix 762 Table and the check fails, the Home Agent MUST discard the 763 Binding Update and send a Binding Acknowldegement with status set 764 to 142 (Not Authorized for Prefix). 766 - If a Mobile Network Prefix Option is present in the Binding 767 Update, the prefix information for the mobile network prefix is 768 retrieved from the Mobile Network Prefix field and the Prefix 769 Length field of the option. If the Binding Update contains more 770 than one option, the Home Agent MUST set up forwarding for all 771 of the Mobile Network Prefixes. Otherwise the Home Agent MUST 772 not forward traffic to any of the prefixes, reject the Binding 773 Update and send a Binding Acknowledgement with status set to 141 774 (Invalid Prefix). 776 If the Home Agent verfies the prefix information with the Prefix 777 Table and the check fails, the Home Agent MUST discard the 778 Binding Update and send a Binding Acknowldegement with status set 779 to 142 (Not Authorized for Prefix). 781 - If there are no options in the Binding Update, the Home Agent 782 MUST figure out which prefixes are assigned to the Mobile Router 783 from the Pre-configured Prefix Table. If the home agent can not 784 find the correspondent Mobile Network prefix, it MUST reject the 785 Binding Update and send a Binding Acknowledgement with the Status 786 field set to 143 (Prefix Information unavailable). 788 If the Lifetime specified in the Binding Update is zero or the 789 specified care-of address matches the home address for the binding, 790 then this is a request to delete the cached binding for the home 791 address and specified mobile network prefixes. The Binding Update is 792 processed according to the procedure described in Section 6.7. 794 If all checks are passed, the home agent creates a binding cache 795 entry for Mobile Router's home address, or updates the binding cache 796 entry if it already exists. Otherwise, the home agent MUST NOT 797 register the binding of the Mobile Router's home address. 799 The home agent also creates a bi-directional tunnel to the mobile 800 router for the requested Mobile Network prefix, or update an existing 801 bi-directional tunnel as described in Section 6.4 803 6.3. Advertising Mobile Network Reachability 805 In order to be able to receive packets meant for the Mobile Network, 806 the Home Agent advertises reachability to the Mobile Network. If the 807 Mobile Network Prefix can be aggregated under the Home Link prefix, 808 then the routing updates advertising reachability to the Mobile 809 Network are sent only on the Home Link. If the Home Agent is the 810 only router on the Home Link, routes to the Mobile Network Prefix 811 gets aggregated naturally under the Home Agent and the Home Agent 812 does not have to do anything special. 814 If the Home Agent receives routing updates through a dynamic routing 815 protocol from the Mobile Router, those routes are propogated by 816 the routing protocol running on the Home Agent on the relevant 817 interfaces. 819 6.4. Establishment of Bi-directional Tunnel 821 The establishment and operation of the bi-directional tunnel is 822 implementation specific. However, all implementations MUST be 823 capable of the following operations. 825 - The Home Agent can tunnel packets meant for the Mobile Network 826 Prefix to the Mobile Router's current location, the Care-of 827 Address of the Mobile Router. 829 - The Home Agent can accept packets tunneled by the Mobile Router 830 with source address of the outer IPv6 header set to the Care-of 831 Address of the Mobile Router. 833 6.5. Forwarding Packets 835 When the Home Agent receives a data packet destined for the mobile 836 network, it fowards the packet to the Mobile Router through the 837 bi-directional tunnel. The Home Agent either uses only the routing 838 table, only the Binding Cache or a combination of routing table 839 and Binding Cache to route packets to the Mobile Network. This is 840 implementation specific. Two examples are shown below. 842 1. The Home Agent maintains a route to the Mobile Network Prefix 843 with the next hop set to the Mobile Router's Home Address. When 844 the Home Agent tries to forward the packet to the next hop, it 845 finds a binding cache entry for the home address. Then the Home 846 Agent extracts the Mobile Router's Care-of address and tunnels 847 the packet to the Care-of address. 849 2. The Home Agent maintains a route to the Mobile Network Prefix 850 with the outgoing interface set to the bi-directional tunnel 851 interface between the Home Agent and the Mobile Router. For 852 this purpose, the Home Agent MUST treat this tunnel as a tunnel 853 interface. When the packets are forwarded through the tunnel 854 interface, they get encapsulated automatically with the source 855 address and destination address in the outer IPv6 header set to 856 the Home Agent's address and the Mobile Router's Care-of address, 857 respectively. 859 6.6. Sending Binding Acknowledgements 861 A Home Agent serving a Mobile Router sends Binding Acknowledgements 862 according to the same rules it uses for sending Binding 863 Acknowledgements to Mobile Hosts, with the following enhancements. 865 The Home Agent sets the status code in the Binding Acknowledgement 866 to '0' (Binding Update accepted) in order to indicate to the Mobile 867 Router that it accepted the Binding Update, set up the tunnel 868 endpoint and the necessary forwarding information. 870 If the Home Agent is configured not to support mobile routers, it 871 sets the status code in the Binding Acknowledgement to '140' (Mobile 872 Router Operation not permitted). 874 If one or more prefixes received in the Binding Update are invalid 875 and the Home Agent cannot setup forwarding for the prefixes, the Home 876 Agent sets the status code in the Binding Acknowledgement to '141' 877 (Invalid Prefix) in order to indicate this to the Mobile Router. 879 If the Mobile Router is not authorized to use this Home Address to 880 forward packets for one or more prefixes that are present in the 881 Binding Update, the Home Agent sets the status code in the Binding 882 Acknowledgement to '142' (Not Authorized for Prefix) in order to 883 indicate this. 885 The Home Agent sets the status code in the Binding Acknowledgement 886 to '143' (Mobile Network Prefix information unavailable) in order 887 to indicate the Mobile Router that the received Home Address in the 888 Binding Update does not match any prefix entry in the pre-configured 889 prefix table. This is used in the Implicit case where the Mobile 890 Router does not include any prefix information in the Binding Update. 892 6.7. Mobile Network Prefix De-Registration 894 The Mobile Router de-registers with the Home Agent by sending 895 a Binding Update with the lifetime set to zero. This Binding 896 Update MUST be secured as described in [3]. When the Home Agent 897 successfully processes the de-registration BU, it deletes the Binding 898 Cache Entry for the Mobile Router's Home Address and stops proxying 899 the Home Address. This is described in detail in the Mobile IPv6 900 specification [1]. 902 In addition, the Home Agent also removes the bi-directional tunnel 903 and stops forwarding packets to the Mobile Network. 905 7. Extended Home Network 907 With MIPv6, the Home Network is generally a physical network 908 interconnecting the Home Agents, and the Mobile Nodes that are at 909 Home. The Network Mobility concept introduces the extended Home 910 Network that aggregates the Home Network(s) and the Mobile Network(s) 911 in a single, shorter prefix. 913 For most practical situations, it is expected that: 915 - There is a single Home Network and multiple Mobile Networks 917 - The Home Network and Mobile Network prefixes are tailored to 918 allow for IPv6 Stateless Address Autoconfiguration with typical 919 interface identifier length for the type of interface. 921 - The prefix length of the extended Home Network is shorter than 922 the Home Network and the Mobile Network prefixes, since it is an 923 aggregation. 925 - The Home Agents collectively advertise the extended Home Network 926 aggregation only. The dichotomy of the extended Home Network is 927 kept within the Home Agents and the Mobile Nodes, as opposed to 928 advertised by means of routing protocols to other parties. 930 The Home Network is configured on a physical interface as defined in 931 MIPv6. A Mobile Router may own a Home Address that is built out of 932 the Home Network prefix and use it for Nemo registration and to come 933 back Home. In that case, the Home Network Prefix and prefix length 934 are used in the Binding Update. 936 A Mobile Router owns one or several Mobile Networks. It may form 937 extended Home Addresses from the prefixes of its Mobile Network(s) 938 and register them to the Home Agent using the extended Home Network 939 prefix and prefix length. An extended Home Address may be used for 940 only one registration that it identifies uniquely, regardless of the 941 Home Agent, as for normal Home Addresses. 943 An extended Home Network may be configured on a virtual or a physical 944 interface of the Home Agent. It is partitioned in Mobile Networks 945 and Home Networks. If the extended Home Network is configured on a 946 physical Network, a Mobile Router that registers using an extended 947 Home Address may come back home by: 949 - Autoconfiguring a Care-of Address from the Home Network and 950 providing Proxy Neighbor Discovery for its Mobile Network 951 Prefixes 953 or 955 - Attaching directly by its Ingress Link if it has only one of 956 them. 958 Multihoming, and in particular the associated coordination of 959 the Home Agents, is out of the scope of this document. Yet, this 960 specification does not prevent that: 962 - More than one Mobile Network may be connected to a Mobile Router 964 - A Mobile Network Prefix may be shared between Mobile Routers and 965 registered by some of them 967 - An Mobile Network Prefix may be registered several times to 968 several Home Agents using different (extended) Home Addresses for 969 each registration. 971 This description is open to a: 973 - Mobile Router autoconfiguring one or several extended Home 974 Address to carry out many registrations in parallel. It owns the 975 full prefix so it may use any address in there for a MNLP based 976 registration, and several of them for multihoming. 978 - Mobile Node autoconfiguring one or several Care-of Addresses from 979 the Mobile Network Prefix 981 - Mobile Host autoconfiguring one or several Home Addresses from 982 the Home Network. 984 Mobile Nodes' Home Addresses may still be configured manually from 985 the Home Network Prefix as described in Mobile IPv6. 987 8. Support for Dynamic Routing Protocols 989 In the solution described so far, forwarding to the Mobile Network 990 at the Home Agent is set up when the Home Agent receives a Binding 991 Update from the Mobile Router. An alternative to this is for the 992 Home Agent and the Mobile Router to run a intra-doamin routing 993 protocol like RIPng [6] and OSPF [7] through the bi-directional 994 tunnel. The Mobile Router can continue running the same routing 995 protocol that it was running when it was attached to the home link. 997 This feature is very useful when the Mobile Network is large with 998 multiple subnets containing different IPv6 prefixes. Routing changes 999 in the Mobile Network are propagated to the Home Agent quickly. 1000 Routing changes in the home link are also propogated to the Mobile 1001 Router very quickly. 1003 When the Mobile Router is attached to the home link, it runs a 1004 routing protocol by sending routing updates through its egress 1005 interface. When the mobile router moves and attaches to a visited 1006 network, it MUST stop sending routing updates on the interface with 1007 which it attaches to the visited link. This is very important so 1008 that IPv6 prefixes specific to the Mobile Network do not leak into 1009 the visited network. The Mobile Router then starts sending routing 1010 protocol messages through the bi-directional tunnel towards the Home 1011 Agent. Most routing protocols use link local addresses as source 1012 addresses for the routing information messages. The Mobile Router is 1013 allowed to use link local addresses for the inner IPv6 header of an 1014 encapsulated packet. But these messages after decapsulation MUST NOT 1015 be forwarded to another link by either the Mobile Router or the Home 1016 Agent. 1018 When the Home Agent receives the encapsulated routing protocol 1019 message, it processes the inner packets and updates its routing table 1020 accordingly. The next hop information in these routing entries is 1021 filled with the Mobile Router's link local address with the outgoing 1022 interface set to the bi-directional tunnel. 1024 Similary, the Home Agent also sends routing updates through the 1025 bi-directional tunnel to the Mobile Router. The Mobile Router 1026 processes these routing protocol messages and updates its routing 1027 table. For all routes advertised by the Home Agent, the Mobile 1028 Router sets the outgoing interface to the bi-directional tunnel to 1029 the Home Agent. 1031 The tunneled routing messages MUST be authenticated and encrypted by 1032 using IPsec ESP [5] in tunnel mode. 1034 9. Use of IPsec to protect the Signaling Messages 1036 The use of IPsec to protect to Mobile IPv6 signaling messages is 1037 described in detail in HA-MN IPsec specification [3]. This document 1038 does not require any changes or anything more that what is described 1039 in the HA-MN IPsec specification. 1041 10. Security Considerations 1043 The Home Agent has to verify that packets received through the 1044 bi-directional tunnel belong to the Mobile Network. This check is 1045 necessary in order to prevent nodes from using the Home Agent to 1046 launch attacks that would have otherwise been prevented by ingress 1047 filtering. The source address of the outer IPv6 header MUST be set 1048 the Mobile Router's current Care-of address. The source address of 1049 the inner IPv6 header MUST belong to the Mobile Network Prefix owned 1050 by the Mobile Router. 1052 When the Mobile Router is running a dynamic routing protocol as 1053 described in Section 8, it injects routing update messages into the 1054 Home Link. The Home Agent MUST verify that the Mobile Router is 1055 allowed to send routing updates before processing the messages and 1056 propagating the routing information. 1058 Please refer to the Mobile IPv6 specification [1] for security 1059 considerations when the Mobile Router operates as a Mobile Host. 1061 11. IANA Considerations 1063 This document defines two new Mobility Header Options. 1065 - Mobile Network Prefix Option 1067 - Mobile Network Prefix Length Option. 1069 These options are described in section 4.3 and section 4.4. The type 1070 values for these options need to assigned from the same space used by 1071 the mobility options defined in [1] 1073 12. Contributors 1075 We would like to acknowledge Thierry Ernst, Miguel Catalina-Gallego, 1076 Christophe Janneteau, T.J. Kniveton, Hong-Yon Lach, Jari T. Malinen, 1077 Koshiro Mitsuya, Charles E. Perkins and Keisuke Uehara, for their 1078 work on earlier proposals for Network Mobility. This document 1079 inherits a lot of ideas from these earlier proposals. 1081 13. Acknowledgements 1083 We also thank all members of the NEMO Working Group, and of the 1084 preceding MONET BoF for fruitful discussions on the mailing list and 1085 at IETF meetings. 1087 Tim Leinumeller for many insightful remarks and implementation 1088 aspects. 1090 References 1092 [1] D. Johnson, C. Perkins and J. Arkko. Mobility Support 1093 in IPv6 (work in progress). Internet Draft, IETF. 1094 draft-ietf-mobileip-ipv6-22.txt. May 2003. 1096 [2] T. Ernst and H.-Y. Lach. Network Mobility Support 1097 Terminology (work in progress). Internet Draft, IETF. 1098 draft-ietf-nemo-terminology-00.txt. May 2003. 1100 [3] J. Arkko, V. Devarapalli and F. Dupont. Using IPsec to 1101 Protect Mobile IPv6 Signaling between Mobile Nodes and 1102 Home Agents (work in progress). Internet Draft, IETF. 1103 draft-ietf-mobileip-mipv6-ha-ipsec-05.txt May 2003. 1105 [4] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 1106 Specification. RFC 2473, IETF. December 1998. 1108 [5] S. Kent and R. Atkinson. IP Encapsulating Security Payload (ESP). 1109 RFC 2402, IETF. November 1998. 1111 [6] G. Malkin and R. Minnear. RIPng for IPv6. RFC 2080, IETF. January 1112 1997. 1114 [7] R. Coltun, D. Ferguson and J. Moy. OSPF for IPv6. RFC 2470, IETF. 1115 December 1999. 1117 [8] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1118 Specification. RFC 2460, IETF. December 1998. 1120 [9] T. Narten, E. Nordmark and W. Simpson. Neighbour Discovery for IP 1121 Version 6 (IPv6). RFC 2461, IETF. December 1998. 1123 [10] C. Perkins, ed. IP Mobility Support for IPv4. RFC 3344, IETF. 1124 August 2002. 1126 A. Examples of Operation 1128 This section tries to illustrate the NEMO protocol using a Mobile 1129 Router and a Mobile Node belonging to different administrative 1130 domains. The Mobile Router's mobile network consists of a Local 1131 Fixed Node (LFN) and a Local Fixed Router (LFR) [2]. The LFR has 1132 an access link to which other Mobile Nodes or Mobile Routers could 1133 attach to. 1135 Figure 1 depicts the scenario where both the Mobile Router and the 1136 Mobile Node are at home. 1138 +----+ +-------+ 1139 | MN | | HA_MN | 1140 +--+-+ 1:: +---+---+ 1141 2+-------------+3 1142 | 1143 | 1144 +-------+2 2:: +-------------------+ 3:: 2+-------+ 1145 | CN_MN |------| Internet |------| CN_MR | 1146 +-------+ +-------------------+ +-------+ 1147 4:: | 1148 | 1149 2+-------------+3 1150 +--+-+ +---+---+ 1151 | MR | | HA_MR | 1152 +--+-+ +-------+ 1153 5:: |1 1154 ---------- 1155 2| |3 1156 +--+-+ +--+-+ 1157 | LFN| | LFR| 1158 +--+-+ +--+-+ 1159 6:: |1 1160 ---------- 1162 Figure 1: Mobile Router and Mobile Node at home. 1164 The Mobile Router then moves away from the home link and attaches to 1165 a visited link. This is shown in Figure 2. The Mobile Router sends 1166 a Binding Update to HA_MR when it attaches to a visited link and 1167 configures a Care-of Addres. HA_MR creates a binding cache entry for 1168 the Mobile Router's Home Address and also sets up forwarding for the 1169 prefixes on the mobile network. 1171 +----+ +-------+ 1172 | MN | | HA_MN | 1173 +--+-+ 1:: +---+---+ 1174 2+-------------+3 1175 | 1176 | 1177 +-------+2 2:: +-------------------+ 3:: 2+-------+ 1178 | CN_MN |------| Internet |------| CN_MR | 1179 +-------+ ++------------------+ +-------+ 1180 | 7:: 4:: | 4::2->7::2 1181 | | 1182 2+ +3 1183 +--+-+ +---+---+ 1184 | MR | | HA_MR | 4::2->7::2 1185 +--+-+ +-------+ 5::/prefixlen -> forward 1186 5:: |1 to MR 1187 ---------- 6::/prefixlen -> forward 1188 2| |3 to MR 1189 +--+-+ +--+-+ 1190 | LFN| | LFR| 1191 +--+-+ +--+-+ 1192 6:: |1 1193 ---------- 1195 Figure 2: Mobile Router on a Visited Link. 1197 Figure 3 shows the Mobile Node moving away from its home link and 1198 attaching to the Mobile Router. The Mobile Node configures a Care-of 1199 Address from the prefix advertised on the mobile network and sends a 1200 Binding Update to its Home Agent (HA_MN) and its Correspondent Node 1201 (CN_MN). Both HA_MN and CN_MN create binding cache entries for the 1202 Mobile Node's Home Address. 1204 +-------+ 1205 | HA_MN | 1::2->6::2 1206 1:: +---+---+ 1207 ---------|3 1208 | 1209 | 1210 +-------+2 2:: +-------------------+ 3:: 2+-------+ 1211 | CN_MN |------| Internet |------| CN_MR | 1212 +-------+ ++------------------+ +-------+ 1213 3::2->6::2 | 7:: 4:: | 4::2->7::2 1214 | | 1215 2+ +3 1216 +--+-+ +---+---+ 1217 | MR | | HA_MR | 4::2->7::2 1218 +--+-+ +-------+ 5::/prefixlen -> forward 1219 5:: |1 to MR 1220 ---------- 6::/prefixlen -> forward 1221 2| |3 to MR 1222 +--+-+ +--+-+ 1223 | LFN| | LFR| 1224 +--+-+ +--+-+ 1225 6:: |1 1226 --------+- 1227 |2 1228 +--+-+ 1229 | MN | 1230 +----+ 1232 Figure 3: Mobile Node attached to Mobile 1233 Router on a Visited Link 1235 Authors Addresses 1237 Vijay Devarapalli 1238 Nokia Research Center 1239 313 Fairchild Drive 1240 Mountain View, CA 94043 1241 USA 1242 Email: vijay.devarapalli@nokia.com 1244 Ryuji Wakikawa 1245 Keio University and WIDE 1246 5322 Endo Fujisawa Kanagawa 1247 252-8520 Japan 1248 Email: ryuji@sfc.wide.ad.jp 1250 Alexandru Petrescu 1251 Motorola Labs 1252 Espace Technologique de St Aubin 1253 Gif-sur-Yvette 91193 1254 France 1255 Email: Alexandru.Petrescu@motorola.com 1257 Pascal Thubert 1258 Cisco Systems Technology Center 1259 Village d'Entreprises Green Side 1260 400, Avenue Roumanille 1261 Biot - Sophia Antipolis 06410 1262 France 1263 Email: pthubert@cisco.com 1265 Full Copyright Statement 1267 Copyright (C) The Internet Society (2003). All Rights Reserved. 1269 This document and translations of it may be copied and furnished to 1270 others, and derivative works that comment on or otherwise explain it 1271 or assist in its implementation may be prepared, copied, published 1272 and distributed, in whole or in part, without restriction of any 1273 kind, provided that the above copyright notice and this paragraph 1274 are included on all such copies and derivative works. However, 1275 this document itself may not be modified in any way, such as by 1276 removing the copyright notice or references to the Internet Society 1277 or other Internet organizations, except as needed for the purpose 1278 of developing Internet standards in which case the procedures 1279 for copyrights defined in the Internet Standards process must be 1280 followed, or as required to translate it into languages other than 1281 English. 1283 The limited permissions granted above are perpetual and will not be 1284 revoked by the Internet Society or its successors or assignees. 1286 This document and the information contained herein is provided on an 1287 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1288 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1289 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1290 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1291 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1293 Acknowledgement 1295 Funding for the RFC Editor function is currently provided by the 1296 Internet Society.