idnits 2.17.1 draft-ietf-mip4-nemo-v4-base-04.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 961. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 968. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 974. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1, updated by RFC 4748 (on line 990), 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 5, 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 10, 2008 Cisco Systems 4 V. Narayanan 5 Qualcomm, Inc. 6 A. Petrescu 7 Motorola 8 October 5, 2007 10 Network Mobility (NEMO) Extensions for Mobile IPv4 11 draft-ietf-mip4-nemo-v4-base-04.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 10, 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 120 Router's Home Address and the Home Agent. This tunnel is 121 encapsulated within the normal tunnel between the Care-of Address 122 (CoA) and Home Agent. In Foreign Agent CoA mode, the tunnel 123 between the Mobile Router and Home Agent is needed to allow the 124 Foreign Agent to direct the decapsulated packet to the proper 125 visiting Mobile Router. However, in Collocated CoA mode, the 126 additional tunnel is not essential and could be eliminated because 127 the Mobile Router is the recipient of the encapsulated packets for 128 the Mobile Network; a proposal for this feature is in [1]. 130 All traffic between the nodes in the Mobile Network and Correspondent 131 Nodes passes through the Home Agent. This document does not cover 132 route optimization of this traffic. 134 A similar protocol has been documented in [RFC3963] for supporting 135 IPv6 mobile networks with Mobile IPv6 extensions. 137 Multihoming for Mobile Routers is outside the scope of this 138 document. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 Terminology for network mobility support is defined in [RFC3344] 147 and its update [2]. In addition, this document defines the 148 following terms. 150 Mobile Network Prefix 152 The network prefix of the subnet delegated to a Mobile Router 153 as the Mobile Network. 155 Prefix Table 157 A list of Mobile Network Prefixes indexed by the Home Address 158 of a Mobile Router. The Home Agent manages and uses Prefix 159 Table to determine which Mobile Network Prefixes belong to a 160 particular Mobile Router. 162 3. Requirements 164 Although Mobile IPv4 stated that Mobile Network can be supported by 165 the Mobile Router and Home Agent using static configuration or 166 running a routing protocol, there is no solution for explicit 167 registration of the Mobile Networks served by the Mobile Router. A 168 solution needs to provide the Home Agent a means to ensure that a 169 Mobile Router claiming a certain Mobile Network Prefix is 170 authorized to do so. A solution would also expose the Mobile 171 Network Prefixes (and potentially other subnet-relevant 172 information) in the exchanged messages, to aid in network 173 debugging. 175 The following requirements for Mobile Network support are 176 enumerated: 178 o A Mobile Router should be able to operate in explicit or implicit 179 mode. A Mobile Router may explicitly inform the Home Agent which 180 Mobile Network(s) need to be propagated via routing protocol. A 181 Mobile Router may also function in implicit mode, where the Home 182 Agent may learn the mobile networks through other means, such as 183 from the AAA server, via pre-configuration or via a dynamic 184 routing protocol. 186 o The Mobile Network should be supported using Foreign Agents that 187 are compliant to RFC 3344 without any changes ('legacy' Foreign 188 Agents). 190 o The mobile network should allow Fixed nodes, Mobile Nodes, or 191 Mobile Routers to be on it. 193 4. Mobile Network Extensions 195 4.1. Mobile Network Request Extension 197 For Explicit Mode, the Mobile Router informs the Home Agent about 198 the Mobile Network Prefixes during registration. The Registration 199 Request contains zero, one or several Mobile Network Request 200 extensions in addition to any other extensions defined by or in the 201 context of [RFC3344]. When several Mobile Networks are needed to 202 be registered, each is included in a separate Mobile Network 203 Request extension, with its own Type, Length, Sub-Type, Prefix 204 Length and Prefix fields. A Mobile Network Request extension is 205 encoded in Type-Length-Value (TLV) format and respects the 206 following format: 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length | Sub-Type | Prefix Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Prefix | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Type: 218 Mobile Network Extension (skippable type range to be assigned 219 by IANA) 221 Length: 223 6 225 Sub-Type: 227 1 (Mobile Network Request) 229 Prefix Length: 231 8-bit unsigned integer indicating the number of bits covering 232 the network part of the address contained in the Prefix field. 234 Prefix: 236 32-bit unsigned integer in network byte-order containing an 237 IPv4 address whose first Prefix Length bits make up the Mobile 238 Network Prefix. 240 4.2. Mobile Network Acknowledgement Extension 242 The Registration Reply contains zero, one or several Mobile Network 243 Acknowledgement extensions in addition to any other extensions 244 defined by or in the context of [RFC3344] and its update [2]. 245 For Implicit Mode, the Mobile Network Acknowledgement informs the 246 Mobile Router the prefixes for which the Home Agent sets up 247 forwarding with respect to this Mobile Router. Policies such as 248 permitting only traffic from these Mobile Networks to be tunneled 249 to the Home Agent may be applied by the Mobile Router. For 250 Explicit Mode, when several Mobile Networks are needed to be 251 acknowledged explicitly, each is included in a separate Mobile 252 Network Acknowledgement extension, with its own Type, Sub-Type, 253 Length and Prefix Length fields. Optionally, all requested Mobile 254 Networks could be acknowledged using only one Mobile Network 255 Acknowledgement extension with "Prefix Length" and "Prefix" fields 256 set to zero. At least one Mobile Network Acknowledgement extension 257 MUST be in a successful Registration Reply to indicate to the 258 Mobile Router that the Mobile Network Request extension was 259 processed, thereby not skipped by the Home Agent. 261 A Registration Reply may contain any non-zero number of Explicit 262 Mode and Implicit Mode Acknowledgements sub-types. Both sub-types 263 can be present in a single Registration Reply. A Mobile Network 264 Acknowledgement extension is encoded in Type-Length-Value (TLV) 265 format. When the registration is denied with code HA_MOBNET_ERROR, 266 the Code field in the extension provides the reason for the 267 failure. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Type | Length | Sub-Type | Code | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Prefix Length | Reserved | Prefix 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Type: 281 Mobile Network Extension (skippable type range to be assigned 282 by IANA) 284 Length: 286 8 288 Sub-Type: 290 TBA (Explicit Mode Acknowledgement) 292 TBA (Implicit Mode Acknowledgement) 294 Code: 296 Value indicating success or failure. 298 0 Success 300 TBA Invalid prefix (MOBNET_INVALID_PREFIX_LEN) 302 TBA Mobile Router is not authorized for prefix 303 (MOBNET_UNAUTHORIZED) 305 TBA Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) 307 Prefix Length: 309 8-bit unsigned integer indicating the number of bits covering 310 the network part of the address contained in the Prefix field. 312 Reserved: 314 Sent as zero; ignored on reception. 316 Prefix: 318 32-bit unsigned integer in network byte-order containing an 319 IPv4 address whose first Prefix Length bits make up the Mobile 320 Network Prefix. 322 5. Mobile Router Operation 324 A Mobile Router's operation is generally derived from the behavior 325 of a Mobile Node, as set in [RFC3344] and its update [2]. In 326 addition to maintaining mobility bindings for its Home Address, the 327 Mobile Router, together with the Home Agent, maintains forwarding 328 information for the Mobile Network Prefix(es) assigned to the 329 Mobile Router. 331 A Mobile Router SHOULD set the 'T' bit to 1 in all Registration 332 Request messages it sends to indicate the need for reverse tunnels 333 for all traffic. Without reverse tunnels, all the traffic from the 334 mobile network will be subject to ingress filtering in the visited 335 networks. Upon reception of successful registration reply, the 336 Mobile Router processes the registration in accordance to RFC 3344. 337 In addition, the following steps are taken: 339 o Check for Mobile Network Acknowledgement extension(s) in 340 Registration Reply 342 o Create tunnel to the Home Agent if registered in reverse tunneling 343 mode 345 o Set up default route via this tunnel or egress interface when 346 registered with or without reverse tunneling, respectively 348 In accordance with this specification, a Mobile Router may operate in 349 one of the following two modes: explicit and implicit. In explicit 350 mode, the Mobile Router includes Mobile Network Prefix information in 351 all Registration Requests (as Mobile Network Request extensions), 352 while in implicit mode it does not include this information in any 353 Registration Request. In this latter case, the Home Agent obtains 354 the Mobile Network Prefixes by other means than Mobile IP. One 355 example of obtention of the Mobile Network Prefix is through static 356 configuration on the Home Agent. 358 A Mobile Router can obtain a Collocated or Foreign Agent Care-of- 359 Address while operating in explicit or implicit modes. 361 For de-registration, the Mobile Router sends a registration request 362 with lifetime set to zero without any Mobile Network Request 363 extensions. 365 5.1. Error Processing 367 A Mobile Router interprets the values of the Code field in Mobile 368 Network Acknowledgement Extension of the Registration Reply in order 369 to identify any error related to managing the Mobile Network Prefixes 370 by the Home Agent. 372 If the value of the Code field in the Registration Reply is set to 373 HA_MOBNET_DISALLOWED, then the Mobile Router MUST stop sending 374 Registration Requests with any Mobile Network Prefix extensions to 375 that Home Agent. 377 If the value of the Code field in the Registration Reply is set to 378 HA_MOBNET_ERROR then the Mobile Router MUST stop sending Registration 379 Requests that contain any of the Mobile Network Prefixes that are 380 defined by the values of the fields Prefix and Prefix Length in the 381 Mobile Network Acknowledgement extension. Note that the registration 382 is denied in this case and no forwarding for any Mobile Network 383 Prefixes would be set up by the Home Agent for the Mobile Router. 385 It is possible that the Mobile Router receives a registration reply 386 with no mobile network extensions if the registration was processed 387 by a Mobile IPv4 home agent that does not support this specification 388 at all. In that case, the absence of mobile network extensions must 389 be interpreted by the Mobile Router as the case where the Home Agent 390 does not support mobile networks. 392 All the error code values are TBA (To Be Assigned) subject to IANA 393 allocation. 395 6. Home Agent Operation 397 6.1. Summary 399 A Home Agent MUST support all the operations specified in [RFC3344] 400 and its update [2] for mobile node support. The Home Agent MUST 401 support both implicit and explicit modes of operation for a Mobile 402 Router. 404 The Home Agent processes the registration in accordance to RFC 3344, 405 which includes route set up to the Mobile Router's home address via 406 the tunnel to the Care-of Address. In addition, for a Mobile Router 407 registering in explicit mode, the following steps are taken: 409 1. Check that the Mobile Network Prefix information is valid 411 2. Ensure the Mobile Network Prefix(es) is or are authorized to be 412 on the Mobile Router 414 3. Create tunnel to the Mobile Router if it does not already exist 416 4. Set up route for the Mobile Network Prefix via this tunnel 418 5. Propagate Mobile Network Prefix routes via routing protocol 420 6. Send the Registration Reply with the Mobile Network 421 Acknowledgement extension(s) 423 If there are any subnet routes via the tunnel to the Mobile Router 424 that are not specified in the Mobile Network extensions, these routes 425 are removed. 427 In the case where the Mobile Node is not permitted to act as a Mobile 428 Router, the Home Agent sends a registration denied message with error 429 code HA_MOBNET_DISALLOWED. 431 For a Mobile Router registering in implicit mode, the Home Agent 432 performs steps 3-6 above, once the registration request is processed 433 successfully. 435 For deregistration, the Home Agent removes the tunnel to the Mobile 436 Router and all routes using this tunnel. The Mobile Network 437 extensions are ignored. 439 6.2. Data Structures 441 6.2.1. Registration Table 443 The Registration Table in the Home Agent, in accordance with 444 [RFC3344] and its update [2], contains binding information for 445 every Mobile Node registered with it. [RFC3344] and its update [2] 446 define the format of Registration Table. In addition to all the 447 parameters specified by [RFC3344] and its update [2], the Home 448 Agent MUST store the Mobile Network Prefixes associated with the 449 Mobile Router in the corresponding registration entry, when the 450 corresponding registration was performed in explicit mode. When 451 the Home Agent is advertising reachability to Mobile Network 452 Prefixes served by a Mobile Router, this information stored in the 453 Registration Table can be used. 455 6.2.2. Prefix Table 457 The Home Agent must be able to authorize a Mobile Router for use of 458 Mobile Network Prefixes when the Mobile Router is operating in 459 explicit mode. Also, when the Mobile Router operates in implicit 460 mode, the Home Agent must be able to locate the Mobile Network 461 Prefixes associated with that Mobile Router. The Home Agent may 462 store the home address of the Mobile Router along with the mobile 463 network prefixes associated with that Mobile Router. If the Mobile 464 Router does not have a home address assigned, this table may store 465 the NAI [RFC2794] of the Mobile Router that will be used in dynamic 466 home address assignment. 468 6.3. Mobile Network Prefix Registration 470 The Home Agent must process registration requests coming from 471 Mobile Routers in accordance with this section. The document 472 [RFC3344] and its update [2] specify that the home address of a 473 mobile node registering with a Home Agent must belong to a prefix 474 advertised on the home network. In accordance with this 475 specification, however, the home address must be configured from a 476 prefix that is served by the Home Agent, not necessarily the one on 477 the home network. 479 If the registration request is valid, the Home Agent checks to see 480 if there are any Mobile Network Prefix extensions included in the 481 Registration Request. 483 If so, the Mobile Network Prefix information is obtained from the 484 included extensions, and the Home Address from the Home Address 485 field of the UDP header Registration Request. For every Mobile 486 Network Prefix extension included in the registration request, the 487 Home Agent MUST perform a check against the Prefix Table. If the 488 Prefix Table does not contain at least one entry pairing that Home 489 Address to that Mobile Network Prefix then the check fails, 490 otherwise it succeeds. 492 Following this check against the Prefix Table, the Home Agent MUST 493 construct a Registration Reply containing Mobile Network 494 Acknowledgement extensions. For a Mobile Network Prefix for which 495 the check was unsuccessfull the Code field in the corresponding 496 Mobile Network Acknowledgement extension should be set to 497 MOBNET_UNAUTHORIZED. 499 For a Mobile Network Prefix for which the check was successfull the 500 Code field in the respective Mobile Network Acknowledgement 501 extensions should be set to 0. 503 The Home Agent MUST attempt to set up forwarding for each Mobile 504 Network Prefix extension for which the Prefix Table check was 505 successfull. If the forwarding setup fails for a particular Mobile 506 Network Prefix (for reasons like not enough memory available, or 507 not enough devices available, or other similar) the Code field in 508 the respective Mobile Network Acknowledgement extension should be 509 set to MOBNET_FWDING_SETUP_FAILED. 511 If forwarding and setup was successful for at least one Mobile 512 Network Prefix then the Code field of the Registration Reply 513 message should be set to 0. Otherwise that Code should be 514 HA_MOBNET_ERROR. 516 If the registration request is sent in implicit mode, i.e., without 517 any Mobile Network Request extension, the Home Agent may use pre- 518 configured mobile network prefix information for the Mobile Router to 519 set up forwarding. 521 If the Home Agent is updating an existing binding entry for the 522 Mobile Router, it MUST check all the prefixes in the registration 523 table against the prefixes included in the registration request. 524 If one or more mobile network prefix is missing from the included 525 information in the registration request, it MUST delete those 526 prefixes from the registration table. Also, the Home Agent MUST 527 disable forwarding for those prefixes. 529 If all checks are successful, the Home Agent either creates a new 530 entry for the Mobile Router or updates an existing binding entry 531 for it and returns a successful registration reply back to the 532 Mobile Router or the Foreign Agent (if the registration request was 533 received from a Foreign Agent). 535 In accordance with [RFC3344], the Home Agent does proxy ARP for the 536 Mobile Router home address, when the Mobile Router home address is 537 derived from the home network. 539 If the 'T' bit is set, the Home Agent creates a bi-directional 540 tunnel for the corresponding mobile network prefixes or updates the 541 existing bi-directional tunnel. This tunnel is maintained 542 independent of the reverse tunnel for the Mobile Router home 543 address itself. 545 6.4. Advertising Mobile Network Reachability 547 If the mobile network prefixes served by the Home Agent are 548 aggregated with the home network prefix and if the Home Agent is 549 the default router on the home network, the Home Agent does not 550 have to advertise the Mobile Network Prefixes. The routes for the 551 Mobile Network Prefix are automatically aggregated into the home 552 network prefix (it is assumed that the Mobile Network Prefixes are 553 automatically aggregated into the home network prefix). If the 554 Mobile Router updates the mobile network prefix routes via a 555 dynamic routing protocol, the Home Agent SHOULD propagate the 556 routes on the appropriate networks. 558 6.5. Establishment of Bi-directional Tunnel 560 The Home Agent creates and maintains a bi-directional tunnel for the 561 mobile network prefixes of a Mobile Router registered with it. A 562 home agent supporting IPv4 Mobile Router operation MUST be able to 563 forward packets destined to the mobile network prefixes served by the 564 mobile router to its care-of-address. Also, the Home Agent MUST be 565 able to accept packets tunneled by the Mobile Router with the source 566 address of the outer header is set to the care-of-address of the 567 mobile router and that of the inner header is set to the Mobile 568 Router's home address or an address from one of the registered mobile 569 network prefixes. 571 6.6. Sending Registration Replies 573 The Home Agents MUST set the status code in the registration reply to 574 0 to indicate successful processing of the registration request and 575 successful set up of forwarding for all the mobile network prefixes 576 served by the Mobile Router. The registration reply MUST contain at 577 least one Mobile Network Acknowledgement extension. 579 If the Home Agent is unable to set up forwarding for one of more 580 mobile network prefixes served by the Mobile Router, it MUST set the 581 Mobile Network Acknowledgement Extension status code in the 582 registration reply to MOBNET_FWDING_SETUP_FAILED. When the prefix 583 length is zero or greater than 32, the status code MUST be set to 584 MOBNET_INVALID_PREFIX_LEN. 586 If the Mobile Router is not authorized to forward packets to one or 587 mobile network prefixes included in the request, the Home Agent MUST 588 set the code to MOBNET_UNAUTHORIZED_MR. 590 6.7. Mobile Network Prefix De-registration 592 If the received registration request is for de-registration of the 593 care-of-address, the Home Agent, upon successful processing of it, 594 MUST delete the entry(ies) from its registration table. The home 595 agent tears down the bi-directional tunnel and stops forwarding any 596 packets to/from the Mobile Router. The Home Agent MUST ignore any 597 included Mobile Network Request extension in a de-registration 598 request. 600 7. Data Forwarding Operation 602 For traffic to the nodes in the Mobile Network, the Home Agent MUST 603 perform double tunneling of the packet, if the Mobile Router had 604 registered with a Foreign Agent care-of-address. In this case, the 605 Home Agent MUST encapsulate the packet with tunnel header (source IP 606 address set to Home Agent and destination IP address set to Mobile 607 Router's home address) and then encapsulate one more time with tunnel 608 header (source IP address set to Home Agent and destination IP 609 address set to CoA). 611 For optimization, the Home Agent SHOULD only encapsulate the packet 612 with the tunnel header (source IP address set to Home Agent and 613 destination IP address set to CoA) for Collocated CoA mode. 615 When a Home Agent receives a packet from the mobile network prefix in 616 the bi-directional tunnel, it MUST de-encapsulate the packet and 617 route it as a normal IP packet. It MUST verify that the incoming 618 packet has the source IP address set to the care-of-address of the 619 Mobile Router. The packet MUST be dropped if the source address is 620 not set to the care-of-address of the Mobile Router. 622 For traffic from the nodes in the Mobile Network, the Mobile Router 623 encapsulates the packet with tunnel header (source IP address set to 624 Mobile Router's home address and destination IP address set to Home 625 Agent) if reverse tunnel is enabled. Otherwise, the packet is routed 626 directly to the Foreign Agent or access router. 628 In Collocated CoA mode, the Mobile Router MAY encapsulate one more 629 times with tunnel header (source IP address set to the CoA and 630 destination IP address set to Home Agent). 632 8. Nested Mobile Networks 634 Nested Network Mobility is a scenario where a Mobile Router allows 635 another Mobile Router to attach to its Mobile Network. There could 636 be arbitrary levels of nested mobility. The operation of each Mobile 637 Router remains the same whether the Mobile Router attaches to another 638 Mobile Router or to a fixed Access Router on the Internet. The 639 solution described here does not place any restriction on the number 640 of levels for nested mobility. But note that this might introduce 641 significant overhead on the data packets as each level of nesting 642 introduces another tunnel header encapsulation. 644 9. Routing Protocol between Mobile Router and Home Agent 646 There are several benefits of running a dynamic routing protocol 647 between the Mobile Router and the Home Agent. If the mobile 648 network is relatively large, including several wireless subnets, 649 then the topology changes within the moving network can be exposed 650 from the Mobile Router to the Home Agent by using a dynamic routing 651 protocol. The purpose of the NEMOv4 protocol extensions to Mobile 652 IPv4, as defined in previous sections, is not to inform the Home 653 Agent about these topology changes, but to manage the mobility of 654 the Mobile Router. 656 Similarly, topology changes in the home network can be exposed to 657 the Mobile Router by using a dynamic routing protocol. This may be 658 necessary when new fixed networks are added in the home network. 659 Here too, the purpose of NEMOv4 extensions is not to inform the 660 Mobile Router about topology changes at home. 662 Examples of dynamic routing protocol include but are not limited to 663 OSPF Version 2 [RFC2328], BGP [RFC4271] and RIP [RFC2453]. 665 The recommendations are related to how the routing protocol and the 666 Mobile IPv4 implementation work in tandem on the Mobile Router and 667 on the Home Agent (1) without creating incoherent states in the 668 forwarding information bases at home and on the Mobile Router (2) 669 without introducing topologically incorrect addressing information 670 in the visited domain and (3) efficiently avoid duplication of sent 671 data or over-provisioning of security. 673 The information exchanged between the Mobile Router and the Home 674 Agent is sent over the bi-directional tunnel established by the 675 Mobile IPv4 exchange Registration Request - Registration Reply (see 676 section 6.5). If a network address and prefix about a subnet in 677 the moving network is sent by the Mobile Router within a routing 678 protocol message then they SHOULD NOT be sent in the Mobile IPv4 679 Registration Request too, in order to avoid incoherencies in the 680 forwarding information bases. The Mobile Router SHOULD use NEMOv4 681 implicit mode in this case (see section 3). 683 The Mobile Router SHOULD NOT send routing protocol information 684 updates in the foreign network. The subnet addresses and prefixes 685 valid in the moving network are topologically incorrect in the 686 visited network. 688 If the Mobile Router and the Home Agent use a dynamic routing 689 protocol over the tunnel interface, and if that protocol offers 690 security mechanisms to protect that protocol's messages, then the 691 security recommendations in section 10.1 apply. 693 10. Security Considerations 695 The Mobile Network extension is protected by the same rules for 696 Mobile IP extensions in registration messages. See the Security 697 Considerations section in RFC 3344. 699 The Home Agent MUST be able to verify that the Mobile Router is 700 authorized to provide mobility service for the Mobile Networks in 701 the registration request, before anchoring these Mobile Network 702 Prefixes on behalf of the Mobile Router. Forwarding for prefixes 703 MUST NOT be set up without successful authorization of the Mobile 704 Router for those prefixes. A registration failure MUST be notified 705 to the mobile router when it cannot be successfully authorized for 706 prefixes requested by it. 708 All registration requests and replies MUST be authenticated by the 709 MN-HA Authentication Extension as specified in [RFC3344] and its 710 update [2]. When the registration request is sent in explicit 711 mode, i.e., with one or more Mobile Network Prefix extensions, all 712 the Mobile Network Prefix extensions MUST be included before the 713 MN-HA Authentication extension. Also, these extensions MUST be 714 included in the calculation of the MN-HA authenticator value. 716 The Mobile Router should perform ingress filtering on all the packets 717 received on the mobile network prior to reverse tunneling them to the 718 Home Agent. The Mobile Router MUST drop any packets that do not have 719 a source address belonging to the mobile network. 721 The Mobile Router MUST also ensure that the source address of 722 packets arriving on the mobile network is not the same as the 723 Mobile Router's IP address on any interface. These checks will 724 protect against nodes attempting to launch IP spoofing attacks 725 through the bi-directional tunnel. 727 The Home Agent, upon receiving packets through the bi-directional 728 tunnel, MUST verify that the source addresses of the outer IP header 729 of the packets are set to the Mobile Router's care-of-address. Also, 730 it MUST ensure that the source address of the inner IP header is a 731 topologically correct address on the mobile network. This will 732 prevent nodes from using the Home Agent to launch attacks inside the 733 protected network. 735 10.1 Security when Dynamic Routing Protocol is Used 737 If a dynamic routing protocol is used between the Mobile Router and 738 the Home Agent to propagate the mobile network information into the 739 home network, the routing updates SHOULD be protected with IPsec ESP 740 confidentiality between the Mobile Router and Home Agent, to prevent 741 information about home network topology from being visible to 742 eavesdroppers. 744 A routing protocol message protected with ESP, and sent through the 745 Mobile Router - Home Agent bidirectional tunnel, SHOULD NOT contain 746 the Mobile IPv4 Mobile-Home Authentication Extension, since ESP 747 provides enough security. 749 11. IANA Considerations 751 IANA to modify rules for the existing registry "Mobile IPv4 numbers - 752 per RFC 3344". The numbering space for Extensions that may appear in 753 Mobile IP control messages (those sent to and from UDP port number 754 434) should be modified. 756 The new Values and Names for the Type for Extensions appearing in 757 Mobile IP control messages are the following: 759 Value Name 760 ----- ------------------------------------------ 761 TBA Mobile Network Extension (To Be Assigned by IANA) 763 The new Values and Names for the Sub-Type for Mobile Network 764 Extension are the following: 766 Value Name 767 ----- ------------------------------------------ 768 TBA Mobile Network Request Extension 769 TBA Explicit Mode Acknowledgement Extension 770 TBA Implicit Mode Acknowledgement Extension 772 The new Code values for Mobile IP Registration Reply messages are 773 the following: 775 Code Values for Mobile IP Registration Reply messages 776 ----------------------------------------------------- 778 Registration denied by the Home Agent: (To Be Assigned by IANA) 780 TBA Mobile Network Prefix operation error (HA_MOBNET_ERROR) 781 TBA Mobile Router operation is not permitted 782 (HA_MOBNET_DISALLOWED) 784 The new Code Values for Mobile IP Registration Reply messages are the 785 following: 787 Code Values for Mobile Network Acknowledgement Extension 788 -------------------------------------------------------- 790 Registration denied by the Home Agent: 792 TBA Invalid prefix length (MOBNET_INVALID_PREFIX_LEN) 793 TBA Mobile Router is not authorized for prefix 794 (MOBNET_UNAUTHORIZED) 795 TBA Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) 797 The current non-modified numbering spaces could be consulted at the 798 following URL: http://www.iana.org/assignments/mobileip-numbers 799 (contents last updated 2007-07-02 and last browsed 2007-10-04, 800 October). 802 12. Acknowledgements 804 The authors would like to thank Christophe Janneteau, George 805 Popovich, Ty Bekiares, Ganesh Srinivasan, Alpesh Patel, Ryuji 806 Wakikawa, George Tsirtsis, and Henrik Levkowetz for their helpful 807 discussions, reviews and comments. Vijay Devarapalli extensively 808 reviewed one of the later versions of the draft. 810 13. References 812 13.1. Normative References 814 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 815 Requirement Levels", BCP 14, RFC 2119, March 1997. 817 [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access 818 Identifier Extension for IPv4", RFC 2794, March 2000. 820 [RFC2453] Malkin, G., "RIP Version 2", RFC 2453, STD 56, November 821 1998. 823 [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, STD 54, April 824 1998. 826 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 827 August 2002. 829 [RFC4271] Rekhter, Y, Ed., Li, T. and S. Hares, "A Border Gateway 830 Protocol (BGP-4)", RFC 4271, January 2006. 832 13.2. Informative References 834 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 835 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 836 RFC 3963, January 2005. 838 [1] Tsirtsis, G., Park, V., Narayanan, V., and K. Leung, "FA 839 extensions to NEMOv4 Base", 840 draft-ietf-mip4-nemov4-fa-01.txt, IETF Internet-Draft, 841 Work in Progress, March 19, 2007. 843 [2] Perkins, C., Ed., "IP Mobility Support for IPv4, 844 revised", draft-ietf-mip4-rfc3344bis-05.txt, IETF 845 Internet-Draft, Work in Progress, July 9, 2007. 847 14. Changelog 849 The changes are listed in reverse chronological order, most recent 850 changes appearing at the top of the list: 852 From draft-ietf-mip4-nemo-v4-base-03.txt to 853 draft-ietf-mip4-nemo-v4-base-04.txt 854 -more changes in Introduction to say that with FA mode only the 855 non-optimized double-encapsulation operation is supported and 856 [1] proposes optimization. 858 From draft-ietf-mip4-nemo-v4-base-02.txt to 859 draft-ietf-mip4-nemo-v4-base-03.txt 860 -changed a sentence in the introduction to say that FA mode _is_ 861 supported but unoptimized, and that a reference [1] optimizes 862 that mode. 863 -added reference [2] to the rfc3344bis draft. 865 From draft-ietf-mip4-nemo-v4-base-01.txt to 866 draft-ietf-mip4-nemo-v4-base-02.txt 867 -changed title from "IPv4 Network Mobility (NEMO) Protocol" to 868 "Network Mobility (NEMO) Extensions for Mobile IPv4" 870 From draft-ietf-mip4-nemo-v4-base-00.txt to 871 draft-ietf-mip4-nemo-v4-base-01.txt 872 -added a section on Routing Protocol between Mobile Router and 873 Home Agent. 874 -added a security subsection about running simultaneously a 875 secure routing protocol with secure Mobile IPv4. 876 -added a date tag on the IANA URL for Mobile IP numbering 877 spaces. 878 -substituted 'Mobile Router' for 'MR' everywhere. 879 -updated reference to NEMOv4 FA draft. 881 From draft-ietf-nemo-v4-base-01.txt to 882 draft-ietf-mip4-nemo-v4-base-00.txt: 883 -changed draft name, headers and footers. 884 -changed title. 885 -a more coherent use of terms 'subnet', 'prefix' and 'mobile 886 network'. 887 -clarified only co-located CoA mode is supported (not FA CoA). 888 for Mobile Routers in this specification. And added reference 889 to the FA NEMO optimizations draft. 890 -changed 'devices' to 'hosts'. 891 -changed 'moving networks' to 'mobile networks'. 892 -clarified what 'reachability' in a certain context is: packets 893 may be dropped if ingress filtering is turned on. 894 -removed the MR-FA-CoA tunnel overhead optimization. There is 895 still an issue with text at HA doing optimization. 897 This document was first presented as an individual contribution to 898 the NEMO Working Group, then adopted as a WG item to that group. 899 The 01 version in the NEMO WG has been Last Called on the 900 INFORMATIONAL track. The evolution was: 902 From version draft-ietf-nemo-v4-base-00 to 903 draft-ietf-nemo-v4-base-01: 904 -removed error code HA_MOBNET_UNSUPPORTED. 905 -changed all values to be assigned by IANA, from specific 906 numbers to "TBA" (To Be Assigned). 907 -substituted "egress interface" for "roaming interface". 908 -changed HA behaviour upon reception of MNPs. In 00 the HA 909 replied positively only if all MNPs in RegReq were valid, in 01 910 a reply is constructed specifying which MNP was valid and which 911 not. 912 -clarified a 3-line paragraph saying that RegRep may contain 913 both implicit and explicit acknowledgements. 915 Authors' Addresses 917 Kent Leung 918 Cisco Systems 919 170 W. Tasman Drive 920 San Jose, CA 95134 921 US 923 Phone: +1 408-526-5030 924 Email: kleung@cisco.com 926 Gopal Dommety 927 Cisco Systems 928 170 W. Tasman Drive 929 San Jose, CA 95134 930 US 932 Phone: +1 408-525-1404 933 Email: gdommety@cisco.com 935 Vidya Narayanan 936 QUALCOMM, Inc. 937 5775 Morehouse Dr 938 San Diego, CA 939 USA 941 Phone: +1 858-845-2483 942 Email: vidyan@qualcomm.com 944 Alexandru Petrescu 945 Motorola 946 Parc les Algorithmes Saint Aubin 947 Gif-sur-Yvette 91193 948 France 950 Email: Alexandru.Petrescu@motorola.com 952 Intellectual Property Statement 954 The IETF takes no position regarding the validity or scope of any 955 Intellectual Property Rights or other rights that might be claimed to 956 pertain to the implementation or use of the technology described in 957 this document or the extent to which any license under such rights 958 might or might not be available; nor does it represent that it has 959 made any independent effort to identify any such rights. Information 960 on the procedures with respect to rights in RFC documents can be 961 found in BCP 78 and BCP 79. 963 Copies of IPR disclosures made to the IETF Secretariat and any 964 assurances of licenses to be made available, or the result of an 965 attempt made to obtain a general license or permission for the use of 966 such proprietary rights by implementers or users of this 967 specification can be obtained from the IETF on-line IPR repository at 968 http://www.ietf.org/ipr. 970 The IETF invites any interested party to bring to its attention any 971 copyrights, patents or patent applications, or other proprietary 972 rights that may cover technology that may be required to implement 973 this standard. Please address the information to the IETF at 974 ietf-ipr@ietf.org. 976 Disclaimer of Validity 978 This document and the information contained herein are provided on 979 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 980 REPRESENTS OR IS SPONSORED BY (IF ANY), THE IETF TRUST AND THE 981 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 982 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 983 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 984 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 986 Copyright Statement 988 Copyright (C) The IETF Trust (2007). This document is subject to 989 the rights, licenses and restrictions contained in BCP 78, and 990 except as set forth therein, the authors retain all their rights. 992 Acknowledgment 994 Funding for the RFC Editor function is currently provided by the 995 Internet Society.