idnits 2.17.1 draft-ietf-mip4-nemo-v4-base-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.1 on line 18. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 954. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 961. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 967. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1, updated by RFC 4748 (on line 983), which is fine, but *also* found old RFC 3978, Section 5.4, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 19 longer pages, the longest (page 18) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 4, 2007) is 6042 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) == Outdated reference: A later version (-03) exists of draft-ietf-mip4-nemov4-fa-01 == Outdated reference: A later version (-10) exists of draft-ietf-mip4-rfc3344bis-05 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Leung 2 Internet-Draft G. Dommety 3 Expires: April 9, 2008 Cisco Systems 4 V. Narayanan 5 Qualcomm, Inc. 6 A. Petrescu 7 Motorola 8 October 4, 2007 10 Network Mobility (NEMO) Extensions for Mobile IPv4 11 draft-ietf-mip4-nemo-v4-base-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 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 This Internet-Draft will expire on April 9, 2008. 38 Copyright Notice 40 Copyright (C) The Internet Society (2007). 42 Abstract 44 This document describes a protocol for supporting Mobile Networks 45 between a Mobile Router and a Home Agent by extending the Mobile IPv4 46 protocol. A Mobile Router is responsible for the mobility of one or 47 more network segments or subnets moving together. The Mobile Router 48 hides its mobility from the nodes on the mobile network. The nodes 49 on the Mobile Network may be fixed in relationship to the Mobile 50 Router and may not have any mobility function. 52 Extensions to Mobile IPv4 are introduced to support Mobile Networks. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Mobile Network Extensions . . . . . . . . . . . . . . . . . . 3 60 4.1. Mobile Network Request Extension . . . . . . . . . . . . . 3 61 4.2. Mobile Network Acknowledgement Extension . . . . . . . . . 4 62 5. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 6 63 5.1. Error Processing . . . . . . . . . . . . . . . . . . . . . 6 64 6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 7 65 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 6.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 8 67 6.2.1. Registration Table . . . . . . . . . . . . . . . . . . 8 68 6.2.2. Prefix Table . . . . . . . . . . . . . . . . . . . . . 8 69 6.3. Mobile Network Prefix Registration . . . . . . . . . . . . 8 70 6.4. Advertising Mobile Network Reachability . . . . . . . . .10 71 6.5. Establishment of Bi-directional Tunnel . . . . . . . . . .10 72 6.6. Sending Registration Replies . . . . . . . . . . . . . . .10 73 6.7. Mobile Network Prefix De-registration . . . . . . . . . .11 74 7. Data Forwarding Operation . . . . . . . . . . . . . . . . . .11 75 8. Nested Mobile Networks . . . . . . . . . . . . . . . . . . . .11 76 9. Routing Protocol between Mobile Router and Home Agent. . . . .12 77 10. Security Considerations . . . . . . . . . . . . . . . . . . .13 78 10.1 Security when Dynamic Routing Protocol is Used. . . . . . .13 79 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .14 80 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .15 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . .15 82 13.1. Normative References . . . . . . . . . . . . . . . . . . .15 83 13.2. Informative References . . . . . . . . . . . . . . . . . .15 84 13. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . .16 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .17 86 Intellectual Property and Copyright Statements . . . . . . . . . .18 88 1. Introduction 90 This document describes protocol extensions to Mobile IPv4 as per 91 [RFC3344] and its update [2], to enable support for Mobile 92 Networks. This draft addresses mainly the co-located Care-of 93 Address mode. Foreign Agent Care-of Address mode (with 'legacy' 94 Foreign Agents, RFC 3344) are supported but without optimization, 95 double encapsulation being used. For an optimization of this mode, 96 the gentle reader is directed to [1]. 98 A Mobile Network is defined as a network segment or subnet that can 99 change its point of attachment to the routing infrastructure. Such 100 movement is performed by a Mobile Router, which is the mobility 101 entity that provides connectivity and reachability as well as 102 session continuity for all the nodes in the Mobile Network. The 103 Mobile Router typically serves as the default gateway for the hosts 104 on the Mobile Network. 106 Mobility for the Mobile Network is supported by the Mobile Router 107 registering the point of attachment to its Home Agent. This 108 signaling sets up the tunnel between the two entities. 110 The Mobile Networks (either implicitly configured on the Home Agent 111 or explicitly identified by the Mobile Router) are advertised by 112 the Home Agent for route propagation. Traffic to and from nodes in 113 the Mobile Network are tunneled by the Home Agent to the Mobile 114 Router, and vice versa. Though packets from the Mobile Network can 115 be forwarded directly without tunneling (if reverse tunneling is 116 not used) packets will be dropped if ingress filtering is turned 117 on. 119 This document specifies an additional tunnel between Mobile Router's 120 Home Address and the Home Agent. This tunnel is encapsulated within 121 the normal tunnel between the Care-of Address (CoA) and Home Agent. 122 In Foreign Agent CoA mode, the tunnel between the Mobile Router and 123 Home Agent is needed to allow the Foreign Agent to direct the 124 decapsulated packet to the proper visiting Mobile Router. However, 125 in Collocated CoA mode, the additional tunnel is not essential and 126 can be eliminated because the Mobile Router is the recipient of the 127 encapsulated packets for the Mobile Network. 129 All traffic between the nodes in the Mobile Network and Correspondent 130 Nodes passes through the Home Agent. This document does not cover 131 route optimization of this traffic. 133 A similar protocol has been documented in [RFC3963] for supporting 134 IPv6 mobile networks with Mobile IPv6 extensions. 136 Multihoming for Mobile Routers is outside the scope of this 137 document. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 Terminology for network mobility support is defined in [RFC3344] 146 and its update [2]. In addition, this document defines the 147 following terms. 149 Mobile Network Prefix 151 The network prefix of the subnet delegated to a Mobile Router 152 as the Mobile Network. 154 Prefix Table 156 A list of Mobile Network Prefixes indexed by the Home Address 157 of a Mobile Router. The Home Agent manages and uses Prefix 158 Table to determine which Mobile Network Prefixes belong to a 159 particular Mobile Router. 161 3. Requirements 163 Although Mobile IPv4 stated that Mobile Network can be supported by 164 the Mobile Router and Home Agent using static configuration or 165 running a routing protocol, there is no solution for explicit 166 registration of the Mobile Networks served by the Mobile Router. A 167 solution needs to provide the Home Agent a means to ensure that a 168 Mobile Router claiming a certain Mobile Network Prefix is 169 authorized to do so. A solution would also expose the Mobile 170 Network Prefixes (and potentially other subnet-relevant 171 information) in the exchanged messages, to aid in network 172 debugging. 174 The following requirements for Mobile Network support are 175 enumerated: 177 o A Mobile Router should be able to operate in explicit or implicit 178 mode. A Mobile Router may explicitly inform the Home Agent which 179 Mobile Network(s) need to be propagated via routing protocol. A 180 Mobile Router may also function in implicit mode, where the Home 181 Agent may learn the mobile networks through other means, such as 182 from the AAA server, via pre-configuration or via a dynamic 183 routing protocol. 185 o The Mobile Network should be supported using Foreign Agents that 186 are compliant to RFC 3344 without any changes ('legacy' Foreign 187 Agents). 189 o The mobile network should allow Fixed nodes, Mobile Nodes, or 190 Mobile Routers to be on it. 192 4. Mobile Network Extensions 194 4.1. Mobile Network Request Extension 196 For Explicit Mode, the Mobile Router informs the Home Agent about 197 the Mobile Network Prefixes during registration. The Registration 198 Request contains zero, one or several Mobile Network Request 199 extensions in addition to any other extensions defined by or in the 200 context of [RFC3344]. When several Mobile Networks are needed to 201 be registered, each is included in a separate Mobile Network 202 Request extension, with its own Type, Length, Sub-Type, Prefix 203 Length and Prefix fields. A Mobile Network Request extension is 204 encoded in Type-Length-Value (TLV) format and respects the 205 following format: 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Type | Length | Sub-Type | Prefix Length | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Prefix | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Type: 217 Mobile Network Extension (skippable type range to be assigned 218 by IANA) 220 Length: 222 6 224 Sub-Type: 226 1 (Mobile Network Request) 228 Prefix Length: 230 8-bit unsigned integer indicating the number of bits covering 231 the network part of the address contained in the Prefix field. 233 Prefix: 235 32-bit unsigned integer in network byte-order containing an 236 IPv4 address whose first Prefix Length bits make up the Mobile 237 Network Prefix. 239 4.2. Mobile Network Acknowledgement Extension 241 The Registration Reply contains zero, one or several Mobile Network 242 Acknowledgement extensions in addition to any other extensions 243 defined by or in the context of [RFC3344] and its update [2]. 244 For Implicit Mode, the Mobile Network Acknowledgement informs the 245 Mobile Router the prefixes for which the Home Agent sets up 246 forwarding with respect to this Mobile Router. Policies such as 247 permitting only traffic from these Mobile Networks to be tunneled 248 to the Home Agent may be applied by the Mobile Router. For 249 Explicit Mode, when several Mobile Networks are needed to be 250 acknowledged explicitly, each is included in a separate Mobile 251 Network Acknowledgement extension, with its own Type, Sub-Type, 252 Length and Prefix Length fields. Optionally, all requested Mobile 253 Networks could be acknowledged using only one Mobile Network 254 Acknowledgement extension with "Prefix Length" and "Prefix" fields 255 set to zero. At least one Mobile Network Acknowledgement extension 256 MUST be in a successful Registration Reply to indicate to the 257 Mobile Router that the Mobile Network Request extension was 258 processed, thereby not skipped by the Home Agent. 260 A Registration Reply may contain any non-zero number of Explicit 261 Mode and Implicit Mode Acknowledgements sub-types. Both sub-types 262 can be present in a single Registration Reply. A Mobile Network 263 Acknowledgement extension is encoded in Type-Length-Value (TLV) 264 format. When the registration is denied with code HA_MOBNET_ERROR, 265 the Code field in the extension provides the reason for the 266 failure. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Type | Length | Sub-Type | Code | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Prefix Length | Reserved | Prefix 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Type: 280 Mobile Network Extension (skippable type range to be assigned 281 by IANA) 283 Length: 285 8 287 Sub-Type: 289 TBA (Explicit Mode Acknowledgement) 291 TBA (Implicit Mode Acknowledgement) 293 Code: 295 Value indicating success or failure. 297 0 Success 299 TBA Invalid prefix (MOBNET_INVALID_PREFIX_LEN) 301 TBA Mobile Router is not authorized for prefix 302 (MOBNET_UNAUTHORIZED) 304 TBA Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) 306 Prefix Length: 308 8-bit unsigned integer indicating the number of bits covering 309 the network part of the address contained in the Prefix field. 311 Reserved: 313 Sent as zero; ignored on reception. 315 Prefix: 317 32-bit unsigned integer in network byte-order containing an 318 IPv4 address whose first Prefix Length bits make up the Mobile 319 Network Prefix. 321 5. Mobile Router Operation 323 A Mobile Router's operation is generally derived from the behavior 324 of a Mobile Node, as set in [RFC3344] and its update [2]. In 325 addition to maintaining mobility bindings for its Home Address, the 326 Mobile Router, together with the Home Agent, maintains forwarding 327 information for the Mobile Network Prefix(es) assigned to the 328 Mobile Router. 330 A Mobile Router SHOULD set the 'T' bit to 1 in all Registration 331 Request messages it sends to indicate the need for reverse tunnels 332 for all traffic. Without reverse tunnels, all the traffic from the 333 mobile network will be subject to ingress filtering in the visited 334 networks. Upon reception of successful registration reply, the 335 Mobile Router processes the registration in accordance to RFC 3344. 336 In addition, the following steps are taken: 338 o Check for Mobile Network Acknowledgement extension(s) in 339 Registration Reply 341 o Create tunnel to the Home Agent if registered in reverse tunneling 342 mode 344 o Set up default route via this tunnel or egress interface when 345 registered with or without reverse tunneling, respectively 347 In accordance with this specification, a Mobile Router may operate in 348 one of the following two modes: explicit and implicit. In explicit 349 mode, the Mobile Router includes Mobile Network Prefix information in 350 all Registration Requests (as Mobile Network Request extensions), 351 while in implicit mode it does not include this information in any 352 Registration Request. In this latter case, the Home Agent obtains 353 the Mobile Network Prefixes by other means than Mobile IP. One 354 example of obtention of the Mobile Network Prefix is through static 355 configuration on the Home Agent. 357 A Mobile Router can obtain a Collocated or Foreign Agent Care-of- 358 Address while operating in explicit or implicit modes. 360 For de-registration, the Mobile Router sends a registration request 361 with lifetime set to zero without any Mobile Network Request 362 extensions. 364 5.1. Error Processing 366 A Mobile Router interprets the values of the Code field in Mobile 367 Network Acknowledgement Extension of the Registration Reply in order 368 to identify any error related to managing the Mobile Network Prefixes 369 by the Home Agent. 371 If the value of the Code field in the Registration Reply is set to 372 HA_MOBNET_DISALLOWED, then the Mobile Router MUST stop sending 373 Registration Requests with any Mobile Network Prefix extensions to 374 that Home Agent. 376 If the value of the Code field in the Registration Reply is set to 377 HA_MOBNET_ERROR then the Mobile Router MUST stop sending Registration 378 Requests that contain any of the Mobile Network Prefixes that are 379 defined by the values of the fields Prefix and Prefix Length in the 380 Mobile Network Acknowledgement extension. Note that the registration 381 is denied in this case and no forwarding for any Mobile Network 382 Prefixes would be set up by the Home Agent for the Mobile Router. 384 It is possible that the Mobile Router receives a registration reply 385 with no mobile network extensions if the registration was processed 386 by a Mobile IPv4 home agent that does not support this specification 387 at all. In that case, the absence of mobile network extensions must 388 be interpreted by the Mobile Router as the case where the Home Agent 389 does not support mobile networks. 391 All the error code values are TBA (To Be Assigned) subject to IANA 392 allocation. 394 6. Home Agent Operation 396 6.1. Summary 398 A Home Agent MUST support all the operations specified in [RFC3344] 399 and its update [2] for mobile node support. The Home Agent MUST 400 support both implicit and explicit modes of operation for a Mobile 401 Router. 403 The Home Agent processes the registration in accordance to RFC 3344, 404 which includes route set up to the Mobile Router's home address via 405 the tunnel to the Care-of Address. In addition, for a Mobile Router 406 registering in explicit mode, the following steps are taken: 408 1. Check that the Mobile Network Prefix information is valid 410 2. Ensure the Mobile Network Prefix(es) is or are authorized to be 411 on the Mobile Router 413 3. Create tunnel to the Mobile Router if it does not already exist 415 4. Set up route for the Mobile Network Prefix via this tunnel 417 5. Propagate Mobile Network Prefix routes via routing protocol 419 6. Send the Registration Reply with the Mobile Network 420 Acknowledgement extension(s) 422 If there are any subnet routes via the tunnel to the Mobile Router 423 that are not specified in the Mobile Network extensions, these routes 424 are removed. 426 In the case where the Mobile Node is not permitted to act as a Mobile 427 Router, the Home Agent sends a registration denied message with error 428 code HA_MOBNET_DISALLOWED. 430 For a Mobile Router registering in implicit mode, the Home Agent 431 performs steps 3-6 above, once the registration request is processed 432 successfully. 434 For deregistration, the Home Agent removes the tunnel to the Mobile 435 Router and all routes using this tunnel. The Mobile Network 436 extensions are ignored. 438 6.2. Data Structures 440 6.2.1. Registration Table 442 The Registration Table in the Home Agent, in accordance with 443 [RFC3344] and its update [2], contains binding information for 444 every Mobile Node registered with it. [RFC3344] and its update [2] 445 define the format of Registration Table. In addition to all the 446 parameters specified by [RFC3344] and its update [2], the Home 447 Agent MUST store the Mobile Network Prefixes associated with the 448 Mobile Router in the corresponding registration entry, when the 449 corresponding registration was performed in explicit mode. When 450 the Home Agent is advertising reachability to Mobile Network 451 Prefixes served by a Mobile Router, this information stored in the 452 Registration Table can be used. 454 6.2.2. Prefix Table 456 The Home Agent must be able to authorize a Mobile Router for use of 457 Mobile Network Prefixes when the Mobile Router is operating in 458 explicit mode. Also, when the Mobile Router operates in implicit 459 mode, the Home Agent must be able to locate the Mobile Network 460 Prefixes associated with that Mobile Router. The Home Agent may 461 store the home address of the Mobile Router along with the mobile 462 network prefixes associated with that Mobile Router. If the Mobile 463 Router does not have a home address assigned, this table may store 464 the NAI [RFC2794] of the Mobile Router that will be used in dynamic 465 home address assignment. 467 6.3. Mobile Network Prefix Registration 469 The Home Agent must process registration requests coming from 470 Mobile Routers in accordance with this section. The document 471 [RFC3344] and its update [2] specify that the home address of a 472 mobile node registering with a Home Agent must belong to a prefix 473 advertised on the home network. In accordance with this 474 specification, however, the home address must be configured from a 475 prefix that is served by the Home Agent, not necessarily the one on 476 the home network. 478 If the registration request is valid, the Home Agent checks to see 479 if there are any Mobile Network Prefix extensions included in the 480 Registration Request. 482 If so, the Mobile Network Prefix information is obtained from the 483 included extensions, and the Home Address from the Home Address 484 field of the UDP header Registration Request. For every Mobile 485 Network Prefix extension included in the registration request, the 486 Home Agent MUST perform a check against the Prefix Table. If the 487 Prefix Table does not contain at least one entry pairing that Home 488 Address to that Mobile Network Prefix then the check fails, 489 otherwise it succeeds. 491 Following this check against the Prefix Table, the Home Agent MUST 492 construct a Registration Reply containing Mobile Network 493 Acknowledgement extensions. For a Mobile Network Prefix for which 494 the check was unsuccessfull the Code field in the corresponding 495 Mobile Network Acknowledgement extension should be set to 496 MOBNET_UNAUTHORIZED. 498 For a Mobile Network Prefix for which the check was successfull the 499 Code field in the respective Mobile Network Acknowledgement 500 extensions should be set to 0. 502 The Home Agent MUST attempt to set up forwarding for each Mobile 503 Network Prefix extension for which the Prefix Table check was 504 successfull. If the forwarding setup fails for a particular Mobile 505 Network Prefix (for reasons like not enough memory available, or 506 not enough devices available, or other similar) the Code field in 507 the respective Mobile Network Acknowledgement extension should be 508 set to MOBNET_FWDING_SETUP_FAILED. 510 If forwarding and setup was successful for at least one Mobile 511 Network Prefix then the Code field of the Registration Reply 512 message should be set to 0. Otherwise that Code should be 513 HA_MOBNET_ERROR. 515 If the registration request is sent in implicit mode, i.e., without 516 any Mobile Network Request extension, the Home Agent may use pre- 517 configured mobile network prefix information for the Mobile Router to 518 set up forwarding. 520 If the Home Agent is updating an existing binding entry for the 521 Mobile Router, it MUST check all the prefixes in the registration 522 table against the prefixes included in the registration request. 523 If one or more mobile network prefix is missing from the included 524 information in the registration request, it MUST delete those 525 prefixes from the registration table. Also, the Home Agent MUST 526 disable forwarding for those prefixes. 528 If all checks are successful, the Home Agent either creates a new 529 entry for the Mobile Router or updates an existing binding entry 530 for it and returns a successful registration reply back to the 531 Mobile Router or the Foreign Agent (if the registration request was 532 received from a Foreign Agent). 534 In accordance with [RFC3344], the Home Agent does proxy ARP for the 535 Mobile Router home address, when the Mobile Router home address is 536 derived from the home network. 538 If the 'T' bit is set, the Home Agent creates a bi-directional 539 tunnel for the corresponding mobile network prefixes or updates the 540 existing bi-directional tunnel. This tunnel is maintained 541 independent of the reverse tunnel for the Mobile Router home 542 address itself. 544 6.4. Advertising Mobile Network Reachability 546 If the mobile network prefixes served by the Home Agent are 547 aggregated with the home network prefix and if the Home Agent is 548 the default router on the home network, the Home Agent does not 549 have to advertise the Mobile Network Prefixes. The routes for the 550 Mobile Network Prefix are automatically aggregated into the home 551 network prefix (it is assumed that the Mobile Network Prefixes are 552 automatically aggregated into the home network prefix). If the 553 Mobile Router updates the mobile network prefix routes via a 554 dynamic routing protocol, the Home Agent SHOULD propagate the 555 routes on the appropriate networks. 557 6.5. Establishment of Bi-directional Tunnel 559 The Home Agent creates and maintains a bi-directional tunnel for the 560 mobile network prefixes of a Mobile Router registered with it. A 561 home agent supporting IPv4 Mobile Router operation MUST be able to 562 forward packets destined to the mobile network prefixes served by the 563 mobile router to its care-of-address. Also, the Home Agent MUST be 564 able to accept packets tunneled by the Mobile Router with the source 565 address of the outer header is set to the care-of-address of the 566 mobile router and that of the inner header is set to the Mobile 567 Router's home address or an address from one of the registered mobile 568 network prefixes. 570 6.6. Sending Registration Replies 572 The Home Agents MUST set the status code in the registration reply to 573 0 to indicate successful processing of the registration request and 574 successful set up of forwarding for all the mobile network prefixes 575 served by the Mobile Router. The registration reply MUST contain at 576 least one Mobile Network Acknowledgement extension. 578 If the Home Agent is unable to set up forwarding for one of more 579 mobile network prefixes served by the Mobile Router, it MUST set the 580 Mobile Network Acknowledgement Extension status code in the 581 registration reply to MOBNET_FWDING_SETUP_FAILED. When the prefix 582 length is zero or greater than 32, the status code MUST be set to 583 MOBNET_INVALID_PREFIX_LEN. 585 If the Mobile Router is not authorized to forward packets to one or 586 mobile network prefixes included in the request, the Home Agent MUST 587 set the code to MOBNET_UNAUTHORIZED_MR. 589 6.7. Mobile Network Prefix De-registration 591 If the received registration request is for de-registration of the 592 care-of-address, the Home Agent, upon successful processing of it, 593 MUST delete the entry(ies) from its registration table. The home 594 agent tears down the bi-directional tunnel and stops forwarding any 595 packets to/from the Mobile Router. The Home Agent MUST ignore any 596 included Mobile Network Request extension in a de-registration 597 request. 599 7. Data Forwarding Operation 601 For traffic to the nodes in the Mobile Network, the Home Agent MUST 602 perform double tunneling of the packet, if the Mobile Router had 603 registered with a Foreign Agent care-of-address. In this case, the 604 Home Agent MUST encapsulate the packet with tunnel header (source IP 605 address set to Home Agent and destination IP address set to Mobile 606 Router's home address) and then encapsulate one more time with tunnel 607 header (source IP address set to Home Agent and destination IP 608 address set to CoA). 610 For optimization, the Home Agent SHOULD only encapsulate the packet 611 with the tunnel header (source IP address set to Home Agent and 612 destination IP address set to CoA) for Collocated CoA mode. 614 When a Home Agent receives a packet from the mobile network prefix in 615 the bi-directional tunnel, it MUST de-encapsulate the packet and 616 route it as a normal IP packet. It MUST verify that the incoming 617 packet has the source IP address set to the care-of-address of the 618 Mobile Router. The packet MUST be dropped if the source address is 619 not set to the care-of-address of the Mobile Router. 621 For traffic from the nodes in the Mobile Network, the Mobile Router 622 encapsulates the packet with tunnel header (source IP address set to 623 Mobile Router's home address and destination IP address set to Home 624 Agent) if reverse tunnel is enabled. Otherwise, the packet is routed 625 directly to the Foreign Agent or access router. 627 In Collocated CoA mode, the Mobile Router MAY encapsulate one more 628 times with tunnel header (source IP address set to the CoA and 629 destination IP address set to Home Agent). 631 8. Nested Mobile Networks 633 Nested Network Mobility is a scenario where a Mobile Router allows 634 another Mobile Router to attach to its Mobile Network. There could 635 be arbitrary levels of nested mobility. The operation of each Mobile 636 Router remains the same whether the Mobile Router attaches to another 637 Mobile Router or to a fixed Access Router on the Internet. The 638 solution described here does not place any restriction on the number 639 of levels for nested mobility. But note that this might introduce 640 significant overhead on the data packets as each level of nesting 641 introduces another tunnel header encapsulation. 643 9. Routing Protocol between Mobile Router and Home Agent 645 There are several benefits of running a dynamic routing protocol 646 between the Mobile Router and the Home Agent. If the mobile 647 network is relatively large, including several wireless subnets, 648 then the topology changes within the moving network can be exposed 649 from the Mobile Router to the Home Agent by using a dynamic routing 650 protocol. The purpose of the NEMOv4 protocol extensions to Mobile 651 IPv4, as defined in previous sections, is not to inform the Home 652 Agent about these topology changes, but to manage the mobility of 653 the Mobile Router. 655 Similarly, topology changes in the home network can be exposed to 656 the Mobile Router by using a dynamic routing protocol. This may be 657 necessary when new fixed networks are added in the home network. 658 Here too, the purpose of NEMOv4 extensions is not to inform the 659 Mobile Router about topology changes at home. 661 Examples of dynamic routing protocol include but are not limited to 662 OSPF Version 2 [RFC2328], BGP [RFC4271] and RIP [RFC2453]. 664 The recommendations are related to how the routing protocol and the 665 Mobile IPv4 implementation work in tandem on the Mobile Router and 666 on the Home Agent (1) without creating incoherent states in the 667 forwarding information bases at home and on the Mobile Router (2) 668 without introducing topologically incorrect addressing information 669 in the visited domain and (3) efficiently avoid duplication of sent 670 data or over-provisioning of security. 672 The information exchanged between the Mobile Router and the Home 673 Agent is sent over the bi-directional tunnel established by the 674 Mobile IPv4 exchange Registration Request - Registration Reply (see 675 section 6.5). If a network address and prefix about a subnet in 676 the moving network is sent by the Mobile Router within a routing 677 protocol message then they SHOULD NOT be sent in the Mobile IPv4 678 Registration Request too, in order to avoid incoherencies in the 679 forwarding information bases. The Mobile Router SHOULD use NEMOv4 680 implicit mode in this case (see section 3). 682 The Mobile Router SHOULD NOT send routing protocol information 683 updates in the foreign network. The subnet addresses and prefixes 684 valid in the moving network are topologically incorrect in the 685 visited network. 687 If the Mobile Router and the Home Agent use a dynamic routing 688 protocol over the tunnel interface, and if that protocol offers 689 security mechanisms to protect that protocol's messages, then the 690 security recommendations in section 10.1 apply. 692 10. Security Considerations 694 The Mobile Network extension is protected by the same rules for 695 Mobile IP extensions in registration messages. See the Security 696 Considerations section in RFC 3344. 698 The Home Agent MUST be able to verify that the Mobile Router is 699 authorized to provide mobility service for the Mobile Networks in 700 the registration request, before anchoring these Mobile Network 701 Prefixes on behalf of the Mobile Router. Forwarding for prefixes 702 MUST NOT be set up without successful authorization of the Mobile 703 Router for those prefixes. A registration failure MUST be notified 704 to the mobile router when it cannot be successfully authorized for 705 prefixes requested by it. 707 All registration requests and replies MUST be authenticated by the 708 MN-HA Authentication Extension as specified in [RFC3344] and its 709 update [2]. When the registration request is sent in explicit 710 mode, i.e., with one or more Mobile Network Prefix extensions, all 711 the Mobile Network Prefix extensions MUST be included before the 712 MN-HA Authentication extension. Also, these extensions MUST be 713 included in the calculation of the MN-HA authenticator value. 715 The Mobile Router should perform ingress filtering on all the packets 716 received on the mobile network prior to reverse tunneling them to the 717 Home Agent. The Mobile Router MUST drop any packets that do not have 718 a source address belonging to the mobile network. 720 The Mobile Router MUST also ensure that the source address of 721 packets arriving on the mobile network is not the same as the 722 Mobile Router's IP address on any interface. These checks will 723 protect against nodes attempting to launch IP spoofing attacks 724 through the bi-directional tunnel. 726 The Home Agent, upon receiving packets through the bi-directional 727 tunnel, MUST verify that the source addresses of the outer IP header 728 of the packets are set to the Mobile Router's care-of-address. Also, 729 it MUST ensure that the source address of the inner IP header is a 730 topologically correct address on the mobile network. This will 731 prevent nodes from using the Home Agent to launch attacks inside the 732 protected network. 734 10.1 Security when Dynamic Routing Protocol is Used 736 If a dynamic routing protocol is used between the Mobile Router and 737 the Home Agent to propagate the mobile network information into the 738 home network, the routing updates SHOULD be protected with IPsec ESP 739 confidentiality between the Mobile Router and Home Agent, to prevent 740 information about home network topology from being visible to 741 eavesdroppers. 743 A routing protocol message protected with ESP, and sent through the 744 Mobile Router - Home Agent bidirectional tunnel, SHOULD NOT contain 745 the Mobile IPv4 Mobile-Home Authentication Extension, since ESP 746 provides enough security. 748 11. IANA Considerations 750 IANA to modify rules for the existing registry "Mobile IPv4 numbers - 751 per RFC 3344". The numbering space for Extensions that may appear in 752 Mobile IP control messages (those sent to and from UDP port number 753 434) should be modified. 755 The new Values and Names for the Type for Extensions appearing in 756 Mobile IP control messages are the following: 758 Value Name 759 ----- ------------------------------------------ 760 TBA Mobile Network Extension (To Be Assigned by IANA) 762 The new Values and Names for the Sub-Type for Mobile Network 763 Extension are the following: 765 Value Name 766 ----- ------------------------------------------ 767 TBA Mobile Network Request Extension 768 TBA Explicit Mode Acknowledgement Extension 769 TBA Implicit Mode Acknowledgement Extension 771 The new Code values for Mobile IP Registration Reply messages are 772 the following: 774 Code Values for Mobile IP Registration Reply messages 775 ----------------------------------------------------- 777 Registration denied by the Home Agent: (To Be Assigned by IANA) 779 TBA Mobile Network Prefix operation error (HA_MOBNET_ERROR) 780 TBA Mobile Router operation is not permitted 781 (HA_MOBNET_DISALLOWED) 783 The new Code Values for Mobile IP Registration Reply messages are the 784 following: 786 Code Values for Mobile Network Acknowledgement Extension 787 -------------------------------------------------------- 789 Registration denied by the Home Agent: 791 TBA Invalid prefix length (MOBNET_INVALID_PREFIX_LEN) 792 TBA Mobile Router is not authorized for prefix 793 (MOBNET_UNAUTHORIZED) 794 TBA Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) 796 The current non-modified numbering spaces could be consulted at the 797 following URL: http://www.iana.org/assignments/mobileip-numbers 798 (contents last updated 2007-07-02 and last browsed 2007-10-04, 799 October). 801 12. Acknowledgements 803 The authors would like to thank Christophe Janneteau, George 804 Popovich, Ty Bekiares, Ganesh Srinivasan, Alpesh Patel, Ryuji 805 Wakikawa, George Tsirtsis, and Henrik Levkowetz for their helpful 806 discussions, reviews and comments. Vijay Devarapalli extensively 807 reviewed one of the later versions of the draft. 809 13. References 811 13.1. Normative References 813 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 814 Requirement Levels", BCP 14, RFC 2119, March 1997. 816 [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access 817 Identifier Extension for IPv4", RFC 2794, March 2000. 819 [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, STD 56, November 820 1998. 822 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, STD 54, April 823 1998. 825 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 826 August 2002. 828 [RFC4271] Rekhter, Y, Ed., Li, T. and S. Hares, "A Border Gateway 829 Protocol (BGP-4)", RFC 4271, January 2006. 831 13.2. Informative References 833 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 834 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 835 RFC 3963, January 2005. 837 [1] Tsirtsis, G., Park, V., Narayanan, V., and K. Leung, "FA 838 extensions to NEMOv4 Base", 839 draft-ietf-mip4-nemov4-fa-01.txt, IETF Internet-Draft, 840 Work in Progress, March 19, 2007. 842 [2] Perkins, C., Ed., "IP Mobility Support for IPv4, 843 revised", draft-ietf-mip4-rfc3344bis-05.txt, IETF 844 Internet-Draft, Work in Progress, July 9, 2007. 846 14. Changelog 848 The changes are listed in reverse chronological order, most recent 849 changes appearing at the top of the list: 851 From draft-ietf-mip4-nemo-v4-base-02.txt to 852 draft-ietf-mip4-nemo-v4-base-03.txt 853 -changed a sentence in the introduction to say that FA mode _is_ 854 supported but unoptimized, and that a reference [1] optimizes 855 that mode. 856 -added reference [2] to the rfc3344bis draft. 858 From draft-ietf-mip4-nemo-v4-base-01.txt to 859 draft-ietf-mip4-nemo-v4-base-02.txt 860 -changed title from "IPv4 Network Mobility (NEMO) Protocol" to 861 "Network Mobility (NEMO) Extensions for Mobile IPv4" 863 From draft-ietf-mip4-nemo-v4-base-00.txt to 864 draft-ietf-mip4-nemo-v4-base-01.txt 865 -added a section on Routing Protocol between Mobile Router and 866 Home Agent. 867 -added a security subsection about running simultaneously a 868 secure routing protocol with secure Mobile IPv4. 869 -added a date tag on the IANA URL for Mobile IP numbering 870 spaces. 871 -substituted 'Mobile Router' for 'MR' everywhere. 872 -updated reference to NEMOv4 FA draft. 874 From draft-ietf-nemo-v4-base-01.txt to 875 draft-ietf-mip4-nemo-v4-base-00.txt: 876 -changed draft name, headers and footers. 877 -changed title. 878 -a more coherent use of terms 'subnet', 'prefix' and 'mobile 879 network'. 880 -clarified only co-located CoA mode is supported (not FA CoA). 881 for Mobile Routers in this specification. And added reference 882 to the FA NEMO optimizations draft. 883 -changed 'devices' to 'hosts'. 884 -changed 'moving networks' to 'mobile networks'. 885 -clarified what 'reachability' in a certain context is: packets 886 may be dropped if ingress filtering is turned on. 887 -removed the MR-FA-CoA tunnel overhead optimization. There is 888 still an issue with text at HA doing optimization. 890 This document was first presented as an individual contribution to 891 the NEMO Working Group, then adopted as a WG item to that group. 892 The 01 version in the NEMO WG has been Last Called on the 893 INFORMATIONAL track. The evolution was: 895 From version draft-ietf-nemo-v4-base-00 to 896 draft-ietf-nemo-v4-base-01: 897 -removed error code HA_MOBNET_UNSUPPORTED. 898 -changed all values to be assigned by IANA, from specific 899 numbers to "TBA" (To Be Assigned). 900 -substituted "egress interface" for "roaming interface". 901 -changed HA behaviour upon reception of MNPs. In 00 the HA 902 replied positively only if all MNPs in RegReq were valid, in 01 903 a reply is constructed specifying which MNP was valid and which 904 not. 905 -clarified a 3-line paragraph saying that RegRep may contain 906 both implicit and explicit acknowledgements. 908 Authors' Addresses 910 Kent Leung 911 Cisco Systems 912 170 W. Tasman Drive 913 San Jose, CA 95134 914 US 916 Phone: +1 408-526-5030 917 Email: kleung@cisco.com 919 Gopal Dommety 920 Cisco Systems 921 170 W. Tasman Drive 922 San Jose, CA 95134 923 US 925 Phone: +1 408-525-1404 926 Email: gdommety@cisco.com 928 Vidya Narayanan 929 QUALCOMM, Inc. 930 5775 Morehouse Dr 931 San Diego, CA 932 USA 934 Phone: +1 858-845-2483 935 Email: vidyan@qualcomm.com 937 Alexandru Petrescu 938 Motorola 939 Parc les Algorithmes Saint Aubin 940 Gif-sur-Yvette 91193 941 France 943 Email: Alexandru.Petrescu@motorola.com 945 Intellectual Property Statement 947 The IETF takes no position regarding the validity or scope of any 948 Intellectual Property Rights or other rights that might be claimed to 949 pertain to the implementation or use of the technology described in 950 this document or the extent to which any license under such rights 951 might or might not be available; nor does it represent that it has 952 made any independent effort to identify any such rights. Information 953 on the procedures with respect to rights in RFC documents can be 954 found in BCP 78 and BCP 79. 956 Copies of IPR disclosures made to the IETF Secretariat and any 957 assurances of licenses to be made available, or the result of an 958 attempt made to obtain a general license or permission for the use of 959 such proprietary rights by implementers or users of this 960 specification can be obtained from the IETF on-line IPR repository at 961 http://www.ietf.org/ipr. 963 The IETF invites any interested party to bring to its attention any 964 copyrights, patents or patent applications, or other proprietary 965 rights that may cover technology that may be required to implement 966 this standard. Please address the information to the IETF at 967 ietf-ipr@ietf.org. 969 Disclaimer of Validity 971 This document and the information contained herein are provided on 972 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 973 REPRESENTS OR IS SPONSORED BY (IF ANY), THE IETF TRUST AND THE 974 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 975 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 976 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 977 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 979 Copyright Statement 981 Copyright (C) The IETF Trust (2007). This document is subject to 982 the rights, licenses and restrictions contained in BCP 78, and 983 except as set forth therein, the authors retain all their rights. 985 Acknowledgment 987 Funding for the RFC Editor function is currently provided by the 988 Internet Society.