idnits 2.17.1 draft-ietf-nemo-basic-support-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1515. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1521. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 'SHOULD not' in this paragraph: When the Mobile Router sends a de-registration Binding Update in Explicit mode, it SHOULD not include any Mobile Network Prefix options in the Binding Update. When the Home Agent removes a binding cache entry, it deletes all the associated Mobile Network Prefix routes. -- 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 (June 2004) is 7227 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: '4' is defined on line 1199, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1224, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1238, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1241, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2402 (ref. '4') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2460 (ref. '5') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '6') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '8') (Obsoleted by RFC 4301) == Outdated reference: A later version (-06) exists of draft-ietf-seamoby-mobility-terminology-05 == Outdated reference: A later version (-06) exists of draft-ietf-nemo-terminology-00 == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-01 == Outdated reference: A later version (-08) exists of draft-ietf-ospf-ospfv3-auth-04 -- No information found for draft-ietf-home-network-models - is the name correct? Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 9 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 December 2004 Keio University 5 Alexandru Petrescu 6 Motorola 7 Pascal Thubert 8 Cisco Systems 9 June 2004 11 Network Mobility (NEMO) Basic Support Protocol 12 draft-ietf-nemo-basic-support-03.txt 14 Status of This Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3667. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note 23 that other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at 28 any time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at: 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document describes the Network Mobility (NEMO) Basic Support 39 protocol that enables mobile networks to attach to different points 40 in the Internet. The protocol is an extension of Mobile IPv6 and 41 allows for session continuity for every node in the mobile network as 42 the network moves. It also allows every node in the mobile network 43 to be reachable while moving around. The Mobile Router, which 44 connects the network to the Internet, runs the NEMO Basic Support 45 protocol with its Home Agent. The protocol is designed in such a way 46 that network mobility is transparent to the nodes inside the mobile 47 network. 49 Contents 51 Status of This Memo 1 53 Abstract 1 55 1. Introduction 4 57 2. Terminology 5 59 3. Overview of the NEMO Protocol 6 61 4. Message Formats 9 62 4.1. Binding Update . . . . . . . . . . . . . . . . . . . . . 9 63 4.2. Binding Acknowledgement . . . . . . . . . . . . . . . . . 9 64 4.3. Mobile Network Prefix Option . . . . . . . . . . . . . . 10 66 5. Mobile Router Operation 12 67 5.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 12 68 5.2. Sending Binding Updates . . . . . . . . . . . . . . . . . 13 69 5.3. Receiving Binding Acknowledgements . . . . . . . . . . . 13 70 5.4. Error Processing . . . . . . . . . . . . . . . . . . . . 14 71 5.4.1. Implicit Mode . . . . . . . . . . . . . . . . . . 14 72 5.4.2. Explicit Mode . . . . . . . . . . . . . . . . . . 14 73 5.5. Establishment of Bi-directional Tunnel . . . . . . . . . 15 74 5.6. Neighbor Discovery for Mobile Router . . . . . . . . . . 16 75 5.7. Multicast Groups for Mobile Router . . . . . . . . . . . 16 76 5.8. Returning Home . . . . . . . . . . . . . . . . . . . . . 16 78 6. Home Agent Operation 18 79 6.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 18 80 6.1.1. Binding Cache . . . . . . . . . . . . . . . . . . 18 81 6.1.2. Prefix Table . . . . . . . . . . . . . . . . . . 18 82 6.2. Mobile Network Prefix Registration . . . . . . . . . . . 19 83 6.3. Advertising Mobile Network Reachability . . . . . . . . . 20 84 6.4. Establishment of Bi-directional Tunnel . . . . . . . . . 21 85 6.5. Forwarding Packets . . . . . . . . . . . . . . . . . . . 21 86 6.6. Sending Binding Acknowledgements . . . . . . . . . . . . 22 87 6.7. Mobile Network Prefix De-Registration . . . . . . . . . . 22 89 7. Modifications to Dynamic Home Agent Discovery 24 90 7.1. Modified Dynamic Home Agent Discovery Request . . . . . . 24 91 7.2. Modified Dynamic Home Agent Discovery Reply . . . . . . . 24 92 7.3. Modified Home Agent Information Option . . . . . . . . . 25 94 8. Support for Dynamic Routing Protocols 26 95 9. Security Considerations 28 97 10. IANA Considerations 29 99 11. Contributors 29 101 12. Acknowledgements 29 103 A. Examples of NEMO Basic Support Operation 32 105 B. Running Link State Routing Protocol with NEMO Basic Support 35 106 B.1. Tunnel Interface Considerations . . . . . . . . . . . . . 35 107 B.2. OSPF Area Considerations . . . . . . . . . . . . . . . . 35 109 C. Changes from Previous Version 37 111 1. Introduction 113 This document describes protocol extensions to Mobile IPv6 (MIPv6) 114 [1] to enable support for network mobility. The extensions are 115 backward compatible with Mobile IPv6. In particular, a NEMO 116 compliant Home Agent can operate as a Mobile IPv6 Home Agent as well. 118 The NEMO Basic Support works in such a way that session continuity is 119 ensured for all the nodes in the mobile network even as the Mobile 120 Router changes its point of attachment to the Internet. It also 121 provides connectivity and reachability for all nodes in the mobile 122 network as the network moves. The solution supports both mobile 123 nodes and hosts that do not support mobility in the mobile network. 125 Within the context of this document, the definition of a Mobile 126 Router extends that of a Mobile IPv6 [1] Mobile Node, by adding 127 the capability of routing between its point of attachment (Care-of 128 Address) and a subnet which moves with the Mobile Router. 130 The solution described in this document requires setting up a 131 bi-directional tunnel between the Mobile Router and its Home Agent. 132 This tunnel is set up when the Mobile Router sends a successful 133 Binding Update to its Home Agent, informing the Home Agent of its 134 current point of attachment. 136 All traffic between the nodes in the mobile network and Correspondent 137 Nodes passes through the Home Agent. This document does not describe 138 route optimization of this traffic. 140 The terminology document [10] describes Nested Mobility as a scenario 141 where a Mobile Router allows another Mobile Router to attach to its 142 mobile network. There could be arbitrary levels of nested mobility. 143 The operation of each Mobile Router remains the same whether the 144 Mobile Router attaches to another Mobile Router or to a fixed Access 145 Router on the Internet. The solution described here does not place 146 any restriction on the number of levels for nested mobility. But it 147 should be noted that this might introduce significant overhead on the 148 data packets as each level of nesting introduces another IPv6 header 149 encapsulation. 151 This document does not discuss multihoming for Mobile Routers. 153 2. Terminology 155 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [7]. 159 Network Mobility related terminology is defined in [9] and [10]. 160 This document in addition defines the following terms. 162 Mobile Network Prefix 164 An IPv6 prefix that is delegated to a Mobile 165 Router and advertised in the mobile network. There could 166 be more than one Mobile Network Prefix being advertised in 167 a mobile network. 169 Prefix Table 171 It is a list of Mobile Network Prefixes indexed by 172 the Home Address of a Mobile Router. The prefix table is 173 managed by the Home Agent and is used by the Home Agent 174 to determine which Mobile Network Prefixes belong to a 175 particular Mobile Router. 177 3. Overview of the NEMO Protocol 179 A Mobile Network is a network segment or subnet which can move and 180 attach to arbitrary points in the routing infrastructure. A mobile 181 network can only be accessed via specific gateways called Mobile 182 Routers that manage its movement. Mobile networks have at least one 183 Mobile Router serving them. A Mobile Router does not distribute 184 the mobile network routes to the infrastructure at its point of 185 attachment (i.e. in the visited network). Instead, it maintains a 186 bidirectional tunnel to a Home Agent that advertises an aggregation 187 of mobile networks to the infrasructure. The Mobile Router is also 188 the default gateway for the mobile network. 190 A mobile network can also consist of multiple and nested subnets. A 191 router with no support for mobility may be permanently attached to 192 a mobile network for local distribution. Also, Mobile Routers may 193 be attached to mobile networks owned by different Mobile Routers and 194 form a graph. In particular, with Basic NEMO Support, each Mobile 195 Router is attached to another mobile network by a single interface, 196 and if loops are avoided, the graph is a tree. 198 A Mobile Router has an unique Home Address through which it is 199 reachable when it is registered with its Home Agent. The Home 200 Address is configured from a prefix that is aggregated and advertised 201 by its Home Agent. The prefix could either be the prefix advertised 202 on the home link or the prefix delegated to the Mobile Router. 203 The Mobile Router can have more than one Home Address if there 204 are multiple prefixes in the home link. The Mobile Router also 205 advertises one or more prefixes in the mobile network attached to it. 206 The actual mechanism for assigning these prefixes to a given Mobile 207 Router is outside the scope of this specification. 209 When the Mobile Router moves away from the home link and attaches to 210 a new access router, it acquires a Care-of Address from the visited 211 link. The Mobile Router can at any time act either as a Mobile Host 212 or a Mobile Router. It acts as a Mobile Host as defined in [1] for 213 sessions originated by itself, while providing connectivity to the 214 Mobile Network. As soon as the Mobile Router acquires a Care-of 215 Address, it immediately sends a Binding Update to its Home Agent as 216 described in [1]. When the Home Agent receives this Binding Update 217 it creates a binding cache entry binding the Mobile Router's Home 218 Address to its Care-of address at the current point of attachment. 220 If the Mobile Router wishes to act as a Mobile Router and provide 221 connectivity to nodes in the mobile network, it indicates this to the 222 Home Agent by setting a flag (R) in the Binding Update. It MAY also 223 include information about the Mobile Network Prefix in the Binding 224 Update using one of the modes described in Section 5.2, so that the 225 Home Agent can forward packets meant for nodes in the mobile network 226 to the Mobile Router. A new Mobility Header Option is described in 227 this document to carry prefix information. This option is described 228 in Section 4.3. If the mobile network has more than one IPv6 prefix 229 and wants the Home Agent to setup forwarding for all these prefixes, 230 it includes multiple prefix information options in a single Binding 231 Update. The Home Agent sets up forwarding for each of these prefixes 232 to the Mobile Router's Care-of Address. In some scenarios the 233 Home Agent already knows which prefixes belong to a Mobile Router 234 by an alternate mechanism such as static configuration. In these 235 scenarios, the Mobile Router does not include any prefix information 236 in the Binding Update. The Home Agent sets up forwarding for all 237 prefixes owned by the Mobile Router, when it receives a Binding 238 Update from the mobile router with the router flag (R) set. 240 The Home Agent acknowledges the Binding Update by sending a Binding 241 Acknowledgement to the Mobile Router. A positive acknowledgement 242 means that the Home Agent has set up forwarding for the mobile 243 network. Once the binding process completes, a bi-directional tunnel 244 is established between the Home Agent and the Mobile Router. The 245 tunnel end points are Mobile Router's Care-of Address and the Home 246 Agent's address. If a packet with a source address belonging to 247 the Mobile Network Prefix is received from the mobile network, the 248 Mobile Router reverse-tunnels the packet to the Home Agent through 249 this tunnel. This reverse-tunneling is done by using IP-in-IP 250 encapsulation [3]. The Home Agent decapsulates this packet and 251 forwards it to the Correspondent Node. For traffic originated by 252 itself, the Mobile Router can use either reverse tunneling or route 253 optimization as specified in [1]. 255 When a data packet is sent by a Correspondent Node to a node in the 256 mobile network, it gets routed to the Home Agent which currently 257 has the binding for the Mobile Router. It is expected that the 258 Mobile Router's network prefix would be aggregated at the Home Agent, 259 which advertises the resulting aggregation. Alternatively, the Home 260 Agent may receive the data packets destined to the mobile network 261 by advertising routes to the Mobile Network Prefix. The actual 262 mechanism by which these routes are advertised is outside the scope 263 of this document. When the Home Agent receives a data packet meant 264 for a node in the mobile network, it tunnels the packet to Mobile 265 Router's current Care-of address. The Mobile Router decapsulates the 266 packet and forwards it onto the interface where the mobile network 267 is connected. The Mobile Router before decapsulating the tunneled 268 packet, has to check if the Source address on the outer IPv6 header 269 is the Home Agent's address. However, this check is not necessary 270 if the packet is protected by IPsec in tunnel mode. The Mobile 271 Router also has to make sure the destination address on the inner 272 IPv6 header belongs to a prefix used in the Mobile Network before 273 forwarding the packet to the Mobile Network. Otherwise it should 274 drop the packet. 276 The mobile network could consist of nodes that do not support 277 mobility and nodes that support mobility. A node in the mobile 278 network can also be a fixed or a mobile router. The protocol 279 described here ensures complete transparency of network mobility to 280 the nodes in the mobile network. Mobile Nodes that attach to the 281 mobile network treat it as a normal IPv6 access network and run the 282 Mobile IPv6 protocol. 284 It is also possible for the Mobile Router and the Home Agent to run 285 a routing protocol through the bi-directional tunnel. In that case, 286 the Mobile Router need not include prefix information in the Binding 287 Update. Instead the Home Agent uses the routing protocol updates to 288 setup forwarding for the mobile network. When running the routing 289 protocol it is required that the bi-directional tunnel be treated as 290 a tunnel interface. The tunnel interface is included in the list of 291 interfaces on which routing protocol is active. The Mobile Router 292 should be configured not to send any routing protocol messages on its 293 egress interface when it is away from the home link and connected to 294 a visited link. 296 Finally, the Home Agent may be configured with static routes to the 297 Mobile Network Prefix via the Mobile Router's Home Address. In that 298 case, the routes are set independently of the binding flows and 299 the returning Home of a Mobile Router. The benefit is that such 300 movement does not induce any additional signalling in the form of 301 routing updates in the Home Network. The drawback of that model is 302 the routes are present even if the related Mobile Routers are not 303 reachable (at Home or bound) at a given point of time. 305 4. Message Formats 307 4.1. Binding Update 309 A new flag (R) is included in the Binding Update to indicate to the 310 Home Agent if the Binding Update is coming from a Mobile Router 311 and not from a mobile node. The rest of the Binding Update format 312 remains the same as defined in [1]. 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Sequence # | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 |A|H|L|K|M|R| Reserved | Lifetime | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 . . 323 . Mobility options . 324 . . 325 | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Mobile Router Flag (R) 330 The Mobile Router Flag is set to indicate to the Home Agent 331 that the Binding Update is from a Mobile Router. If the flag 332 is set to 0, the Home Agent assumes that the Mobile Router is 333 just behaving as a Mobile Node, and MUST NOT forward packets 334 destined for the mobile network to the Mobile Router. 336 Mobility Options 338 Variable length field which can include zero or more mobility 339 options. This document defines a new mobility option in 340 addition to what is defined in [1]. 342 For descriptions of the other fields in the message, see [1]. 344 4.2. Binding Acknowledgement 346 A new flag (R) is included in the Binding Acknowledgement to indicate 347 that the Home Agent which processed the corresponding Binding Update 348 supports Mobile Routers. The flag is set only if the corresponding 349 Binding Update had the Mobile Router flag (R) set to 1. The rest of 350 the Binding Acknowledgement format remains the same as defined in 351 [1]. 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Status |K|R| Reserved | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Sequence # | Lifetime | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | | 361 . . 362 . Mobility options . 363 . . 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Mobile Router Flag (R) 369 The Mobile Router Flag is set to indicate that the Home Agent 370 which processed the Binding Update supports Mobile Routers. It 371 is set to 1 only if the corresponding Binding Update had the 372 Mobile Router flag set to 1. 374 For descriptions of the other fields in the message, see [1]. 376 This document also introduces the following new Binding 377 Acknowledgement status values. The values shown below are decimal 378 values. 380 140 Mobile Router Operation not permitted 382 141 Invalid Prefix 384 142 Not Authorized for Prefix 386 143 Forwarding Setup failed 388 Status values less than 128 indicate that the Binding Update was 389 processed successfully by the receiving nodes. Values greater than 390 128 indicate that the Binding Update was rejected by the Home Agent. 392 4.3. Mobile Network Prefix Option 394 The Mobile Network Prefix Option is included in the Binding Update 395 to indicate to the Home Agent the prefix information for the mobile 396 network. There could be multiple Mobile Network Prefix Options 397 if the Mobile Router has more than one IPv6 prefix in the mobile 398 network and wants the Home Agent to forward packets for each of these 399 prefixes to the Mobile Router's current location. 401 The Mobile Network Prefix Option has an alignment requirement of 402 8n+4. Its format is as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | 410 + + 411 | | 412 + Mobile Network Prefix + 413 | | 414 + + 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Type 420 TBA 422 Length 424 8 bit unsigned integer indicating the length in octets of the 425 option excluding the type and length fields. Set to 18. 427 Reserved 429 This field is unused for now. The value MUST be initialized to 430 zero by the sender, and MUST be ignored by the receiver. 432 Prefix Length 434 8 bit unsigned integer indicating the prefix length of the IPv6 435 prefix contained in the option. 437 Mobile Network Prefix 439 A 16 byte field contains the Mobile Network Prefix. 441 5. Mobile Router Operation 443 Mobile Router operation is derived largely from the combined 444 behaviors of a Host, of a Router [5], and of a Mobile Node [1]. 446 A Mobile Node can act in two different ways: (1) as a Mobile Host 447 (in which case the Home Agent doesn't maintain any prefix information 448 related to the Mobile Host's Home Address, but does maintain a 449 binding cache entry related to the Mobile Host's Home Address) and 450 (2) as a Mobile Router (in which case, in addition to maintaining the 451 binding cache entry corresponding to the Mobile Router Home Address, 452 the Home Agent also maintains forwarding information related to 453 prefixes assigned to the mobile network). The distinction between 454 the the two modes is represented by the value of the Mobile Router 455 flag (R). 457 A Mobile Router MUST implement all requirements for IPv6 Mobile Nodes 458 as described in Section 8.5 of [1]. 460 5.1. Data Structures 462 Like a Mobile Host, a Mobile Router also maintains a Binding Update 463 List, described in Section 11.1 of Mobile IPv6 specification[1]. The 464 Binding Update list is a conceptual data structure which records 465 information that is sent in the Binding Updates. There is one entry 466 per each destination that the Mobile Router is currently sending 467 Binding Updates to. 469 This document introduces a new Prefix Information field in the 470 Binding Update list structure. This field is used to store any 471 prefix information that the Mobile Router includes in the Binding 472 Update. If the Mobile Router sets the Mobile Router flag (R) in the 473 Binding Update, but does not include any prefix information in it 474 this field is set to null. The Mobile Router does not include prefix 475 information in the Binding Update in the implicit mode or when it 476 runs a dynamic routing protocol with its Home Agent. 478 Similar to a Mobile Host, a Mobile Router stores the information 479 regarding status of flags of the Binding Update, in the corresponding 480 Binding Update List entry. This document introduces a new mobile 481 router flag (R) for this entry. The status of this flag is stored in 482 the Binding Update list whenever a Binding Update is sent. 484 A Mobile Router also maintains a Home Agent list populated according 485 to the same procedure as a Mobile Host. 487 5.2. Sending Binding Updates 489 A Mobile Router sends Binding Updates to its Home Agent as described 490 in [1]. If the Mobile Router is not running a routing protocol 491 as described in Section 8, it uses one of the following modes to 492 instruct the Home Agent to determine the prefixes that belong to the 493 Mobile Router. In all the modes, the Mobile Router sets the Mobile 494 Router flag (R). 496 Implicit: 498 In this mode, the Mobile Router does not include a Mobile 499 Network Prefix Option in the Binding Update. The Home Agent 500 can use any mechanism (not defined in this document) to 501 determine the Mobile Network Prefix(es) owned by the Mobile 502 Router and setup forwarding for the mobile network. One 503 example would be manual configuration at the Home Agent mapping 504 the Mobile Router's Home Address to the information required 505 for setting up forwarding for the mobile network. 507 Explicit: 509 In this mode, the Mobile Router includes one or more Mobile 510 Network Prefix Options in the Binding Update. These options 511 contain information about the Mobile Network Prefix(es) 512 configured on the mobile network. 514 A Mobile Router MUST implement at least one mode and MAY implement 515 both modes. If a Mobile Router implements both modes, local 516 configuration on the Mobile Router decides which mode to use. This 517 is out of scope for this document. 519 If the Mobile Router flag is set, Home Registration flag (H) MUST be 520 set. 522 If the Mobile Router has a valid binding cache entry at the Home 523 Agent, subsequent Binding Updates for the same Home Address should 524 have the same value for the Mobile Router Flag (R) as the value in 525 the binding cache. 527 5.3. Receiving Binding Acknowledgements 529 The Mobile Router receives Binding Acknowledgements from the Home 530 Agent, corresponding to the Binding Updates it sent. If the Binding 531 Acknowledgement status is set to '0' (Binding Update accepted) and 532 the Mobile Router flag (R) is set to 1, the Mobile Router assumes 533 that the Home Agent has successfully processed the Binding Update 534 and has set up forwarding for the mobile network. The Mobile Router 535 can then start using the bi-directional tunnel for reverse tunneling 536 traffic from the mobile network. If the Mobile Router flag (R) is 537 not set, then the Mobile Router concludes that its current Home 538 Agent does not support Mobile Routers and performs Dynamic Home 539 Agent Discovery again to discover Home Agents which support Mobile 540 Routers. Additional the Mobile Router MUST also de-register with the 541 Home Agent which did not support Mobile Routers before attempting 542 registration with another Home Agent. 544 5.4. Error Processing 546 If the Binding Acknowledgement status is set to a value between 128 547 and 139, the Mobile Router takes necessary actions as described in 548 the Mobile IPv6 specification [1]. For the Binding Acknowledgement 549 status values defined in this document, the following sections 550 explain the Mobile Router's behavior. 552 5.4.1. Implicit Mode 554 In Implicit mode, the Mobile Router interprets only error 555 status '140' (Mobile Router Operation not permitted) and '143' 556 (Forwarding Setup failed). The Mobile Router MUST discard Binding 557 Acknowledgements with status '141' and '142'. 559 If the Binding Acknowledgement from the Home Agent has the status 560 '140', the Mobile Router SHOULD send a Binding Update to another Home 561 Agent on the same home link. If no Home Agent replies positively 562 the Mobile Router MUST refrain from sending Binding Updates with the 563 Mobile Router flag set to any Home Agent on the home link, and log 564 the information. 566 If the Binding Acknowledgemnet has the status '143', the Mobile 567 Router SHOULD send a Binding Update to another Home Agent on the same 568 home link. If no Home Agent replies positively the Mobile Router 569 SHOULD refrain from sending this Binding Update to any Home Agent on 570 the home link, and MAY send Binding Updates in Explicit mode to a 571 Home Agent on the same home link. 573 5.4.2. Explicit Mode 575 If the Mobile Router sent a Binding Update to Home Agent in explicit 576 mode then the Mobile Router interprets only error status '140' 577 (Mobile Router Operation not permitted), '141' (Invalid Prefix) and 578 '142' (Not Authorized for Prefix). The Mobile Router MUST discard 579 Binding Acknowledgements with status '143'. 581 If the Binding Acknowledgement from the Home Agent has the status 582 '140', the Mobile Router SHOULD send a Binding Update to another Home 583 Agent on the same home link. If no Home Agent replies positively 584 then the Mobile Router MUST refrain from sending Binding Updates with 585 the Mobile Router flag set to any Home Agent on the home link, and 586 log the information. 588 If the Binding Acknowledgement has the status '141' or '142', the 589 Mobile Router SHOULD send a Binding Update to another Home Agent 590 on the same home link. If no Home Agent replies positively then 591 the Mobile Router SHOULD refrain from sending Binding Updates to 592 any Home Agent on the home link. The Mobile Router MUST also stop 593 advertising the prefix in the Mobile Network and try to obtain new 594 IPv6 prefix information for the Mobile Network by the same means 595 that it initially got assigned the current Mobile Network Prefix. 596 Alternatively, Mobile Router MAY send Binding Updates in Implicit 597 mode to a Home Agent on the same home link. 599 If at the end of this Error Processing procedure, as described in 600 Sections 5.4.1 and 5.4.2, the Mobile Router has tried every available 601 modes of sending Binding Updates and still has not received a 602 positive Binding Acknowledgement, the Mobile Router MUST stop sending 603 Binding Updates with the Mobile Router flag set for this Home Address 604 and log the information. 606 In all the above cases, the Mobile Router MUST conclude that the Home 607 Agent did not create a binding cache entry for the Mobile Router's 608 Home Address. 610 5.5. Establishment of Bi-directional Tunnel 612 When a successful Binding Acknowledgement is received, the Mobile 613 Router sets up its endpoint of the bi-directional tunnel. 615 The bi-directional tunnel between Mobile Router and Home Agent allows 616 packets to flow in both directions between these entities, while the 617 Mobile Router is connected to a visited link. The bi-directional 618 tunnel is created by merging two unidirectional tunnels as described 619 in RFC 2473 [3]. The tunnel from the Mobile Router to the Home Agent 620 has the Care-of address of the Mobile Router as the tunnel entry 621 point and the Home Agent's address as the tunnel exit point. The 622 tunnel from the Home Agent to the Mobile Router has the Home Agent's 623 address and the Mobile Router's Care-of address as the tunnel entry 624 point and exit point respectively. All IPv6 traffic to and from the 625 mobile network is sent through this bi-directional tunnel. 627 A Mobile Router MAY limit the number of mobile routers that attach to 628 its mobile network (the number of levels in the nested aggregation) 629 by means of setting the Tunnel Encapsulation Limit field of the 630 Tunnel Encapsulation option. 632 A Mobile Router uses the Tunnel Hop Limit that is normally assigned 633 to routers (not to hosts). Please refer to [3] for more details. 635 5.6. Neighbor Discovery for Mobile Router 637 When the Mobile Router is at home, it MAY be configured to send 638 Router Advertisements and reply to Router Solicitations on the 639 interface attached to the home link. The value of the Router 640 Lifetime field MUST be set to zero to prevent other nodes from 641 configuring the Mobile Router as the default router. 643 A Mobile Router SHOULD NOT send unsolicited Router Advertisements 644 and SHOULD NOT reply to Router Solicitations on any egress interface 645 when that interface is attached to a visited link. However, the 646 Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor 647 Solicitations received on the egress interface, for topologically 648 correct addresses. 650 A router typically ignores router advertisements sent by other 651 routers on a link. However, a Mobile Router MUST NOT ignore Router 652 Advertisements received on the egress interface. The received Router 653 Advertisements MAY be used for address configuration, default router 654 selection or movement detection. 656 5.7. Multicast Groups for Mobile Router 658 When at home, the Mobile Router joins the multicast group All Routers 659 Address with scopes '1' interface-local (on the home-advertising 660 interface) and '2' link-local on any of its egress interfaces. When 661 in a visited network, the Mobile Router MUST NOT join the above 662 multicast groups on the corresponding interface. 664 5.8. Returning Home 666 When the Mobile Router realizes it has returned to its home link 667 through movement detection mechanisms, it MUST de-register with 668 its Home Agent. The Mobile Router MUST implement and follow the 669 returning home procedures defined for a mobile node in [1]. In 670 addition, the Mobile Router MAY start behaving as a router on its 671 egress interface. In particular, 673 - The Mobile Router MAY send router advertisements on its egress 674 interfaces. But the router lifetime SHOULD be set to 0, so that 675 hosts on the home link do not pick the Mobile Router as the 676 default router. 678 - The Mobile Router MAY join the All Routers multicast group on the 679 home link. 681 - The Mobile Router MAY send routing protocol messages on its 682 egress interface if it is configured to run a dynamic routing 683 protocol. 685 When the Mobile Router sends a de-registration Binding Update in 686 Explicit mode, it SHOULD not include any Mobile Network Prefix 687 options in the Binding Update. When the Home Agent removes a binding 688 cache entry, it deletes all the associated Mobile Network Prefix 689 routes. 691 6. Home Agent Operation 693 In order for a Mobile Router to operate correctly, the Home Agent 694 MUST satisfy all the requirements listed in Section 8.4 of [1]. The 695 Home Agent MUST implement both modes described in Section 5.2 of this 696 document. 698 6.1. Data Structures 700 6.1.1. Binding Cache 702 The Home Agent maintains Binding Cache Entries for each Mobile Router 703 that is currently registered with the Home Agent. The Binding Cache 704 is a conceptual data structure described in detail in [1]. 706 The Home Agent might need to store the Mobile Network Prefixes 707 associated with a Mobile Router in the corresponding Binding Cache 708 Entry. This is required if the Binding Update (that created the 709 Binding Cache Entry) contained explicit prefix information. This 710 information can be used later to cleanup routes installed in explicit 711 mode, when the Binding Cache Entry is removed, and to maintain the 712 routing table, for instance should the routes be manually removed. 714 The Home Agent also stores the status of the Mobile Router Flag (R) 715 in the Binding Cache entry. 717 6.1.2. Prefix Table 719 The Home Agent SHOULD be able to prevent a Mobile Router from 720 claiming Mobile Network Prefixes that belong to another Mobile 721 Router. The Home Agent can prevent such attacks if it maintains a 722 Prefix Table and verifies the Prefix Information provided by the 723 Mobile Router against the entries in the Prefix Table. The Prefix 724 Table SHOULD be used by the Home Agent when it processes a Binding 725 Update in explicit mode. It is not required when a dynamic routing 726 protocol is run between the Mobile Router and the Home Agent. 728 Each entry in the Prefix Table conceptually contains the following 729 fields: 731 - The Home Address of the Mobile Router. This field is used as the 732 key for searching the pre-configured prefix table. 734 - The Mobile Network Prefix of the Mobile Router associated with 735 the Home Address. 737 6.2. Mobile Network Prefix Registration 739 The Home Agent processes the Binding Update as described in Section 740 10.3.1 of the Mobile IPv6 specification [1]. This section describes 741 the processing of the Binding Update if the Mobile Router (R) flag is 742 set. The Home Agent performs the following check in addition. 744 - The Home Registration (H) flag MUST be set. If not, the 745 Home Agent MUST reject the Binding Update and send a Binding 746 Acknowledgement with status set to 140. Note: The basic support 747 does not allow sending Binding Update for a Mobile Network Prefix 748 to correspondent nodes (for route optimization). 750 - Mobile IPv6 specification [1] requires that the Home Address in 751 the Binding Update should be configured from a prefix advertised 752 on the home link. Otherwise the Binding Update is rejected 753 with status value 132 [1]. This specification relaxes this 754 requirement so that the Home Agent rejects the Binding Update 755 only if Home Address does not belong to the prefix that the Home 756 Agent is configured to serve. 758 If the Home Agent has a valid binding cache entry for the Mobile 759 Router and if the Binding Update has the Mobile Router Flag (R) 760 set to a value different from the value in the existing binding 761 cache entry, the Home Agent MUST reject the Binding Update and send 762 a Binding Acknowledgement with status set to 139 (Registration 763 type change disallowed). However, if the Binding Update is a 764 de-registration Binding Update, the Home Agent ignores the value of 765 the Mobile Router Flag (R). 767 If the Home Agent does not reject the Binding Update as described 768 above, and if a dynamic routing protocol is not being run between 769 the Home Agent and the Mobile Router as described in Section 8, then 770 the Home Agent retrieves the Mobile Network Prefix information as 771 described below. 773 - If a Mobile Network Prefix Option is present in the Binding 774 Update, the prefix information for the Mobile Network Prefix is 775 retrieved from the Mobile Network Prefix field and the Prefix 776 Length field of the option. If the Binding Update contains more 777 than one option, the Home Agent MUST set up forwarding for all of 778 the Mobile Network Prefixes. If the Home Agent fails to setup 779 forwarding to all the prefixes listed in the Binding Update, then 780 it MUST NOT forward traffic to any of the prefixes, reject the 781 Binding Update and send a Binding Acknowledgement with status set 782 to 141 (Invalid Prefix). 784 If the Home Agent verifies the prefix information with the Prefix 785 Table and the check fails, the Home Agent MUST discard the 786 Binding Update and send a Binding Acknowldegement with status set 787 to 142 (Not Authorized for Prefix). 789 - If there are is no option in the Binding Update carying 790 prefix information, the Home Agent uses manual pre-configured 791 information to determine the prefixes assigned to the Mobile 792 Router and for setting up forwarding for the mobile network. If 793 there is no information that the Home Agent can use, it MUST 794 reject the Binding Update and send a Binding Acknowledgement with 795 status set to 143 (Forwarding Setup failed). 797 If the Lifetime specified in the Binding Update is zero or the 798 specified Care-of address matches the Home Address in the Binding 799 Update, then this is a request to delete the cached binding for 800 the home address and specified Mobile Network Prefixes. The 801 Binding Update is processed according to the procedure described in 802 Section 6.7. 804 If all checks are passed, the Home Agent creates a binding cache 805 entry for Mobile Router's Home Address, or updates the binding cache 806 entry if it already exists. Otherwise, the Home Agent MUST NOT 807 register the binding of the Mobile Router's Home Address. 809 The Home Agent defends the Mobile Router's Home Address through Proxy 810 Neighbor Discovery by multicasting onto the home link a Neighbor 811 Advertisement message on behalf of the mobile router. All fields in 812 the Proxy Neighbor Advertisement message should be set in the same 813 way they would be set by the Mobile Router itself if sending this 814 Neighbor Advertisement while at home, as described in [6], with the 815 exception that the Router (R) bit in the Advertisement MUST be set if 816 the Mobile Router (R) flag has been set in the Binding Update. 818 The Home Agent also creates a bi-directional tunnel to the mobile 819 router for the requested Mobile Network Prefix, or update an existing 820 bi-directional tunnel as described in Section 6.4. 822 6.3. Advertising Mobile Network Reachability 824 In order to be able to receive packets meant for the mobile network, 825 the Home Agent advertises reachability to the mobile network. If 826 the Home Link is configured with a prefix that is an aggregation and 827 if the Mobile Network Prefix is aggregated under that prefix, then 828 the routing changes related to the Mobile Network may be restricted 829 to the Home Link. If the Home Agent is the only default router on 830 the Home Link, routes to the Mobile Network Prefix get aggregated 831 naturally under the Home Agent and the Home Agent does not have to do 832 anything special. 834 If the Home Agent receives routing updates through a dynamic routing 835 protocol from the Mobile Router, it can be configured to propagate 836 those routes on the relevant interfaces. 838 6.4. Establishment of Bi-directional Tunnel 840 The implementation of the bi-directional tunnels and the mechanism 841 of attaching them to the IP stack are outside the scope of this 842 specification. However, all implementations MUST be capable of the 843 following operations. 845 - The Home Agent can tunnel packets meant for the mobile network 846 prefix to the Mobile Router's current location, the Care-of 847 Address of the Mobile Router. 849 - The Home Agent can accept packets tunneled by the Mobile Router 850 with source address of the outer IPv6 header set to the Care-of 851 Address of the Mobile Router. 853 6.5. Forwarding Packets 855 When the Home Agent receives a data packet destined for the mobile 856 network, it MUST forward the packet to the Mobile Router through the 857 bi-directional tunnel. The Home Agent either uses only the routing 858 table, only the Binding Cache or a combination of routing table 859 and Binding Cache to route packets to the mobile network. This is 860 implementation specific. Two examples are shown below. 862 1. The Home Agent maintains a route to the Mobile Network Prefix 863 with the next hop set to the Mobile Router's Home Address. When 864 the Home Agent tries to forward the packet to the next hop, it 865 finds a binding cache entry for the home address. Then the Home 866 Agent extracts the Mobile Router's Care-of address and tunnels 867 the packet to the Care-of address. 869 2. The Home Agent maintains a route to the Mobile Network Prefix 870 with the outgoing interface set to the bi-directional tunnel 871 interface between the Home Agent and the Mobile Router. For 872 this purpose, the Home Agent MUST treat this tunnel as a tunnel 873 interface. When the packets are forwarded through the tunnel 874 interface, they get encapsulated automatically with the source 875 address and destination address in the outer IPv6 header set to 876 the Home Agent's address and the Mobile Router's Care-of address, 877 respectively. 879 6.6. Sending Binding Acknowledgements 881 A Home Agent serving a Mobile Router sends Binding Acknowledgements 882 according to the same rules it uses for sending Binding 883 Acknowledgements to Mobile Hosts [1], with the following 884 enhancements. 886 The Home Agent sets the status code in the Binding Acknowledgement 887 to '0' (Binding Update accepted) in order to indicate to the Mobile 888 Router that it successfully processed the Binding Update. It also 889 sets the Mobile Router flag (R) to indicate to the Mobile Router that 890 it has setup forwarding for the mobile network. 892 If the Home Agent is configured not to support mobile routers, it 893 sets the status code in the Binding Acknowledgement to '140' (Mobile 894 Router Operation not permitted). 896 If one or more prefixes received in the Binding Update are invalid 897 and the Home Agent cannot setup forwarding for the prefixes, the Home 898 Agent sets the status code in the Binding Acknowledgement to '141' 899 (Invalid Prefix) in order to indicate this to the Mobile Router. 901 If the Mobile Router is not authorized to use this Home Address to 902 forward packets for one or more prefixes that are present in the 903 Binding Update, the Home Agent sets the status code in the Binding 904 Acknowledgement to '142' (Not Authorized for Prefix) in order to 905 indicate this. 907 The Home Agent sets the status code to 143 (Forwarding Setup 908 failed) if it is unable to determine the information needed to setup 909 forwarding for the mobile network. This is used in the Implicit mode 910 where the Mobile Router does not include any prefix information in 911 the Binding Update. 913 6.7. Mobile Network Prefix De-Registration 915 The Mobile Router de-registers with the Home Agent by sending a 916 Binding Update with the lifetime set to zero. When the Home Agent 917 successfully processes the de-registration BU, it deletes the Binding 918 Cache Entry for the Mobile Router's Home Address and stops proxying 919 the Home Address. This is described in detail in the Mobile IPv6 920 specification [1]. 922 In addition, the Home Agent also removes the bi-directional tunnel 923 and stops forwarding packets to the mobile network. The Home Agent 924 should keep all necessary information to clean up whichever routes it 925 installed, whether they come from implicit or explicit source. 927 In Explicit mode, the Home Agent MUST ignore any Mobile Network 928 Prefix Options present in the de-registration Binding Update. 930 7. Modifications to Dynamic Home Agent Discovery 932 This document extends the Dynamic Home Agent Discovery mechanism 933 defined in [1], so that Mobile Routers attempt registration only with 934 Home Agents that support Mobile Routers. 936 7.1. Modified Dynamic Home Agent Discovery Request 938 A new flag (R) (Support for Mobile Routers) is introduced in the 939 Dynamic Home Agent Discovery Reguest message defined in [1]. The 940 Mobile Router sets this flag to indicate that it wants to discover 941 Home Agents that support Mobile Routers. 943 0 1 2 3 944 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 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Type | Code | Checksum | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Identifier |R| Reserved | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 Mobile Router Support Flag (R) 953 A 1 bit flag which when set indicates that the Mobile Router 954 wants to discover Home Agents that support Mobile Routers. 956 For a description of the other fields in the message, see [1]. 958 7.2. Modified Dynamic Home Agent Discovery Reply 960 A new flag (R) (Support for Mobile Routers) is introduced in the 961 Dynamic Home Agent Discovery Reply message defined in [1]. If a Home 962 Agent receives a Dynamic Home Agent Discovery request message with 963 the Mobile Router Support flag set, it MUST reply with a list of Home 964 Agents that support Mobile Routers. The Mobile Router Support flag 965 MUST be set if there is at least one Home Agent that supports Mobile 966 Routers. If none of the Home Agents support Mobile Routers, the Home 967 Agent MAY reply with a list of Home Agents that support just Mobile 968 IPv6 Mobile Nodes. In this case, the Mobile Router Support flag MUST 969 be set to 0. 971 The modified message format is as follows. 973 0 1 2 3 974 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 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Type | Code | Checksum | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Identifier |R| Reserved | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | | 981 + + 982 . . 983 . Home Agent Addresses . 984 . . 985 + + 986 | | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 Mobile Router Support Flag (R) 991 A 1 bit flag which when set indicates that the Home Agents 992 listed in this message support Mobile Routers. 994 For a description of the other fields in the message, see [1]. 996 7.3. Modified Home Agent Information Option 998 A new flag (R) (Support for Mobile Routers) is introduced in the Home 999 Agent Information Option defined in [1]. If a Home Agent supports 1000 Mobile Routers, it SHOULD set the flag. 1002 0 1 2 3 1003 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 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | Type | Length |R| Reserved | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Home Agent Preference | Home Agent Lifetime | 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 Mobile Router Support Flag (R) 1012 A 1-bit flag which when set indicates that the Home Agent 1013 supports Mobile Routers. 1015 For a description of the other fields in the message, see [1]. 1017 8. Support for Dynamic Routing Protocols 1019 In the solution described so far, forwarding to the mobile network 1020 at the Home Agent is set up when the Home Agent receives a Binding 1021 Update from the Mobile Router. An alternative to this is for the 1022 Home Agent and the Mobile Router to run an intra-domain routing 1023 protocol like RIPng [12] and OSPF [13] through the bi-directional 1024 tunnel. The Mobile Router can continue running the same routing 1025 protocol that it was running when it was attached to the home link. 1027 Support for running a intra-domain routing protocol is optional and 1028 is governed by the configuration on the Mobile Router and the Home 1029 Agent. 1031 This feature is very useful when the mobile network is large with 1032 multiple subnets containing different IPv6 prefixes. Routing changes 1033 in the mobile network are propagated to the Home Agent quickly. 1034 Routing changes in the home link are also propagated to the Mobile 1035 Router very quickly. 1037 When the Mobile Router is attached to the home link, it runs a 1038 routing protocol by sending routing updates through its egress 1039 interface. When the mobile router moves and attaches to a visited 1040 network, it MUST stop sending routing updates on the interface 1041 with which it attaches to the visited link. This is to reduce the 1042 chances that prefixes specific to the Mobile Network are leaked to 1043 the visited network in the case where routing protocol authentication 1044 is not enabled in the visited network and in the Mobile Network. It 1045 is expected that normal deployment practices will include proper 1046 authentication mechanisms to prevent unauthorized route announcements 1047 on both home and visited networks. The Mobile Router then starts 1048 sending routing protocol messages through the bi-directional tunnel 1049 towards the Home Agent. Most routing protocols use link local 1050 addresses as source addresses for the routing information messages. 1051 The Mobile Router is allowed to use link local addresses for the 1052 inner IPv6 header of an encapsulated packet. But these routing 1053 protocol messages with link local address MUST NOT be forwarded to 1054 another link by either the Mobile Router or the Home Agent. 1056 When the Home Agent receives the inner packet, it processes the 1057 encapsulated routing protocol messages and updates its routing table 1058 accordingly. As part of normal routing protocol operation, the next 1059 hop information in these routing entries is filled with the Mobile 1060 Router's link local address with the outgoing interface set to the 1061 bi-directional tunnel. 1063 Similary, the Home Agent also sends routing updates through the 1064 bi-directional tunnel to the Mobile Router. The Mobile Router 1065 processes these routing protocol messages and updates its routing 1066 table. For all routes advertised by the Home Agent, the Mobile 1067 Router sets the outgoing interface to the bi-directional tunnel to 1068 the Home Agent. 1070 When the Mobile Router and the Home Agent exchange routes through 1071 a dynamic routing protocol, the Mobile Router SHOULD NOT include 1072 Mobile Network Prefixes in the Binding Update to the Home Agent. The 1073 Home Agent depending on its configuration might not add routes based 1074 on the prefix information in the Binding Updates at all, and might 1075 use only the routing protocol updates. Moreover, including prefix 1076 information in both the Binding Updates and the routing protocol 1077 updates is redundant. 1079 Since the routing protocol messages from the Home Agent to the 1080 Mobile Router could potentially contain information about the 1081 internal routing structure of the home network, these messages 1082 require authentication and confidentiality protection. Appropriate 1083 authentication and confidentiality protection mechanisms defined in 1084 [14] MUST be used. For protecting routing protocol messages using 1085 ESP, the bi-directional tunnel between the Mobile Router and the 1086 Home Agent should be treated as the outgoing interface, with the 1087 Home Agent's and Mobile Router's addresses as source and destination 1088 addresses for the inner encapsulated messages. 1090 If a link state routing protocol like OSPFv3 is run by the Mobile 1091 Router and the Home Agent, the recommendations in Appendix B should 1092 be followed. 1094 9. Security Considerations 1096 All signaling messages between the Mobile Router and the Home Agent 1097 MUST be authenticated by IPsec [8]. The use of IPsec to protect 1098 Mobile IPv6 signaling messages is described in detail in the HA-MN 1099 IPsec specification [2]. The signaling messages described in this 1100 document just extend Mobile IPv6 messages and do not require any 1101 changes to what is described in the HA-MN IPsec specification. 1103 The Mobile Router has to perform ingress filtering on packets 1104 received from the mobile network to ensure that nodes in the Mobile 1105 Network do not use the bi-directional tunnel to launch IP spoofing 1106 attacks. In particular the Mobile Router SHOULD check that the IP 1107 source address in the packets received from the nodes in the Mobile 1108 Network belongs to the Mobile Network Prefix and is not the same as 1109 one of the addresses used by the Mobile Router. In case the Mobile 1110 Router receives a IP-in-IP tunneled packet from a node in the Mobile 1111 Network and the Mobile Router has to forward the decapsulated packet, 1112 it SHOULD perform the above mentioned checks on the source address of 1113 the inner packet. 1115 The Home Agent has to verify that packets received through the 1116 bi-directional tunnel belong to the mobile network. This check is 1117 necessary in order to prevent nodes from using the Home Agent to 1118 launch attacks that would have otherwise been prevented by ingress 1119 filtering. The source address of the outer IPv6 header MUST be set 1120 to the Mobile Router's current Care-of address. The source address 1121 of the inner IPv6 header MUST be a topologically correct address with 1122 respect to the IPv6 prefixes used in the mobile network. 1124 When the Mobile Router is running a dynamic routing protocol as 1125 described in Section 8, it injects routing update messages into 1126 the Home Link. Since the routing protocol message could contain 1127 information about the internal routing structure of the home network, 1128 these messages require confidentiality protection. Confidentiality 1129 protection through IPsec ESP as described in [14] SHOULD be used. 1130 If the bi-directional tunnel between the Mobile Router and the Home 1131 Agent is protected by ESP in tunnel mode for all IP traffic, then 1132 no additional confidentiality protection specific to the routing 1133 protocol is required. 1135 Home agents and mobile routers may use IPsec ESP to protect payload 1136 packets tunneled between themselves. This is useful to protect 1137 communications against attackers on the path of the tunnel. 1139 Please refer to the Mobile IPv6 specification [1] for security 1140 considerations when the Mobile Router operates as a Mobile Host. 1142 10. IANA Considerations 1144 This document defines a new Mobility Header Option, the Mobile 1145 Network Prefix Option. This option is described in Section 4.3. The 1146 type value for this option needs to be assigned from the same space 1147 used by the mobility options defined in [1]. 1149 This document also defines the following new Binding Acknowledgement 1150 status values. These status values are defined in Section 4.2 1151 and need to be assigned from the same space used for Binding 1152 Acknowledgement status values in [1]. 1154 - Mobile Router Operation not permitted 1156 - Invalid Prefix 1158 - Not Authorized for Prefix 1160 - Forwarding Setup failed 1162 11. Contributors 1164 We would like to acknowledge Ludovic Bellier, Claude Castelluccia, 1165 Thierry Ernst, Miguel Catalina-Gallego, Christophe Janneteau, T.J. 1166 Kniveton, Hong-Yon Lach, Jari T. Malinen, Koshiro Mitsuya, Alexis 1167 Olivereau, Charles E. Perkins and Keisuke Uehara, for their work on 1168 earlier proposals for Network Mobility. This document inherits a lot 1169 of ideas from these proposals. 1171 12. Acknowledgements 1173 We thank all members of the NEMO Working Group, and of the preceding 1174 MONET BoF for fruitful discussions on the mailing list and at IETF 1175 meetings. 1177 Kent Leung, Marco Molteni and Patrick Wetterwald for their work on 1178 Network Mobility for IPv4 and IPv6. 1180 Tim Leinmueller for many insightful remarks and for Section 7. 1182 Jari Arkko, James Kempf and Chan-Wah Ng for their thorough review and 1183 comments. 1185 Normative References 1187 [1] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6. 1188 Internet Draft, IETF. draft-ietf-mobileip-ipv6-24.txt (work in 1189 progress). June 2003. 1191 [2] J. Arkko, V. Devarapalli and F. Dupont. Using IPsec to Protect 1192 Mobile IPv6 Signaling between Mobile Nodes and Home Agents. 1193 Internet Draft, IETF. draft-ietf-mobileip-mipv6-ha-ipsec-06.txt 1194 (work in progress). June 2003. 1196 [3] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 1197 Specification. RFC 2473, IETF. December 1998. 1199 [4] S. Kent and R. Atkinson. IP Encapsulating Security Payload 1200 (ESP). RFC 2402, IETF. November 1998. 1202 [5] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1203 Specification. RFC 2460, IETF. December 1998. 1205 [6] T. Narten, E. Nordmark and W. Simpson. Neighbour Discovery for 1206 IP Version 6 (IPv6). RFC 2461, IETF. December 1998. 1208 [7] S. Bradner. Key words for use in RFCs to Indicate Requirement 1209 Levels. RFC 2119, IETF. March 1997. 1211 Informative References 1213 [8] S. Kent and R. Atkinson. Security Architecture for the Internet 1214 Protocol. RFC 2401, IETF. November 1998. 1216 [9] J. Manner and M. Kojo. Mobility Related Terminology. Internet 1217 Draft, IETF. draft-ietf-seamoby-mobility-terminology-05.txt 1218 (work in progress). November 2003. 1220 [10] T. Ernst and H.-Y. Lach. Network Mobility Support Terminology. 1221 Internet Draft, IETF. draft-ietf-nemo-terminology-00.txt (work 1222 in progress). May 2003. 1224 [11] T. Ernst. Network Mobility Support Goals and Requirements. 1225 Internet Draft, IETF. draft-ietf-nemo-requirements-01.txt (work 1226 in progress). May 2003. 1228 [12] G. Malkin and R. Minnear. RIPng for IPv6. RFC 2080, IETF. 1229 January 1997. 1231 [13] R. Coltun, D. Ferguson and J. Moy. OSPF for IPv6. RFC 2470, 1232 IETF. December 1999. 1234 [14] M. Gupta and N. Melam. Authentication/Confidentiality for 1235 OSPFv3. Internet Draft, IETF. draft-ietf-ospf-ospfv3-auth-04.txt 1236 (work in progress). December 2003. 1238 [15] T. Ernst. Network Mobility Support in IPv6. PhD Thesis, 1239 University Joseph Fourier, Grenoble, France. October 2001. 1241 [16] T. Ernst, K, Mitsuya and K. Uehara. Network Mobility from the 1242 InternetCAR perspective. Journal of Interconnection Networks 1243 (JOIN), Vol. 4, No. 3. September 2003. 1245 [17] J. Moy. Extending OSPF to Support Demand Circuits. RFC 1793, 1246 IETF. April 1995. 1248 [18] P. Thubert, et. al. NEMO Home Network models. Internet Draft, 1249 IETF. draft-ietf-home-network-models-00.txt (work in progress). 1250 April 2004. 1252 A. Examples of NEMO Basic Support Operation 1254 This section tries to illustrate the NEMO protocol using a Mobile 1255 Router and a Mobile Node belonging to different administrative 1256 domains. The Mobile Router's mobile network consists of a Local 1257 Fixed Node (LFN) and a Local Fixed Router (LFR) [10]. The LFR has 1258 an access link to which other Mobile Nodes or Mobile Routers could 1259 attach to. 1261 Figure 1 depicts the scenario where both the Mobile Router and the 1262 Mobile Node are at home. 1264 +----+ +-------+ 1265 | MN | | HA_MN | 1266 +--+-+ 1:: +---+---+ 1267 2+-------------+3 1268 | 1269 | 1270 +-------+2 2:: +-------------------+ 3:: 2+-------+ 1271 | CN_MN |------| Internet |------| CN_MR | 1272 +-------+ +-------------------+ +-------+ 1273 4:: | 1274 | 1275 2+-------------+3 1276 +--+-+ +---+---+ 1277 | MR | | HA_MR | 1278 +--+-+ +-------+ 1279 5:: |1 1280 ---------- 1281 2| |3 1282 +--+-+ +--+-+ 1283 | LFN| | LFR| 1284 +--+-+ +--+-+ 1285 6:: |1 1286 ---------- 1288 Figure 1: Mobile Router and Mobile Node at home. 1290 The Mobile Router then moves away from the home link and attaches to 1291 a visited link. This is shown in Figure 2. The Mobile Router sends 1292 a Binding Update to HA_MR when it attaches to a visited link and 1293 configures a Care-of Addres. HA_MR creates a binding cache entry for 1294 the Mobile Router's Home Address and also sets up forwarding for the 1295 prefixes on the mobile network. 1297 +----+ +-------+ 1298 | MN | | HA_MN | 1299 +--+-+ 1:: +---+---+ 1300 2+-------------+3 1301 | 1302 | 1303 +-------+2 2:: +-------------------+ 3:: 2+-------+ 1304 | CN_MN |------| Internet |------| CN_MR | 1305 +-------+ ++------------------+ +-------+ 1306 | 7:: 4:: | 4::2->7::2 1307 | | 1308 2+ +3 1309 +--+-+ +---+---+ 1310 | MR | | HA_MR | 4::2->7::2 1311 +--+-+ +-------+ 5::/prefixlen -> forward 1312 5:: |1 to MR 1313 ---------- 6::/prefixlen -> forward 1314 2| |3 to MR 1315 +--+-+ +--+-+ 1316 | LFN| | LFR| 1317 +--+-+ +--+-+ 1318 6:: |1 1319 ---------- 1321 Figure 2: Mobile Router on a Visited Link. 1323 Figure 3 shows the Mobile Node moving away from its home link and 1324 attaching to the Mobile Router. The Mobile Node configures a Care-of 1325 Address from the prefix advertised on the mobile network and sends a 1326 Binding Update to its Home Agent (HA_MN) and its Correspondent Node 1327 (CN_MN). Both HA_MN and CN_MN create binding cache entries for the 1328 Mobile Node's Home Address. 1330 +-------+ 1331 | HA_MN | 1::2->6::2 1332 1:: +---+---+ 1333 ---------|3 1334 | 1335 | 1336 +-------+2 2:: +-------------------+ 3:: 2+-------+ 1337 | CN_MN |------| Internet |------| CN_MR | 1338 +-------+ ++------------------+ +-------+ 1339 1::2->6::2 | 7:: 4:: | 4::2->7::2 1340 | | 1341 2+ +3 1342 +--+-+ +---+---+ 1343 | MR | | HA_MR | 4::2->7::2 1344 +--+-+ +-------+ 5::/prefixlen -> forward 1345 5:: |1 to MR 1346 ---------- 6::/prefixlen -> forward 1347 2| |3 to MR 1348 +--+-+ +--+-+ 1349 | LFN| | LFR| 1350 +--+-+ +--+-+ 1351 6:: |1 1352 --------+- 1353 |2 1354 +--+-+ 1355 | MN | 1356 +----+ 1358 Figure 3: Mobile Node attached to Mobile 1359 Router on a Visited Link 1361 B. Running Link State Routing Protocol with NEMO Basic Support 1363 The bi-directional tunnel between the Mobile Router and the Home 1364 Agent is used a virtual interface over which routing protocol 1365 messages are exchanged. When a link state routing protocol is run 1366 the following recommendations should be followed. 1368 B.1. Tunnel Interface Considerations 1370 If the tunnel interface goes up and down every time the Mobile Router 1371 moves to a new visited network, with high level of mobility and 1372 sufficient number of mobile routers, the amount of interface state 1373 changes will adversely affect the Home Agent performance. This also 1374 introduces a high level of instability in the home network. To 1375 avoid this, the following should be considered when implementing the 1376 bi-directional tunnel. 1378 - A tunnel inteface is consistently assigned to each Mobile Router 1379 as long as it has a valid binding cache at the Home Agent 1381 - Everytime the Mobile Router moves and updates the binding cache 1382 entry, the bi-directional tunnel should not be torn down and 1383 setup again. The tunnel end points should be updated dynamically 1384 with the Mobile Router's current care-of address. 1386 - With a large number of interfaces, Hello packet processing may 1387 become a burden. Therefore the tunnel interface should be 1388 treated as On-Demand circuits for OSPF [17]. 1390 B.2. OSPF Area Considerations 1392 The following should be considered when the Home Network is 1393 configured for running OSPF. 1395 - The entire Home domain SHOULD NOT be configured as a single area 1396 if a Home Agent supports Mobile Routers. At least the Home 1397 Network should be configured as a separate area. 1399 - The bi-directional tunnel interfaces to the Mobile Routers should 1400 never be included in the same area as the backbone links. 1402 For a more detailed discussion on configuring a Home Network for NEMO 1403 Basic Support, please see [18]. 1405 One disadvantage of running OSPFv3 with NEMO Basic Support is that 1406 there is a possibility that the Mobile Networks will be told of the 1407 topology of the entire Home Network, including all the fixed and 1408 mobile routers, while the only thing the Mobile Routers might really 1409 need is a default route through the Home Agent. 1411 To reduce the amount of routing protocol messages received by a 1412 Mobile Router, one can configure each bi-directional tunnel to a 1413 Mobile Router as a separate area. But this requires that the Home 1414 Agent support a large number of OSPF areas if it supports a large 1415 number of Mobile Routers and might not be possible with most router 1416 implementations. 1418 Another option is to configure multiple areas on the Home Link and 1419 group a number of Mobile Routers into each area. This reduces the 1420 number of areas that a Home Agent needs to support, but at the same 1421 time reduces the amount of routing protocol traffic that a Mobile 1422 Router receives. 1424 C. Changes from Previous Version 1426 The following changes have been made to this document from version 02 1428 - Clarified that Mobile Network Prefix Options should be ignored in 1429 de-registration binding updates. (Issue #30) 1431 - Addressed tunnel interface concerns when dynamic routing 1432 protocols are used. Added section B.1. (Issue #31) 1434 - Addressed OSPF Area configuration considerations. Added section 1435 B.2. (Issue #31) 1437 - Clarified the use of link local addresses on the inner 1438 encapsulated packets when routing protocol messages are exchanged 1439 between the Mobile Router and the Home Agent. (Issue #31) 1441 - Clarified that binding acknowledgement status values are in 1442 decimal. (Issue #32) 1444 - Clarifed that the Home Agent does not have to check the source 1445 address of the outer IPv6 header against the binding cache if the 1446 tunneled packet is protected by ESP in tunneled mode. (Issue 1447 #33) 1449 - Fixed the text which says Mobile Router does not process binding 1450 acknowledgement with status value 140. (Issue #33) 1452 - Added text to clarify the relationship between the use of a 1453 Prefix Table and running a dynamic routing protocol. (Issue #33) 1455 - Clarified the terminology used in describing bi-directional 1456 tunnel setup. (Issue #34) 1458 - Added text to specify that the Mobile Router has to implement 1459 atleast one mode and may implement both. (Issue #34) 1461 - Re-wrote section 5.4 for better clarity. (Issue #34) 1463 - Mobile Router Flag in Binding Update conflicts with HMIPv6's M 1464 flag. Moved the flag to a new position. (Issue #35) 1466 - Clarified Binding Acknowledgement status value 139 and the Mobile 1467 Router Flag. (Issue #38) 1469 Authors' Address 1471 Vijay Devarapalli 1472 Nokia Research Center 1473 313 Fairchild Drive 1474 Mountain View, CA 94043 1475 USA 1476 Email: vijay.devarapalli@nokia.com 1478 Ryuji Wakikawa 1479 Keio University and WIDE 1480 5322 Endo Fujisawa Kanagawa 1481 252-8520 Japan 1482 Email: ryuji@sfc.wide.ad.jp 1484 Alexandru Petrescu 1485 Motorola Labs 1486 Parc les Algorithmes Saint Aubin 1487 Gif-sur-Yvette 91193 1488 France 1489 Email: Alexandru.Petrescu@motorola.com 1491 Pascal Thubert 1492 Cisco Systems Technology Center 1493 Village d'Entreprises Green Side 1494 400, Avenue Roumanille 1495 Biot - Sophia Antipolis 06410 1496 France 1497 Email: pthubert@cisco.com 1499 Intellectual Property Statement 1501 The IETF takes no position regarding the validity or scope of any 1502 Intellectual Property Rights or other rights that might be claimed to 1503 pertain to the implementation or use of the technology described in 1504 this document or the extent to which any license under such rights 1505 might or might not be available; nor does it represent that it has 1506 made any independent effort to identify any such rights. Information 1507 on the procedures with respect to rights in RFC documents can be 1508 found in BCP 78 and BCP 79. 1510 Copies of IPR disclosures made to the IETF Secretariat and any 1511 assurances of licenses to be made available, or the result of an 1512 attempt made to obtain a general license or permission for the 1513 use of such proprietary rights by implementers or users of this 1514 specification can be obtained from the IETF on-line IPR repository at 1515 http://www.ietf.org/ipr. 1517 The IETF invites any interested party to bring to its attention any 1518 copyrights, patents or patent applications, or other proprietary 1519 rights that may cover technology that may be required to implement 1520 this standard. Please address the information to the IETF at 1521 ietf-ipr@ietf.org. 1523 Disclaimer of Validity 1525 This document and the information contained herein are provided 1526 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1527 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1528 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1529 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1530 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1531 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1533 Copyright Statement 1535 Copyright (C) The Internet Society (2004). This document is subject 1536 to the rights, licenses and restrictions contained in BCP 78, and 1537 except as set forth therein, the authors retain all their rights. 1539 Acknowledgement 1541 Funding for the RFC Editor function is currently provided by the 1542 Internet Society.