idnits 2.17.1 draft-ietf-nemo-basic-support-02.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 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 211: '...R) in the Binding Update. It MAY also...' RFC 2119 keyword, line 318: '...Mobile Node, and MUST NOT forward pack...' RFC 2119 keyword, line 413: '... now. The value MUST be initialized t...' RFC 2119 keyword, line 414: '... the sender, and MUST be ignored by th...' RFC 2119 keyword, line 441: '... A Mobile Router MUST implement all re...' (63 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2003) is 7438 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '10' is defined on line 1165, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1179, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1182, 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 2401 (ref. '5') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2460 (ref. '6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '7') (Obsoleted by RFC 4861) == Outdated reference: A later version (-06) exists of draft-ietf-seamoby-mobility-terminology-05 ** Downref: Normative reference to an Informational draft: draft-ietf-seamoby-mobility-terminology (ref. '8') == 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. '9') == Outdated reference: A later version (-06) exists of draft-ietf-nemo-requirements-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '10') == Outdated reference: A later version (-08) exists of draft-ietf-ospf-ospfv3-auth-04 -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 4 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 June 2004 Keio University 5 Alexandru Petrescu 6 Motorola 7 Pascal Thubert 8 Cisco Systems 9 December 2003 11 Network Mobility (NEMO) Basic Support Protocol 12 draft-ietf-nemo-basic-support-02.txt 14 Status of This Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document describes the NEMO Basic Support protocol that enables 37 mobile networks to attach to different points in the Internet. The 38 protocol is an extension of Mobile IPv6 and allows for session 39 continuity for every node in the mobile network as the network moves. 40 It also allows every node in the mobile network to be reachable while 41 moving around. The Mobile Router, which connects the network to the 42 Internet, runs the NEMO Basic Support protocol with its Home Agent. 43 The protocol is designed in such a way that network mobility is 44 transparent to the nodes inside the mobile network. 46 Contents 48 Status of This Memo 1 50 Abstract 1 52 1. Introduction 4 54 2. Terminology 5 56 3. Overview of the NEMO Protocol 6 58 4. Message Formats 9 59 4.1. Binding Update . . . . . . . . . . . . . . . . . . . . . 9 60 4.2. Binding Acknowledgement . . . . . . . . . . . . . . . . . 9 61 4.3. Mobile Network Prefix Option . . . . . . . . . . . . . . 10 63 5. Mobile Router Operation 12 64 5.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 12 65 5.2. Sending Binding Updates . . . . . . . . . . . . . . . . . 13 66 5.3. Receiving Binding Acknowledgements . . . . . . . . . . . 13 67 5.4. Error Processing . . . . . . . . . . . . . . . . . . . . 14 68 5.5. Establishment of Bi-directional Tunnel . . . . . . . . . 15 69 5.6. Neighbor Discovery for Mobile Router . . . . . . . . . . 16 70 5.7. Multicast Groups for Mobile Router . . . . . . . . . . . 16 71 5.8. Returning Home . . . . . . . . . . . . . . . . . . . . . 16 73 6. Home Agent Operation 18 74 6.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 18 75 6.1.1. Binding Cache . . . . . . . . . . . . . . . . . . 18 76 6.1.2. Prefix Table . . . . . . . . . . . . . . . . . . 18 77 6.2. Mobile Network Prefix Registration . . . . . . . . . . . 19 78 6.3. Advertising Mobile Network Reachability . . . . . . . . . 20 79 6.4. Establishment of Bi-directional Tunnel . . . . . . . . . 20 80 6.5. Forwarding Packets . . . . . . . . . . . . . . . . . . . 21 81 6.6. Sending Binding Acknowledgements . . . . . . . . . . . . 21 82 6.7. Mobile Network Prefix De-Registration . . . . . . . . . . 22 84 7. Modifications to Dynamic Home Agent Discovery 23 85 7.1. Modified Dynamic Home Agent Discovery Request . . . . . . 23 86 7.2. Modified Dynamic Home Agent Discovery Reply . . . . . . . 23 87 7.3. Modified Home Agent Information Option . . . . . . . . . 24 89 8. Support for Dynamic Routing Protocols 25 91 9. Security Considerations 27 93 10. IANA Considerations 28 95 11. Contributors 28 97 12. Acknowledgements 28 99 A. Examples of NEMO Basic Support Operation 31 101 B. Changes from Previous Version 34 103 1. Introduction 105 This document describes protocol extensions to Mobile IPv6 (MIPv6) 106 [1] to enable support for network mobility. The extensions are 107 backward compatible with Mobile IPv6. In particular, a NEMO 108 compliant Home Agent can operate as a Mobile IPv6 Home Agent as well. 110 The NEMO Basic Support works in such a way that session continuity is 111 ensured for all the nodes in the mobile network even as the Mobile 112 Router changes its point of attachment to the Internet. It also 113 provides connectivity and reachability for all nodes in the mobile 114 network as the network moves. The solution supports both mobile 115 nodes and hosts that do not support mobility in the mobile network. 117 Within the context of this document, the definition of a Mobile 118 Router extends that of a Mobile IPv6 [1] Mobile Node, by adding 119 the capability of routing between its point of attachment (Care-of 120 Address) and a subnet which moves with the Mobile Router. 122 The solution described in this document requires setting up a 123 bi-directional tunnel between the Mobile Router and its Home Agent. 124 This tunnel is set up when the Mobile Router sends a successful 125 Binding Update to its Home Agent, informing the Home Agent of its 126 current point of attachment. 128 All traffic between the nodes in the mobile network and Correspondent 129 Nodes passes through the Home Agent. This document does not describe 130 route optimization of this traffic. 132 The terminology document [9] 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 it 139 should be noted that this might introduce significant overhead on the 140 data packets as each level of nesting introduces another IPv6 header 141 encapsulation. 143 2. Terminology 145 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [2]. 149 Network Mobility related terminology is defined in [8] [9]. This 150 document in addition defines the following terms. 152 Mobile Network Prefix 154 An IPv6 prefix that is delegated to a Mobile 155 Router and advertised in the mobile network. There could 156 be more than one Mobile Network Prefix being advertised in 157 a mobile network. 159 Prefix Table 161 It is a list of Mobile Network Prefixes indexed by 162 the Home Address of a Mobile Router. The prefix table is 163 managed by the Home Agent and is used by the Home Agent 164 to determine which Mobile Network Prefixes belong to a 165 particular Mobile Router. 167 3. Overview of the NEMO Protocol 169 A Mobile Network is a network segment or subnet which can move and 170 attach to arbitrary points in the Internet. A mobile network can 171 only be accessed via specific gateways called Mobile Routers that 172 manage its movement. Mobile networks have atleast one Mobile Router 173 serving them. A Mobile Router does not distribute the mobile network 174 routes to the infrastructure at its point of attachment (i.e. in the 175 visited network). Instead, it maintains a bidirectional tunnel to a 176 Home Agent that advertises an aggregation of mobile networks to the 177 infrasructure. The Mobile Router is also the default gateway for the 178 mobile network. 180 A mobile network can also consist of multiple and nested subnets. A 181 router with no support for mobility may be permanently attached to 182 a mobile network for local distribution. Also, Mobile Routers may 183 be attached to mobile networks owned by different Mobile Routers and 184 form a graph. In particular, with Basic NEMO Support, each Mobile 185 Router is attached to another mobile network by a single interface, 186 and if loops are avoided, the graph is a tree. 188 A Mobile Router has an unique Home Address through which it is 189 reachable when it is registered with its Home Agent. The Home 190 Address is configured from a prefix that is aggregated and advertised 191 by its Home Agent. The prefix could either be the prefix advertised 192 on the home link or the prefix delegated to the Mobile Router. 193 The Mobile Router can have more than one Home Address if there 194 are multiple prefixes in the home link. The Mobile Router also 195 advertises one or more prefixes in the mobile network attached to it. 196 The actual mechanism for assigning these prefixes to a given Mobile 197 Router is outside the scope of this specification. 199 When the Mobile Router moves away from the home link and attaches to 200 a new access router, it acquires a Care-of Address from the visited 201 link. The Mobile Router can at any time act either as a Mobile Host 202 or a Mobile Router. In either case, as soon as the Mobile Router 203 acquires a Care-of Address, it immediately sends a Binding Update to 204 its Home Agent as described in [1]. When the Home Agent receives 205 this Binding Update it creates a binding cache entry binding the 206 Mobile Router's Home Address to its Care-of address at the current 207 point of attachment. 209 If the Mobile Router wishes to act as a Mobile Router and provide 210 connectivity to nodes in the mobile network, it indicates this to the 211 Home Agent by setting a flag (R) in the Binding Update. It MAY also 212 include information about the Mobile Network Prefix in the Binding 213 Update using one of the modes described in Section 5.2, so that the 214 Home Agent can forward packets meant for nodes in the mobile network 215 to the Mobile Router. A new Mobility Header Option is described in 216 this document to carry prefix information. This option is described 217 in Section 4.3. If the mobile network has more than one IPv6 prefix 218 and wants the Home Agent to setup forwarding for all these prefixes, 219 it includes multiple prefix information options in a single Binding 220 Update. The Home Agent sets up forwarding for each of these prefixes 221 to the Mobile Router's Care-of Address. In some scenarios the Home 222 Agent already knows which prefixes belong to a Mobile Router. In 223 these scenarios, the Mobile Router does not include any prefix 224 information in the Binding Update. The Home Agent sets up forwarding 225 for all prefixes owned by the Mobile Router, when it receives a 226 Binding Update from the mobile router with the router flag (R) set. 228 The Home Agent acknowledges the Binding Update by sending a Binding 229 Acknowledgement to the Mobile Router. A positive acknowledgement 230 means that the Home Agent has set up forwarding for the mobile 231 network. Once the binding process completes, a bi-directional tunnel 232 is established between the Home Agent and the Mobile Router. The 233 tunnel end points are Mobile Router's Care-of Address and the Home 234 Agent's address. If a packet with a source address belonging to 235 the Mobile Network Prefix is received from the mobile network, the 236 Mobile Router reverse-tunnels the packet to the Home Agent through 237 this tunnel. This reverse-tunneling is done by using IP-in-IP 238 encapsulation [3]. The Home Agent decapsulates this packet and 239 forwards it to the Correspondent Node. For traffic originated by 240 itself, the Mobile Router can use either reverse tunneling or route 241 optimization as specified in [1]. 243 When a data packet is sent by a Correspondent Node to a node in the 244 mobile network, it gets routed to the Home Agent which currently 245 has the binding for the Mobile Router. It is expected that the 246 Mobile Router's network prefix would be aggregated at the Home Agent, 247 which advertises the resulting aggregation. Alternatively, the Home 248 Agent may receive the data packets destined to the mobile network 249 by advertising routes to the Mobile Network Prefix. The actual 250 mechanism by which these routes are advertised is outside the scope 251 of this document. When the Home Agent receives a data packet meant 252 for a node in the mobile network, it tunnels the packet to Mobile 253 Router's current Care-of address. The Mobile Router decapsulates 254 the packet and forwards it onto the interface where the mobile 255 network is connected. The Mobile Router before decapsulating the 256 tunneled packet, has to check if the Source address on the outer IPv6 257 header is the Home Agent's address. It also has to make sure the 258 destination address on the inner IPv6 header belongs to one of its 259 Mobile Network Prefixes before forwarding the packet to the mobile 260 network. 262 The mobile network could consist of nodes that do not support 263 mobility and nodes that support mobility. A node in the mobile 264 network can also be a fixed or a mobile router. The protocol 265 described here ensures complete transparency of network mobility to 266 the nodes in the mobile network. Mobile Nodes that attach to the 267 mobile network treat it as a normal IPv6 access network and run the 268 Mobile IPv6 protocol. 270 It is also possible for the Mobile Router and the Home Agent to run 271 a routing protocol through the bi-directional tunnel. In that case, 272 the Mobile Router need not include prefix information in the Binding 273 Update. Instead the Home Agent uses the routing protocol updates to 274 setup forwarding for the mobile network. When running the routing 275 protocol it is required that the bi-directional tunnel be treated as 276 a tunnel interface. The tunnel interface is included as the list of 277 interfaces on which routing protocol is active. The Mobile Router 278 should be configured not to run the routing protocol on its egress 279 interface when it is away from the home link. 281 Finally, the Home Agent may be configured with static routes to the 282 Mobile Network Prefix via the Mobile Router's Home Address. In that 283 case, the routes are set independently of the binding flows and the 284 returning Home of a Mobile Router. The benefit is that such movement 285 does not induce any additional signalling in the form of routing 286 updates in the Home Network. The drawback of that model is that the 287 routes are present even if the related Mobile Routers that are not 288 reachable (at Home or bound) at a given point of time. 290 4. Message Formats 292 4.1. Binding Update 294 A new flag (R) is included in the Binding Update to indicate to the 295 Home Agent if the Binding Update is coming from a Mobile Router 296 and not from a mobile node. The rest of the Binding Update format 297 remains the same as defined in [1]. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Sequence # | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 |A|H|L|K|R| Reserved | Lifetime | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | 307 . . 308 . Mobility options . 309 . . 310 | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Mobile Router Flag (R) 315 The Mobile Router Flag is set to indicate to the Home Agent 316 that the Binding Update is from a Mobile Router. If the flag 317 is set to 0, the Home Agent assumes that the Mobile Router is 318 just behaving as a Mobile Node, and MUST NOT forward packets 319 destined for the mobile network to the Mobile Router. 321 Mobility Options 323 Variable length field which can include zero or more mobility 324 options. This document defines a new mobility option in 325 addition to what is defined in [1]. 327 For a description of the other fields in the message, see [1]. 329 4.2. Binding Acknowledgement 331 A new flag (R) is included in the Binding Acknowledgement to indicate 332 that the Home Agent which processed the corresponding Binding Update 333 supports Mobile Routers. The flag is set only if the corresponding 334 Binding Update had the Mobile Router flag (R) set to 1. The rest of 335 the Binding Acknowledgement format remains the same as defined in 336 [1]. 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Status |K|R| Reserved | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Sequence # | Lifetime | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | | 346 . . 347 . Mobility options . 348 . . 349 | | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Mobile Router Flag (R) 354 The Mobile Router Flag is set to indicate that the Home Agent 355 which processed the Binding Update supports Mobile Routers. It 356 is set to 1 only if the corresponding Binding Update had the 357 Mobile Router flag set to 1. 359 For a description of the other fields in the message, see [1]. 361 This document also introduces the following new Binding 362 Acknowledgement status values. 364 140 Mobile Router Operation not permitted 366 141 Invalid Prefix 368 142 Not Authorized for Prefix 370 143 Forwarding Setup failed 372 Status values less than 128 indicate that the Binding Update was 373 processed successfully by the receiving nodes. Values greater than 374 128 indicate that the Binding Update was rejected by the Home Agent. 376 4.3. Mobile Network Prefix Option 378 The Mobile Network Prefix Option is included in the Binding Update 379 to indicate to the Home Agent the prefix information for the mobile 380 network. There could be multiple Mobile Network Prefix Options 381 if the Mobile Router has more than one IPv6 prefix in the mobile 382 network and wants the Home Agent to forward packets for each of these 383 prefixes to the Mobile Router's current location. 385 The Mobile Network Prefix Option has an alignment requirement of 386 8n+4. Its format is as follows. 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Type | Length | Reserved | Prefix Length | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 | | 394 + + 395 | | 396 + Mobile Network Prefix + 397 | | 398 + + 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Type 404 TBA 406 Length 408 8 bit unsigned integer indicating the length in octets of the 409 option excluding the type and length fields. Set to 18. 411 Reserved 413 This field is unused for now. The value MUST be initialized to 414 zero by the sender, and MUST be ignored by the receiver. 416 Prefix Length 418 8 bit unsigned integer indicating the prefix length of the IPv6 419 prefix contained in the option. 421 Mobile Network Prefix 423 A 16 byte field contains the Mobile Network Prefix. 425 5. Mobile Router Operation 427 Mobile Router operation is derived largely from the combined 428 behaviors of a Host, of a Router [6], and of a Mobile Node [1]. 430 A Mobile Node can act in two different ways: (1) as a Mobile Host 431 (in which case the Mobile IPv6 Home Agent doesn't maintain any prefix 432 information related to the Mobile Host's Home Address, but does 433 maintain a binding cache entry related to the Mobile Host's Home 434 Address) and (2) as a Mobile Router (in which case, in addition to 435 maintaining the binding cache entry corresponding to the Mobile 436 Router Home Address, the Mobile IPv6 Home Agent also maintains 437 forwarding information related to prefixes assigned to the mobile 438 network). The distinction between the the two modes is represented 439 by the value of the Mobile Router flag (R). 441 A Mobile Router MUST implement all requirements for IPv6 Mobile 442 Nodes, Section 8.5 in [1]. However if a Mobile Router is not 443 expected to initiate sessions of its own and behaves purely as a 444 router serving the mobile network most of the time, then the Route 445 Optimization functionality MAY be implemented. 447 5.1. Data Structures 449 Like a Mobile Host, a Mobile Router also maintains a Binding Update 450 List, described in Section 11.1 of Mobile IPv6 specification[1]. The 451 Binding Update list is a conceptual data structure which records 452 information that is sent in the Binding Updates. There is one entry 453 per each destination that the Mobile Router is currently sending 454 Binding Updates to. 456 This document introduces a new Prefix Information field in the 457 Binding Update list structure. This field is used to store any 458 prefix information that the Mobile Router includes in the Binding 459 Update. If the Mobile Router sets the Mobile Router flag (R) in the 460 Binding Update, but does not include any prefix information in it 461 this field is set to null. The Mobile Router does not include prefix 462 information in the Binding Update in the implicit mode or when it 463 runs a dynamic routing protocol with its Home Agent. 465 Similar to a Mobile Host, a Mobile Router stores the information 466 regarding status of flags of the Binding Update, in the corresponding 467 Binding Update List entry. This document introduces a new mobile 468 router flag (R) for this entry. The status of this flag is stored in 469 the Binding Update list whenever a Binding Update is sent. 471 A Mobile Router also maintains a Home Agent list populated according 472 to the same procedure as a Mobile Host. 474 5.2. Sending Binding Updates 476 A Mobile Router sends Binding Updates to its Home Agent as described 477 in [1]. It uses one of the following modes to instruct the Home 478 Agent to determine the prefixes that belong to the Mobile Router. In 479 all the modes, the Mobile Router sets the Mobile Router flag (R). 481 Implicit: 483 In this mode, the Mobile Router does not include either a 484 Mobile Network Prefix Option or a Mobile Network Prefix Length 485 Option in the Binding Update (but it does include the Home 486 Address Option in the Destination Options header, as all Mobile 487 Hosts do). The Home Agent can use any mechanism (not defined 488 in this document) to determine the Mobile Network Prefix(es) 489 owned by the Mobile Router and setup forwarding for the mobile 490 network. One example would be manual configuration at the 491 Home Agent mapping the Mobile Router's Home Address to the 492 information required for setting up forwarding for the mobile 493 network. 495 Explicit: 497 In this mode, the Mobile Router includes one or more Mobile 498 Network Prefix Options in the Binding Update. These options 499 contain information about the Mobile Network Prefix(es) 500 configured on the mobile network. 502 A Mobile Router MUST implement atleast one mode and MAY implement 503 both modes. If the Mobile Router flag is set, Home Registration flag 504 (H) MUST be set. 506 5.3. Receiving Binding Acknowledgements 508 The Mobile Router receives Binding Acknowledgements from the Home 509 Agent, corresponding to the Binding Updates it sent. If the Binding 510 Acknowledgement status is set to '0' (Binding Update accepted) and 511 the Mobile Router flag (R) is set to 1, the Mobile Router assumes 512 that the Home Agent has successfully processed the Binding Update 513 and has set up forwarding for the mobile network. The Mobile Router 514 can then start using the bi-directional tunnel for reverse tunneling 515 traffic from the mobile network. If the Mobile Router flag (R) is 516 not set, then the Mobile Router concludes that its current Home 517 Agent does not support Mobile Routers and performs Dynamic Home 518 Agent Discovery again to discover Home Agents which support Mobile 519 Routers. Additional the Mobile Router MUST also de-register with the 520 Home Agent which did not support Mobile Routers before attempting 521 registration with another Home Agent. 523 5.4. Error Processing 525 If the Binding Acknowledgement status is set to a value between 128 526 and 140, the Mobile Router takes necessary actions as described in 527 the Mobile IPv6 specification [1]. 529 If the Mobile Router sent a Binding Update to the Home Agent in 530 implicit mode (i.e. the prefix field in the Binding Update list 531 entry is null) then the Mobile Router interprets only the error 532 status '140' (Mobile Router Operation not permitted) and '143' 533 (Forwarding Setup failed). For this Binding Update, the Mobile 534 Router MUST discard Binding Acknowledgements with codes '141' and 535 '142'. 537 For the same Binding Update, if the status is '140', then the Mobile 538 Router should send a similar Binding Update (implicit mode) to 539 another Home Agent on the same home link. If no Home Agent replies 540 positively then the Mobile Router MUST refrain from sending any 541 Binding Update with the Mobile Router flag set to any Home Agent on 542 the home link, and log the information. 544 For the same Binding Update, if the status is '143', then the Mobile 545 Router should send a similar Binding Update (implicit mode) to 546 another Home Agent on the same home link. If no Home Agent replies 547 positively then Mobile Router SHOULD refrain from sending this 548 Binding Update to any Home Agent on the home link, and MAY send 549 Binding Updates in another mode (e.g. explicitly include a prefix) 550 to a Home Agent on the same home link. 552 If the Mobile Router sent a Binding Update to Home Agent in explict 553 mode then the Mobile Router interprets only the error status 554 '141' (Invalid Prefix) and '142' (Not Authorized for Prefix). 555 For this Binding Update, the Mobile Router MUST discard Binding 556 Acknowledgements with codes '140' and '143'. 558 For the same Binding Update, if the status is set to '141', then the 559 Mobile Router should send a similar Binding Update to another Home 560 Agent on the same home link. If no Home Agent replies positively 561 then Mobile Router SHOULD refrain from sending this Binding Updates 562 to any Home Agent on the home link. At this point, Mobile Router MAY 563 try to obtain and own a prefix by the same means that it initially 564 got assigned the current Mobile Network Prefix. Alternatively, 565 Mobile Router MAY send Binding Updates in another mode (e.g. 566 implicit mode) to a Home Agent on the same home link. 568 For the same Binding Update, if the status is set to '142', then the 569 Mobile Router should send a similar Binding Update to another Home 570 Agent on the same home link. If no Home Agent replies positively 571 then Mobile Router SHOULD refrain from sending this Binding Updates 572 to any Home Agent on the home link. Additionally, the Home Agent 573 MUST stop advertising the respective prefix(es) in the mobile network 574 with associated Router Advertisements, and modify its own forwarding 575 information accordingly. Following this, the Mobile Router MAY send 576 Binding Updates in another mode (e.g. implicit) to a Home Agent on 577 the same home link. 579 If at the end of this Error Processing procedure the Mobile Router 580 has tried every available modes of sending Binding Updates and still 581 has not received a positive Binding Acknowledgement (status value 582 between 0 and 127) for this Home Address from any Home Agent on its 583 home link, then the Mobile Router MUST stop sending Binding Updates 584 with the Mobile Router flag set for this Home Address and log the 585 information. 587 In all the above cases, the Mobile Router MUST conclude that the Home 588 Agent did not create a binding cache entry for the Mobile Router's 589 Home Address. 591 5.5. Establishment of Bi-directional Tunnel 593 When a successful Binding Acknowledgement is received, the Mobile 594 Router sets up its endpoint of the bi-directional tunnel. 596 The bi-directional tunnel between Mobile Router and Home Agent allows 597 packets to flow in both directions between these entities, while the 598 Mobile Router is connected to a Visited Link. The bi-directional 599 tunnel involves two virtual links [3]: one virtual link has the 600 address of the tunnel entry point as the Care-of Address of the 601 Mobile Router and the tunnel exit point as the address of the 602 Home Agent; the other virtual link has as tunnel entry point the 603 Home Agent address and as tunnel exit point the Care-of Address 604 of the Mobile Router. Both addresses are unicast addresses. All 605 IPv6 traffic to and from the mobile network is sent through this 606 bi-directional tunnel. 608 A Mobile Router MAY limit the number of mobile routers that attach to 609 its mobile network (the number of levels in the nested aggregation) 610 by means of setting the Tunnel Encapsulation Limit field of the 611 Tunnel Encapsulation option. 613 A Mobile Router uses the Tunnel Hop Limit that is normally assigned 614 to routers (not to hosts). Please refer to [3] for more details. 616 5.6. Neighbor Discovery for Mobile Router 618 When the Mobile Router is at home, it MAY be configured to send 619 Router Advertisements and reply to Router Solicitations on the 620 interface attached to the home link. The value of the Router 621 Lifetime field MUST be set to zero to prevent other nodes from 622 configuring the Mobile Router as the default router. 624 A Mobile Router SHOULD NOT send unsolicited Router Advertisements 625 and SHOULD NOT reply to Router Solicitations on any egress interface 626 when that interface is attached to a visited link. However, the 627 Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor 628 Solicitations received on the egress interface, for topologically 629 correct addresses. 631 A router typically ignores router advertisements sent by other 632 routers on a link. However, a Mobile Router MUST NOT ignore Router 633 Advertisements received on the egress interface. The received Router 634 Advertisements MAY be used for address configuration, default router 635 selection or movement detection. 637 5.7. Multicast Groups for Mobile Router 639 When at home, the Mobile Router joins the multicast group All Routers 640 Address with scopes '1' interface-local (on the home-advertising 641 interface) and '2' link-local on any of its egress interfaces. When 642 in a visited network, the Mobile Router MUST NOT join the above 643 multicast groups on the corresponding interface. 645 5.8. Returning Home 647 When the Mobile Router realizes it has returned to its home link 648 through movement detection mechanisms, it MUST de-register with 649 its Home Agent. The Mobile Router MUST implement and follow the 650 returning home procedures defined for a mobile node in [1]. In 651 addition, the Mobile Router MAY start behaving as a router on its 652 egress interface. In particular, 654 - The Mobile Router MAY send router advertisements on its egress 655 interfaces. But the router lifetime SHOULD be set to 0, so that 656 hosts on the home link do not pick the Mobile Router as the 657 default router. 659 - The Mobile Router MAY join the All Routers multicast group on the 660 home link. 662 - The Mobile Router MAY send routing protocol messages on its 663 egress interface if it is configured to run a dynamic routing 664 protocol. 666 6. Home Agent Operation 668 In order for a Mobile Router to operate correctly, the Home Agent 669 MUST satisfy all the requirements listed in Section 8.4 of [1]. The 670 Home Agent MUST implement both modes described in Section 5.2 of this 671 document. 673 6.1. Data Structures 675 6.1.1. Binding Cache 677 The Home Agent maintains Binding Cache Entries for each Mobile Router 678 that is currently registered with the Home Agent. The Binding Cache 679 is a conceptual data structure described in detail in [1]. 681 The Home Agent might need to store the Mobile Network Prefixes 682 associated with a Mobile Router in the corresponding Binding Cache 683 Entry. This is required if the Binding Update (that created the 684 Binding Cache Entry) contained explicit prefix information. This 685 information can be used later to cleanup routes installed in explicit 686 mode, when the Binding Cache Entry is removed, and to maintain the 687 routing table, for instance should the routes be manually removed. 689 The Home Agent also stores the status of the Mobile Router Flag (R) 690 in the Binding Cache entry. 692 6.1.2. Prefix Table 694 The Home Agent SHOULD be able to prevent a Mobile Router from 695 claiming Mobile Network Prefixes that belong to another Mobile 696 Router. The Home Agent can prevent such attacks if it maintains a 697 Prefix Table and verifies the Prefix Information provided by the 698 Mobile Router against the entries in the Prefix Table. The Prefix 699 Table SHOULD be used by the Home Agent when it processes a Binding 700 Update in explicit mode. It is not required when a dynamic routing 701 protocol is run between the Mobile Router and the Home Agent. 703 Each entry in the Prefix Table conceptually contains the following 704 fields: 706 - The Home Address of the Mobile Router. This field is used as the 707 key for searching the pre-configured prefix table. 709 - The Mobile Network Prefix of the Mobile Router associated with 710 the Home Address. 712 6.2. Mobile Network Prefix Registration 714 The Home Agent processes the Binding Update as described in Section 715 10.3.1 of the Mobile IPv6 specification [1]. This section describes 716 the processing of the Binding Update if the Mobile Router (R) flag is 717 set. The Home Agent performs the following check in addition. 719 - The Home Registration (H) flag MUST be set. If not, the 720 Home Agent MUST reject the Binding Update and send a Binding 721 Acknowledgement with status set to 140. Note: The basic support 722 does not allow sending Binding Update for a Mobile Network Prefix 723 to correspondent nodes (for route optimization). 725 - Mobile IPv6 specification [1] requires that the Home Address in 726 the Binding Update should be configured from a prefix advertised 727 on the home link. Otherwise the Binding Update is rejected 728 with status value 132 [1]. This specification relaxes this 729 requirement so that the Home Agent rejects the Binding Update 730 only if Home Address does not belong to the prefix that the Home 731 Agent is configured to serve. 733 If the Home Agent does not reject the Binding Update as described 734 above, then it retrieves the Mobile Network Prefix information as 735 described below. 737 - If a Mobile Network Prefix Option is present in the Binding 738 Update, the prefix information for the Mobile Network Prefix is 739 retrieved from the Mobile Network Prefix field and the Prefix 740 Length field of the option. If the Binding Update contains more 741 than one option, the Home Agent MUST set up forwarding for all of 742 the Mobile Network Prefixes. If the Home Agent fails to setup 743 forwarding to all the prefixes listed in the Binding Update, then 744 it MUST NOT forward traffic to any of the prefixes, reject the 745 Binding Update and send a Binding Acknowledgement with status set 746 to 141 (Invalid Prefix). 748 If the Home Agent verifies the prefix information with the Prefix 749 Table and the check fails, the Home Agent MUST discard the 750 Binding Update and send a Binding Acknowldegement with status set 751 to 142 (Not Authorized for Prefix). 753 - If there are is no option in the Binding Update carying 754 prefix information, the Home Agent uses manual pre-configured 755 information to determine the prefixes assigned to the Mobile 756 Router and for setting up forwarding for the mobile network. If 757 there is no information that the Home Agent can use, it MUST 758 reject the Binding Update and send a Binding Acknowledgement with 759 status set to 143 (Forwarding Setup failed). 761 If the Lifetime specified in the Binding Update is zero or the 762 specified Care-of address matches the Home Address in the Binding 763 Update, then this is a request to delete the cached binding for 764 the home address and specified Mobile Network Prefixes. The 765 Binding Update is processed according to the procedure described in 766 Section 6.7. 768 If all checks are passed, the Home Agent creates a binding cache 769 entry for Mobile Router's Home Address, or updates the binding cache 770 entry if it already exists. Otherwise, the Home Agent MUST NOT 771 register the binding of the Mobile Router's Home Address. 773 The Home Agent defends the Mobile Router's Home Address through Proxy 774 Neighbor Discovery by multicasting onto the home link a Neighbor 775 Advertisement message on behalf of the mobile router. All fields in 776 the Proxy Neighbor Advertisement message should be set in the same 777 way they would be set by the Mobile Router itself if sending this 778 Neighbor Advertisement while at home, as described in [7], with the 779 exception that the Router (R) bit in the Advertisement MUST be set if 780 the Mobile Router (R) flag has been set in the Binding Update. 782 The Home Agent also creates a bi-directional tunnel to the mobile 783 router for the requested Mobile Network Prefix, or update an existing 784 bi-directional tunnel as described in Section 6.4. 786 6.3. Advertising Mobile Network Reachability 788 In order to be able to receive packets meant for the mobile network, 789 the Home Agent advertises reachability to the mobile network. If the 790 Home Link is configured with a prefix that is an aggregation and if 791 the Mobile Network Prefix is aggregated under that prefix, then the 792 routing updates advertising reachability to the mobile network are 793 sent only on the Home Link. If the Home Agent is the only default 794 router on the Home Link, routes to the Mobile Network Prefix get 795 aggregated naturally under the Home Agent and the Home Agent does not 796 have to do anything special. 798 If the Home Agent receives routing updates through a dynamic routing 799 protocol from the Mobile Router, those routes are propagated by 800 the routing protocol running on the Home Agent on the relevant 801 interfaces. 803 6.4. Establishment of Bi-directional Tunnel 805 The implementation of the bi-directional tunnels and the mechanism 806 of attaching them to the IP stack are outside the scope of this 807 specification. However, all implementations MUST be capable of the 808 following operations. 810 - The Home Agent can tunnel packets meant for the mobile network 811 prefix to the Mobile Router's current location, the Care-of 812 Address of the Mobile Router. 814 - The Home Agent can accept packets tunneled by the Mobile Router 815 with source address of the outer IPv6 header set to the Care-of 816 Address of the Mobile Router. 818 6.5. Forwarding Packets 820 When the Home Agent receives a data packet destined for the mobile 821 network, it MUST forward the packet to the Mobile Router through the 822 bi-directional tunnel. The Home Agent either uses only the routing 823 table, only the Binding Cache or a combination of routing table 824 and Binding Cache to route packets to the mobile network. This is 825 implementation specific. Two examples are shown below. 827 1. The Home Agent maintains a route to the Mobile Network Prefix 828 with the next hop set to the Mobile Router's Home Address. When 829 the Home Agent tries to forward the packet to the next hop, it 830 finds a binding cache entry for the home address. Then the Home 831 Agent extracts the Mobile Router's Care-of address and tunnels 832 the packet to the Care-of address. 834 2. The Home Agent maintains a route to the Mobile Network Prefix 835 with the outgoing interface set to the bi-directional tunnel 836 interface between the Home Agent and the Mobile Router. For 837 this purpose, the Home Agent MUST treat this tunnel as a tunnel 838 interface. When the packets are forwarded through the tunnel 839 interface, they get encapsulated automatically with the source 840 address and destination address in the outer IPv6 header set to 841 the Home Agent's address and the Mobile Router's Care-of address, 842 respectively. 844 6.6. Sending Binding Acknowledgements 846 A Home Agent serving a Mobile Router sends Binding Acknowledgements 847 according to the same rules it uses for sending Binding 848 Acknowledgements to Mobile Hosts [1], with the following 849 enhancements. 851 The Home Agent sets the status code in the Binding Acknowledgement 852 to '0' (Binding Update accepted) in order to indicate to the Mobile 853 Router that it successfully processed the Binding Update. It also 854 sets the Mobile Router flag (R) to indicate to the Mobile Router that 855 it has setup forwarding for the mobile network. 857 If the Home Agent is configured not to support mobile routers, it 858 sets the status code in the Binding Acknowledgement to '140' (Mobile 859 Router Operation not permitted). 861 If one or more prefixes received in the Binding Update are invalid 862 and the Home Agent cannot setup forwarding for the prefixes, the Home 863 Agent sets the status code in the Binding Acknowledgement to '141' 864 (Invalid Prefix) in order to indicate this to the Mobile Router. 866 If the Mobile Router is not authorized to use this Home Address to 867 forward packets for one or more prefixes that are present in the 868 Binding Update, the Home Agent sets the status code in the Binding 869 Acknowledgement to '142' (Not Authorized for Prefix) in order to 870 indicate this. 872 The Home Agent sets the status code to 143 (Forwarding Setup 873 failed) if it is unable to determine the information needed to setup 874 forwarding for the mobile network. This is used in the Implicit mode 875 where the Mobile Router does not include any prefix information in 876 the Binding Update. 878 6.7. Mobile Network Prefix De-Registration 880 The Mobile Router de-registers with the Home Agent by sending a 881 Binding Update with the lifetime set to zero. When the Home Agent 882 successfully processes the de-registration BU, it deletes the Binding 883 Cache Entry for the Mobile Router's Home Address and stops proxying 884 the Home Address. This is described in detail in the Mobile IPv6 885 specification [1]. 887 In addition, the Home Agent also removes the bi-directional tunnel 888 and stops forwarding packets to the mobile network. The Home Agent 889 should keep all necessary information to clean up whichever routes it 890 installed, whether they come from implicit or explicit source. 892 7. Modifications to Dynamic Home Agent Discovery 894 This document extends the Dynamic Home Agent Discovery mechanism 895 defined in [1], so that Mobile Routers attempt registration only with 896 Home Agents that support Mobile Routers. 898 7.1. Modified Dynamic Home Agent Discovery Request 900 A new flag (R) (Support for Mobile Routers) is introduced in the 901 Dynamic Home Agent Discovery Reguest message defined in [1]. The 902 Mobile Router sets this flag to indicate that it wants to discover 903 Home Agents that support Mobile Routers. 905 0 1 2 3 906 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 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Type | Code | Checksum | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | Identifier |R| Reserved | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 Mobile Router Support Flag (R) 915 A 1 bit flag which when set indicates that the Mobile Router 916 wants to discover Home Agents that support Mobile Routers. 918 For a description of the other fields in the message, see [1]. 920 7.2. Modified Dynamic Home Agent Discovery Reply 922 A new flag (R) (Support for Mobile Routers) is introduced in the 923 Dynamic Home Agent Discovery Reply message defined in [1]. If a Home 924 Agent receives a Dynamic Home Agent Discovery request message with 925 the Mobile Router Support flag set, it MUST reply with a list of Home 926 Agents that support Mobile Routers. The Mobile Router Support flag 927 MUST be set if there is atleast one Home Agent that supports Mobile 928 Routers. If none of the Home Agents support Mobile Routers, the Home 929 Agent MAY reply with a list of Home Agents that support just Mobile 930 IPv6 Mobile Nodes. In this case, the Mobile Router Support flag MUST 931 be set to 0. 933 The modified message format is as follows. 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Type | Code | Checksum | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Identifier |R| Reserved | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | | 943 + + 944 . . 945 . Home Agent Addresses . 946 . . 947 + + 948 | | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 Mobile Router Support Flag (R) 953 A 1 bit flag which when set indicates that the Home Agents 954 listed in this message support Mobile Routers. 956 For a description of the other fields in the message, see [1]. 958 7.3. Modified Home Agent Information Option 960 A new flag (R) (Support for Mobile Routers) is introduced in the Home 961 Agent Information Option defined in [1]. If a Home Agent supports 962 Mobile Routers, it SHOULD set the flag. 964 0 1 2 3 965 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 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Type | Length |R| Reserved | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Home Agent Preference | Home Agent Lifetime | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 Mobile Router Support Flag (R) 974 A 1 bit flag which when set indicates that the Home Agent 975 supports Mobile Routers. 977 For a description of the other fields in the message, see [1]. 979 8. Support for Dynamic Routing Protocols 981 In the solution described so far, forwarding to the mobile network 982 at the Home Agent is set up when the Home Agent receives a Binding 983 Update from the Mobile Router. An alternative to this is for the 984 Home Agent and the Mobile Router to run an intra-domain routing 985 protocol like RIPng [11] and OSPF [12] through the bi-directional 986 tunnel. The Mobile Router can continue running the same routing 987 protocol that it was running when it was attached to the home link. 989 This feature is very useful when the mobile network is large with 990 multiple subnets containing different IPv6 prefixes. Routing changes 991 in the mobile network are propagated to the Home Agent quickly. 992 Routing changes in the home link are also propogated to the Mobile 993 Router very quickly. 995 When the Mobile Router is attached to the home link, it runs a 996 routing protocol by sending routing updates through its egress 997 interface. When the mobile router moves and attaches to a visited 998 network, it MUST stop sending routing updates on the interface with 999 which it attaches to the visited link. This is very important so 1000 that IPv6 prefixes specific to the mobile network do not leak into 1001 the visited network. The Mobile Router then starts sending routing 1002 protocol messages through the bi-directional tunnel towards the Home 1003 Agent. Most routing protocols use link local addresses as source 1004 addresses for the routing information messages. The Mobile Router is 1005 allowed to use link local addresses for the inner IPv6 header of an 1006 encapsulated packet. But these messages after decapsulation MUST NOT 1007 be forwarded to another link by either the Mobile Router or the Home 1008 Agent. 1010 When the Home Agent receives the encapsulated routing protocol 1011 message, it processes the inner packets and updates its routing table 1012 accordingly. The next hop information in these routing entries is 1013 filled with the Mobile Router's link local address with the outgoing 1014 interface set to the bi-directional tunnel. 1016 Similary, the Home Agent also sends routing updates through the 1017 bi-directional tunnel to the Mobile Router. The Mobile Router 1018 processes these routing protocol messages and updates its routing 1019 table. For all routes advertised by the Home Agent, the Mobile 1020 Router sets the outgoing interface to the bi-directional tunnel to 1021 the Home Agent. 1023 When the Mobile Router and the Home Agent exchange routes through 1024 a dynamic routing protocol, the Mobile Router should be careful in 1025 including the same Mobile Network Prefixes in the Binding Update to 1026 the Home Agent and in the routing protocol updates. The Home Agent 1027 depending on its configuration might not add routes based on the 1028 prefix information in the Binding Updates at all, and might use only 1029 the routing protocol updates. Moreover, including the same prefix 1030 information in both the Binding Update and the routing protocol 1031 update is redundant. 1033 Since the routing protocol messages from the Home Agent to the Mobile 1034 Router could potentially contain information about the internal 1035 routing structure of the home network, these messages require 1036 authentications and confidentiality protection. Confidentialy 1037 protection using IPsec ESP [4] MUST be supported and SHOULD be 1038 used. For protecting routing protocol messages using ESP, the 1039 bi-directional tunnel between the Mobile Router and the Home 1040 Agent should be treated as the outgoing interface, with link local 1041 addresses as source and destination addresses for the messages. 1042 IPsec ESP with a non-null encryption algorithm should be used 1043 in transport mode for protecting the routing protocol messages. 1044 Examples of SPD entries for protecting OSPFv3 messages are described 1045 in [13]. 1047 9. Security Considerations 1049 All signaling messages between the Mobile Router and the Home Agent 1050 MUST be authenticated by IPsec [5]. The use of IPsec to protect 1051 Mobile IPv6 signaling messages is described in detail in the HA-MN 1052 IPsec specification [2]. The signaling messages described in this 1053 document just extend Mobile IPv6 messages and do not require any 1054 changes to what is described in the HA-MN IPsec specification. 1056 The Mobile Router has to perform ingress filtering on packets 1057 received from the mobile network to ensure that nodes in the Mobile 1058 Network do not use the bi-directional tunnel to launch IP spoofing 1059 attacks. In particular the Mobile Router SHOULD check that the IP 1060 source address in the packets received from the nodes in the Mobile 1061 Network belongs to the Mobile Network Prefix and is not the same as 1062 one of the addresses used by the Mobile Router. In case the Mobile 1063 Router receives a IP-in-IP tunneled packet from a node in the Mobile 1064 Network and the Mobile Router has to forward the decapsulated packet, 1065 it SHOULD perform the above mentioned checks on the source address of 1066 the inner packet. 1068 The Home Agent has to verify that packets received through the 1069 bi-directional tunnel belong to the mobile network. This check is 1070 necessary in order to prevent nodes from using the Home Agent to 1071 launch attacks that would have otherwise been prevented by ingress 1072 filtering. The source address of the outer IPv6 header MUST be set 1073 to the Mobile Router's current Care-of address. The source address 1074 of the inner IPv6 header MUST be a topologically correct address with 1075 respect to the IPv6 prefixes used in the mobile network. 1077 When the Mobile Router is running a dynamic routing protocol as 1078 described in Section 8, it injects routing update messages into the 1079 Home Link. The Home Agent MUST verify that the Mobile Router is 1080 allowed to send routing updates before processing the messages and 1081 propagating the routing information. 1083 Please refer to the Mobile IPv6 specification [1] for security 1084 considerations when the Mobile Router operates as a Mobile Host. 1086 10. IANA Considerations 1088 This document defines a new Mobility Header Option, the Mobile 1089 Network Prefix Option. This option is described in Section 4.3. The 1090 type value for this option needs to be assigned from the same space 1091 used by the mobility options defined in [1]. 1093 This document also defines the following new Binding Acknowledgement 1094 status values. These status values are defined in Section 4.2 1095 and need to be assigned from the same space used for Binding 1096 Acknowledgement status values in [1]. 1098 - Mobile Router Operation not permitted 1100 - Invalid Prefix 1102 - Not Authorized for Prefix 1104 - Forwarding Setup failed 1106 11. Contributors 1108 We would like to acknowledge Ludovic Bellier, Claude Castelluccia, 1109 Thierry Ernst, Miguel Catalina-Gallego, Christophe Janneteau, T.J. 1110 Kniveton, Hong-Yon Lach, Jari T. Malinen, Koshiro Mitsuya, Alexis 1111 Olivereau, Charles E. Perkins and Keisuke Uehara, for their work on 1112 earlier proposals for Network Mobility. This document inherits a lot 1113 of ideas from these proposals. 1115 12. Acknowledgements 1117 We thank all members of the NEMO Working Group, and of the preceding 1118 MONET BoF for fruitful discussions on the mailing list and at IETF 1119 meetings. 1121 Kent Leung, Marco Molteni and Patrick Wetterwald for their work on 1122 Network Mobility for IPv4 and IPv6. 1124 Tim Leinmueller for many insightful remarks and for Section 7. 1126 Jari Arkko, James Kempf and Chan-Wah Ng for their thorough review and 1127 comments. 1129 References 1131 [1] D. Johnson, C. Perkins and J. Arkko. Mobility Support in IPv6. 1132 Internet Draft, IETF. draft-ietf-mobileip-ipv6-24.txt (work in 1133 progress). June 2003. 1135 [2] J. Arkko, V. Devarapalli and F. Dupont. Using IPsec to Protect 1136 Mobile IPv6 Signaling between Mobile Nodes and Home Agents. 1137 Internet Draft, IETF. draft-ietf-mobileip-mipv6-ha-ipsec-06.txt 1138 (work in progress). June 2003. 1140 [3] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 1141 Specification. RFC 2473, IETF. December 1998. 1143 [4] S. Kent and R. Atkinson. IP Encapsulating Security Payload 1144 (ESP). RFC 2402, IETF. November 1998. 1146 [5] S. Kent and R. Atkinson. Security Architecture for the Internet 1147 Protocol. RFC 2401, IETF. November 1998. 1149 [6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) 1150 Specification. RFC 2460, IETF. December 1998. 1152 [7] T. Narten, E. Nordmark and W. Simpson. Neighbour Discovery for 1153 IP Version 6 (IPv6). RFC 2461, IETF. December 1998. 1155 References 1157 [8] J. Manner and M. Kojo. Mobility Related Terminology. Internet 1158 Draft, IETF. draft-ietf-seamoby-mobility-terminology-05.txt 1159 (work in progress). November 2003. 1161 [9] T. Ernst and H.-Y. Lach. Network Mobility Support Terminology. 1162 Internet Draft, IETF. draft-ietf-nemo-terminology-00.txt (work 1163 in progress). May 2003. 1165 [10] T. Ernst. Network Mobility Support Goals and Requirements. 1166 Internet Draft, IETF. draft-ietf-nemo-requirements-01.txt (work 1167 in progress). May 2003. 1169 [11] G. Malkin and R. Minnear. RIPng for IPv6. RFC 2080, IETF. 1170 January 1997. 1172 [12] R. Coltun, D. Ferguson and J. Moy. OSPF for IPv6. RFC 2470, 1173 IETF. December 1999. 1175 [13] M. Gupta and N. Melam. Authentication/Confidentiality for 1176 OSPFv3. Internet Draft, IETF. draft-ietf-ospf-ospfv3-auth-04.txt 1177 (work in progress). December 2003. 1179 [14] T. Ernst. Network Mobility Support in IPv6. PhD Thesis, 1180 University Joseph Fourier, Grenoble, France. October 2001. 1182 [15] T. Ernst, K, Mitsuya and K. Uehara. Network Mobility from the 1183 InternetCAR perspective. Journal of Interconnection Networks 1184 (JOIN), Vol. 4, No. 3. September 2003. 1186 A. Examples of NEMO Basic Support Operation 1188 This section tries to illustrate the NEMO protocol using a Mobile 1189 Router and a Mobile Node belonging to different administrative 1190 domains. The Mobile Router's mobile network consists of a Local 1191 Fixed Node (LFN) and a Local Fixed Router (LFR) [9]. The LFR has 1192 an access link to which other Mobile Nodes or Mobile Routers could 1193 attach to. 1195 Figure 1 depicts the scenario where both the Mobile Router and the 1196 Mobile Node are at home. 1198 +----+ +-------+ 1199 | MN | | HA_MN | 1200 +--+-+ 1:: +---+---+ 1201 2+-------------+3 1202 | 1203 | 1204 +-------+2 2:: +-------------------+ 3:: 2+-------+ 1205 | CN_MN |------| Internet |------| CN_MR | 1206 +-------+ +-------------------+ +-------+ 1207 4:: | 1208 | 1209 2+-------------+3 1210 +--+-+ +---+---+ 1211 | MR | | HA_MR | 1212 +--+-+ +-------+ 1213 5:: |1 1214 ---------- 1215 2| |3 1216 +--+-+ +--+-+ 1217 | LFN| | LFR| 1218 +--+-+ +--+-+ 1219 6:: |1 1220 ---------- 1222 Figure 1: Mobile Router and Mobile Node at home. 1224 The Mobile Router then moves away from the home link and attaches to 1225 a visited link. This is shown in Figure 2. The Mobile Router sends 1226 a Binding Update to HA_MR when it attaches to a visited link and 1227 configures a Care-of Addres. HA_MR creates a binding cache entry for 1228 the Mobile Router's Home Address and also sets up forwarding for the 1229 prefixes on the mobile network. 1231 +----+ +-------+ 1232 | MN | | HA_MN | 1233 +--+-+ 1:: +---+---+ 1234 2+-------------+3 1235 | 1236 | 1237 +-------+2 2:: +-------------------+ 3:: 2+-------+ 1238 | CN_MN |------| Internet |------| CN_MR | 1239 +-------+ ++------------------+ +-------+ 1240 | 7:: 4:: | 4::2->7::2 1241 | | 1242 2+ +3 1243 +--+-+ +---+---+ 1244 | MR | | HA_MR | 4::2->7::2 1245 +--+-+ +-------+ 5::/prefixlen -> forward 1246 5:: |1 to MR 1247 ---------- 6::/prefixlen -> forward 1248 2| |3 to MR 1249 +--+-+ +--+-+ 1250 | LFN| | LFR| 1251 +--+-+ +--+-+ 1252 6:: |1 1253 ---------- 1255 Figure 2: Mobile Router on a Visited Link. 1257 Figure 3 shows the Mobile Node moving away from its home link and 1258 attaching to the Mobile Router. The Mobile Node configures a Care-of 1259 Address from the prefix advertised on the mobile network and sends a 1260 Binding Update to its Home Agent (HA_MN) and its Correspondent Node 1261 (CN_MN). Both HA_MN and CN_MN create binding cache entries for the 1262 Mobile Node's Home Address. 1264 +-------+ 1265 | HA_MN | 1::2->6::2 1266 1:: +---+---+ 1267 ---------|3 1268 | 1269 | 1270 +-------+2 2:: +-------------------+ 3:: 2+-------+ 1271 | CN_MN |------| Internet |------| CN_MR | 1272 +-------+ ++------------------+ +-------+ 1273 1::2->6::2 | 7:: 4:: | 4::2->7::2 1274 | | 1275 2+ +3 1276 +--+-+ +---+---+ 1277 | MR | | HA_MR | 4::2->7::2 1278 +--+-+ +-------+ 5::/prefixlen -> forward 1279 5:: |1 to MR 1280 ---------- 6::/prefixlen -> forward 1281 2| |3 to MR 1282 +--+-+ +--+-+ 1283 | LFN| | LFR| 1284 +--+-+ +--+-+ 1285 6:: |1 1286 --------+- 1287 |2 1288 +--+-+ 1289 | MN | 1290 +----+ 1292 Figure 3: Mobile Node attached to Mobile 1293 Router on a Visited Link 1295 B. Changes from Previous Version 1297 The following changes have been made to this document from version 01 1299 - Dynamic Home Agent Discovery was modified to return only Home 1300 Agents that support Mobile Routers. A new section was added to 1301 the specification. (Issue 16). 1303 - A new flag (R) was introduced in the Binding Acknowledgement for 1304 the Home Agent to indicate to the Mobile Router that it processed 1305 the Mobile Router flag (R) in the corresponding Binding Update. 1306 (Issue 16). 1308 - Relaxed a Mobile IPv6 requirement which said the Home Agent MUST 1309 drop a Binding Update if the home address is not configured from 1310 the home prefix. NEMO Home Agent drops the Binding Update only 1311 if the Home Address does not belong to the prefix that the Home 1312 Agent is currently configured to serve. (Issue 19) 1314 - Explicit Prefix Length mode is removed. (Issue 20). 1316 - Text related to Mobile Router performing ingress filtering was 1317 added to the Security Considerations section to prevent some 1318 threats due to tunneling. (Issue 23). 1320 - Added a new section on Mobile Router returning home. (Issue 25). 1322 - Clarified that the Prefix Table is not required when a dynamic 1323 routing protocol is being run between the Mobile Router and the 1324 Home Agent. (Issue 26). 1326 - Clarified the use of Prefix Table. (Issue 25). 1328 - Clarified Mobile Router sending router advertisements on its 1329 egress interface when at home. (Issue 21 and 26). 1331 - Clarified implementation requirements with respect to the Mobile 1332 IPv6 specification. (Issue 27). 1334 - Modified/added network mobility terms so that the NEMO 1335 terminology document becomes an informative reference. (Issue 1336 28). 1338 - Provided more information for creating SPD entries for protecting 1339 routing protocol messages. (Issue 29). 1341 Authors Addresses 1343 Vijay Devarapalli 1344 Nokia Research Center 1345 313 Fairchild Drive 1346 Mountain View, CA 94043 1347 USA 1348 Email: vijay.devarapalli@nokia.com 1350 Ryuji Wakikawa 1351 Keio University and WIDE 1352 5322 Endo Fujisawa Kanagawa 1353 252-8520 Japan 1354 Email: ryuji@sfc.wide.ad.jp 1356 Alexandru Petrescu 1357 Motorola Labs 1358 Parc les Algorithmes Saint Aubin 1359 Gif-sur-Yvette 91193 1360 France 1361 Email: Alexandru.Petrescu@motorola.com 1363 Pascal Thubert 1364 Cisco Systems Technology Center 1365 Village d'Entreprises Green Side 1366 400, Avenue Roumanille 1367 Biot - Sophia Antipolis 06410 1368 France 1369 Email: pthubert@cisco.com 1371 Intellectual Property Statement 1373 The IETF has been notified of intellectual property rights claimed 1374 in regard to some or all of the specification contained in this 1375 document. For more information consult the online list of claimed 1376 rights. 1378 The IETF takes no position regarding the validity or scope of any 1379 intellectual property or other rights that might be claimed to 1380 pertain to the implementation or use of the technology described in 1381 this document or the extent to which any license under such rights 1382 might or might not be available; neither does it represent that it 1383 has made any effort to identify any such rights. Information on 1384 the IETF's procedures with respect to rights in standards-track and 1385 standards-related documentation can be found in BCP-11. Copies of 1386 claims of rights made available for publication and any assurances 1387 of licenses to be made available, or the result of an attempt 1388 made to obtain a general license or permission for the use of such 1389 proprietary rights by implementers or users of this specification can 1390 be obtained from the IETF Secretariat. 1392 The IETF invites any interested party to bring to its attention any 1393 copyrights, patents or patent applications, or other proprietary 1394 rights which may cover technology that may be required to practice 1395 this standard. Please address the information to the IETF Executive 1396 Director. 1398 Full Copyright Statement 1400 Copyright (C) The Internet Society (2003). All Rights Reserved. 1402 This document and translations of it may be copied and furnished to 1403 others, and derivative works that comment on or otherwise explain it 1404 or assist in its implementation may be prepared, copied, published 1405 and distributed, in whole or in part, without restriction of any 1406 kind, provided that the above copyright notice and this paragraph 1407 are included on all such copies and derivative works. However, 1408 this document itself may not be modified in any way, such as by 1409 removing the copyright notice or references to the Internet Society 1410 or other Internet organizations, except as needed for the purpose 1411 of developing Internet standards in which case the procedures 1412 for copyrights defined in the Internet Standards process must be 1413 followed, or as required to translate it into languages other than 1414 English. 1416 The limited permissions granted above are perpetual and will not be 1417 revoked by the Internet Society or its successors or assignees. 1419 This document and the information contained herein is provided on an 1420 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1421 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1422 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1423 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1424 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1426 Acknowledgement 1428 Funding for the RFC Editor function is currently provided by the 1429 Internet Society.