idnits 2.17.1 draft-ietf-mip4-nemo-v4-base-10.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1430. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == 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 (February 18, 2008) is 5883 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 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) == Outdated reference: A later version (-03) exists of draft-ietf-mip4-nemov4-fa-02 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 K. Leung 3 Internet-Draft G. Dommety 4 Intended status: Standards Track Cisco Systems 5 Expires: August 21, 2008 V. Narayanan 6 Qualcomm, Inc. 7 A. Petrescu 8 Motorola 9 February 18, 2008 11 Network Mobility (NEMO) Extensions for Mobile IPv4 12 draft-ietf-mip4-nemo-v4-base-10.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 21, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document describes a protocol for supporting Mobile Networks 46 between a Mobile Router and a Home Agent by extending the Mobile IPv4 47 protocol. A Mobile Router is responsible for the mobility of one or 48 more network segments or subnets moving together. The Mobile Router 49 hides its mobility from the nodes on the mobile network. The nodes 50 on the Mobile Network may be fixed in relationship to the Mobile 51 Router and may not have any mobility function. 53 Extensions to Mobile IPv4 are introduced to support Mobile Networks. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Examples of Mobile Networks . . . . . . . . . . . . . . . 3 59 1.2. Overview of Protocol . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4. Mobile Network Extensions . . . . . . . . . . . . . . . . . . 8 63 4.1. Representing a Subnet . . . . . . . . . . . . . . . . . . 8 64 4.2. Mobile Network Request Extension . . . . . . . . . . . . . 9 65 4.3. Mobile Network Acknowledgement Extension . . . . . . . . . 10 66 5. Mobile Router Operation . . . . . . . . . . . . . . . . . . . 13 67 5.1. Error Processing . . . . . . . . . . . . . . . . . . . . . 14 68 5.2. Mobile Router Management . . . . . . . . . . . . . . . . . 14 69 6. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 15 70 6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 6.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 16 72 6.2.1. Registration Table . . . . . . . . . . . . . . . . . . 16 73 6.2.2. Prefix Table . . . . . . . . . . . . . . . . . . . . . 16 74 6.3. Mobile Network Prefix Registration . . . . . . . . . . . . 16 75 6.4. Advertising Mobile Network Reachability . . . . . . . . . 18 76 6.5. Establishment of Bi-directional Tunnel . . . . . . . . . . 18 77 6.6. Sending Registration Replies . . . . . . . . . . . . . . . 18 78 6.7. Mobile Network Prefix De-registration . . . . . . . . . . 19 79 7. Data Forwarding Operation . . . . . . . . . . . . . . . . . . 19 80 8. Nested Mobile Networks . . . . . . . . . . . . . . . . . . . . 20 81 9. Routing Protocol between Mobile Router and Home Agent . . . . 20 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 83 10.1. Security when Dynamic Routing Protocol is Used . . . . . . 22 84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 85 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 86 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 13.1. Normative References . . . . . . . . . . . . . . . . . . . 25 88 13.2. Informative References . . . . . . . . . . . . . . . . . . 26 89 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 26 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 91 Intellectual Property and Copyright Statements . . . . . . . . . . 32 93 1. Introduction 95 This document describes network mobility extensions to the Mobile 96 IPv4 protocol. The goal of introducing these extensions is to 97 acommodate mobility scenarios where groups of hosts and routers move 98 homogeneously (as a whole). It is required that all hosts and 99 routers in a mobile network be able to run applications connecting to 100 the Internet, and to be reachable from the Internet. 102 For details regarding terminology related to network mobility (NEMO), 103 the gentle reader is suggested a quick read of RFC 4885 [RFC4885]. 105 1.1. Examples of Mobile Networks 107 A mobile network links together a set of hosts and routers. 108 Connecting this mobile network to the Internet is ensured at two 109 levels: first, a Mobile Router is connected on one side to the Mobile 110 Network and on another side to a wireless access system; second, a 111 Home Agent placed on the home link manages traffic between the 112 Correspondent Node and a Local Fixed Node (LFN, a node in the mobile 113 network) by means of encapsulating traffic. 115 A scenario of applicability for this mobile network is described 116 next. A mobile network is formed by a wireless-enabled Personal 117 Digital Assistant (PDA) and a portable photographic camera, linked 118 together by Bluetooth wireless link-layer technology. This is 119 sometimes referred to as a Personal Area Network (PAN). In the 120 illustration below one can notice the PDA playing the role of a 121 Mobile Router and the camera the role of Local Fixed Node: 123 ---- 124 | HA | 125 ---- -------- 126 | / \ ---- 127 -+--------| Internet |---------| CN | 128 \ / ---- 129 -------- 130 / \ 131 / \ 132 / \ 133 ---- ---- 134 | AR | | AR | 135 ---- ---- 136 |cellular |cellular 138 / |cellular 139 | ---- ---- 140 Mobile | | MR | |LFN | ---movement--> 141 Network < ---- ---- 142 | | | 143 | -+-----------+- 144 \ Bluetooth 146 The camera (Local Fixed Node) uploads photographic content to a 147 Correspondent Node (CN) server. When the mobile network moves away, 148 the Mobile Router serving the mobile network changes its point of 149 attachment from one cellular access (Access Router) to another, 150 obtaining a new Care-of Address. The Home Agent (HA) encapsulates 151 application traffic for CN and LFN. 153 Whereas the illustration above is a very simple instantiation of the 154 applicability of Mobile IP-based mobile networks, more complex mobile 155 networks are easily acommodated by the Mobile IPv4 extensions 156 presented in this document (NEMOv4). For example, laptop computers 157 used by passengers in a bus, train, ship or in a plane should all be 158 considered as forming mobile networks, as long as they move together 159 (homogeneously). 161 1.2. Overview of Protocol 163 As introduced previously, this document presents extensions to the 164 Mobile IPv4 protocol. The entities sending and receiving these 165 extensions are the Mobile Router and the Home Agent. The Local Fixed 166 Node is relieved from running Mobile IP software and, although it 167 moves (together with the mobile network), its IP stack is not seing 168 any change in addressing. 170 Mobility for the entire Mobile Network is supported by the Mobile 171 Router registering its current point of attachment (Care-of Address) 172 to its Home Agent: Mobile Router sends an extended Registration 173 Request to Home Agent which returns an extended Registration Reply. 174 This signaling sets up the tunnel between the two entities, as 175 illustrated in the following figure: 177 LFN MR HA CN 178 | | | | 179 | | Extended Registration | | 180 | |---------------------->| | 181 | | Request | | 182 | | | | 183 | | | | 184 | | Extended Registration | | 185 | |<----------------------| | 186 | | Reply | | 187 | | | | 188 |<--------o=======================o-------->| 189 | | Encapsulated | | 190 | | Application Traffic | | 191 | | | | 193 The prefix(es) used within a Mobile Network (either implicitly 194 configured on the Home Agent or explicitly identified by the Mobile 195 Router in the Registration Request) is/are advertised by the Home 196 Agent for route propagation in the home network. Traffic to and from 197 nodes in the Mobile Network are tunelled by the Home Agent to the 198 Mobile Router, and vice versa. Though packets from a Local Fixed 199 Node placed in the Mobile Network can be forwarded by the Mobile 200 Router directly without tunneling (if reverse tunneling were not 201 used) these packets will be dropped if ingress filtering is turned on 202 at the Access Router. 204 Extensively relating to Mobile IPv4 RFC 3344 [RFC3344], this 205 specification addresses mainly the co-located Care-of Address mode. 206 Foreign Agent Care-of Address mode (with 'legacy' Foreign Agents, 207 RFC 3344 [RFC3344]) are supported but without optimization, double 208 encapsulation being used. For an optimization of this mode, the 209 gentle reader is directed to an extension document 210 [I-D.ietf-mip4-nemov4-fa]. 212 Compared to Mobile IPv4, this document specifies an additional tunnel 213 between a Mobile Router's Home Address and the Home Agent. This 214 tunnel is encapsulated within the normal tunnel between the Care-of 215 Address (CoA) and Home Agent. In Foreign Agent CoA mode, the tunnel 216 between the Mobile Router and Home Agent is needed to allow the 217 Foreign Agent to direct the decapsulated packet to the proper 218 visiting Mobile Router. However, in Collocated CoA mode, the 219 additional tunnel is not essential and could be eliminated because 220 the Mobile Router is the recipient of the encapsulated packets for 221 the Mobile Network; a proposal for this feature is in a further 222 extending document [I-D.ietf-mip4-nemov4-fa]. 224 All traffic between the nodes in the Mobile Network and Correspondent 225 Nodes passes through the Home Agent. This document does not touch on 226 aspects related to route optimization of this traffic. 228 A similar protocol has been documented in RFC 3963 [RFC3963] for 229 supporting IPv6 mobile networks with Mobile IPv6 extensions. 231 Multihoming for Mobile Routers is outside the scope of this document. 233 2. Terminology 235 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 236 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 237 document are to be interpreted as described in RFC 2119 [RFC2119]. 239 Terminology for Mobile IPv4 mobility support is defined in RFC 3344 240 [RFC3344]. Terminology for network mobility support (NEMO), from an 241 IPv6 perspective, is described in RFC 4885 [RFC4885]. In addition, 242 this document defines the following terms for NEMOv4. 244 Mobile Router 246 RFC 3344 [RFC3344] defines a Mobile Router as a mobile node 247 that can be a router that is responsible for the mobility of 248 one or more entire networks moving together, perhaps on an 249 airplane, a ship, a train, an automobile, a bicycle, or a 250 kayak. 252 Mobile Network Prefix 254 The network prefix of the subnet delegated to a Mobile Router 255 as the Mobile Network. 257 Prefix Table 259 A list of Mobile Network Prefixes indexed by the Home Address 260 of a Mobile Router. The Home Agent manages and uses Prefix 261 Table to determine which Mobile Network Prefixes belong to a 262 particular Mobile Router. 264 Local Fixed Node 266 RFC 4885 [RFC4885] defines a Local Fixed Node (LFN) to be a 267 fixed node belonging to the mobile network and unable to 268 change its point of attachment. This definition should not 269 be confused with "Long, Fat Network, LFN" of RFC 1323 270 [RFC1323], at least because this latter is pronounced 271 "elephan(t)" whereas a NEMO LFN is distinctively pronounced 272 "elefen". 274 3. Requirements 276 Although the original Mobile IPv4 specifications stated that Mobile 277 Networks can be supported by the Mobile Router and Home Agent using 278 static configuration or running a routing protocol (see Section 4.5 279 of RFC 3344 [RFC3344]), there is no solution for explicit 280 registration of the Mobile Networks served by the Mobile Router. A 281 solution needs to provide the Home Agent a means to ensure that a 282 Mobile Router claiming a certain Mobile Network Prefix is authorized 283 to do so. A solution would also expose the Mobile Network Prefixes 284 (and potentially other subnet-relevant information) in the exchanged 285 messages, to aid in network debugging. 287 The following requirements for Mobile Network support are enumerated: 289 o A Mobile Router should be able to operate in explicit or implicit 290 mode. A Mobile Router may explicitly inform the Home Agent which 291 Mobile Network(s) need to be propagated via a routing protocol. A 292 Mobile Router may also function in implicit mode, where the Home 293 Agent may learn the mobile networks through other means, such as 294 from the AAA server, via pre-configuration, or via a dynamic 295 routing protocol. 297 o The Mobile Network should be supported using Foreign Agents that 298 are compliant to RFC 3344 [RFC3344] without any changes ('legacy' 299 Foreign Agents). 301 o The mobile network should allow Fixed Nodes, Mobile Nodes, or 302 Mobile Routers to be on it. 304 o The Local Fixed Nodes on a mobile network should be able to 305 execute their sessions without running themselves Mobile IP 306 stacks. The Mobile Router managing the LFNs' mobile network is 307 'hiding' mobility events like the changes of the Care-of Address 308 from the Local Fixed Nodes in that mobile network. 310 4. Mobile Network Extensions 312 4.1. Representing a Subnet 314 Since the protocol extensions presented in this document concentrate 315 on treatment of prefixes, subnets and network masks it is important 316 to choose an all-encompassing wire representation of subnets, as 317 generic as possible. 319 A subnet can easily be represented as address/prefix length, as in 320 192.0.2.0/24. This is interpreted as the subnet being the first 321 leftmost 24 bits of the address 192.0.2.0, i.e. 192.0.2. This 322 representation corresponds to an underlying forwarding system which 323 uses longest-prefix match rules. It is typically in widespread 324 deployment in the Internet. 326 In a Mobile Network Extension, this representation is expressed by 327 the tuple of Prefix and Prefix Length fields. 329 On another hand, some forwarding systems don't use longest-prefix 330 match rules. In these cases it is important to provide the more 331 generic way of representing subnets by using non-contiguous sets of 332 1bits as netmasks. For example, 255.255.0.255 is a perfectly legal 333 netmask which, when applied to an address like 192.0.2.1 gives the 334 network part 192.0.x.1, the third 'x' byte acting alone as the host 335 part. 337 In a Mobile Network Extension, this non-contiguous netmask 338 representation is expressed by the tuple of Prefix and Optional 339 Netmask fields (Prefix Length field being ignored). 341 The two representation methods (address/prefix and address/netmask) 342 are alternative and only one method of representation is used by a 343 Mobile Network Extension. 345 Representing the subnet as address/prefix has the advantage of a more 346 compact encoding (40bits) whereas the address/netmask requires 347 64bits. Hence it is suggested as a default. However, representing 348 the subnet as address/netmask gives more applicability of NEMOv4 349 extensions to forwarding systems where more complex forwarding 350 schemes are used. 352 4.2. Mobile Network Request Extension 354 For Explicit Mode, the Mobile Router informs the Home Agent about the 355 Mobile Network Prefixes during registration. The Registration 356 Request contains zero, one or several Mobile Network Request 357 extensions in addition to any other extensions defined by or in the 358 context of RFC 3344 [RFC3344]. When several Mobile Networks are 359 needed to be registered, each is included in a separate Mobile 360 Network Request extension, with its own Type, Length, Sub-Type, 361 Prefix Length, Prefix and optionally the Optional Netmask fields. 362 For a discussion of the subnet encoding see Section 4.1. A Mobile 363 Network Request extension is encoded in Type-Length-Value (TLV) 364 format and respects the following ordering: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Type | Length | Sub-Type | Prefix Length | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Prefix | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Optional Netmask | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Type: 378 Mobile Network Extension (skippable type range to be assigned 379 by IANA). 381 Length: 383 Decimal 6 or decimal 10, not any other. If the masking is 384 expressed as Prefix/Prefix Length (e.g. 192.0.2.1/24), the 385 value of this Length field is decimal 6 and the Optional 386 Netmask field is absent. If the masking is expressed as 387 Prefix and Netmask (e.g. 192.0.2.1 255.255.0.255) then the 388 value of this Length field is decimal 10, the Optional 389 Netmask field is present and the value of the Prefix Length 390 field is set to all-zero by sender and ignored by receiver. 392 Sub-Type: 394 TBA (Mobile Network Request) 396 Prefix Length: 398 8-bit unsigned integer indicating the number of leftmost bits 399 covering the network part of the address contained in the 400 Prefix field. If the Optional Netmask field is present then 401 this field is set to all-zero by sender and ignored by 402 receiver. 404 Prefix: 406 32-bit unsigned integer in network byte-order containing an 407 IPv4 address. If the Optional Netmask field is absent then 408 the first Prefix Length bits make up the Mobile Network 409 Prefix. Otherwise the Mobile Network Prefix is obtained by 410 masking this IPv4 address with the value of the Optional 411 Netmask field. 413 Optional Netmask: 415 32-bit unsigned integer in network byte-order containing an 416 IPv4 netmask. For example '255.255.0.255'. This field is 417 present when the subnet masking needs to be expressed as a 418 non-contiguous set of 1 bits. Otherwise it is absent. If 419 the Optional Netmask is present then the value of the field 420 Prefix Length is set to all-zero by sender and ignored by 421 receiver. 423 4.3. Mobile Network Acknowledgement Extension 425 The Registration Reply contains zero, one or several Mobile Network 426 Acknowledgement extensions in addition to any other extensions 427 defined by or in the context of RFC 3344 [RFC3344]. For Implicit 428 Mode, the Mobile Network Acknowledgement informs the Mobile Router 429 the prefixes for which the Home Agent sets up forwarding with respect 430 to this Mobile Router. Policies such as permitting only traffic from 431 these Mobile Networks to be tunneled to the Home Agent may be applied 432 by the Mobile Router. For Explicit Mode, when several Mobile 433 Networks are needed to be acknowledged explicitly, each is included 434 in a separate Mobile Network Acknowledgement extension, with its own 435 Type, Sub-Type, Length, Prefix, Prefix Length and optionally the 436 Optional Netmask fields. For a discussion of the subnet encoding see 437 Section 4.1. At least one Mobile Network Acknowledgement extension 438 MUST be in a successful Registration Reply to indicate to the Mobile 439 Router that the Mobile Network Request extension was processed, 440 thereby not skipped by the Home Agent. 442 A Registration Reply may contain any non-zero number of Explicit Mode 443 and Implicit Mode Acknowledgements sub-types. Both sub-types can be 444 present in a single Registration Reply. A Mobile Network 445 Acknowledgement extension is encoded in Type-Length-Value (TLV) 446 format. When the registration is denied with Code HA_MOBNET_ERROR 447 (Code field in the Registration Reply), the Code field in the 448 included Mobile Network Extension provides the reason for the 449 failure. 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Type | Length | Sub-Type | Code | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Prefix Length | Reserved | Prefix... 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 ...Prefix | Optional Netmask... 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 ...Optional Netmask | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Type: 465 TBA Mobile Network Extension (skippable type range to be 466 assigned by IANA). 468 Length: 470 Decimal 8 or decimal 12, not any other. If the masking is 471 expressed as Prefix/Prefix Length (e.g. 192.0.2.1/24), the 472 value of this Length field is decimal 8 and the Optional 473 Netmask field is absent. If the masking is expressed as 474 Prefix and Netmask (e.g. 192.0.2.1 255.255.0.255) then the 475 value of this Length field is decimal 12, the Optional 476 Netmask field is present and the value of the Prefix Length 477 field set to all-zero by sender and ignored by receiver. 479 Sub-Type: 481 TBA (Explicit Mode Acknowledgement) 483 TBA (Implicit Mode Acknowledgement) 485 Code: 487 Value indicating success or failure: 489 TBA Success 491 TBA Invalid prefix (MOBNET_INVALID_PREFIX_LEN) 493 TBA Mobile Router is not authorized for prefix 494 (MOBNET_UNAUTHORIZED) 496 TBA Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) 498 Prefix Length: 500 8-bit unsigned integer indicating the number of leftmost bits 501 covering the network part of the address contained in the 502 Prefix field. If the Optional Netmask field is present then 503 this field is set to all-zero by sender and ignored by 504 receiver. 506 Reserved: 508 Sent as zero; ignored on reception. 510 Prefix: 512 32-bit unsigned integer in network byte-order containing an 513 IPv4 address. If the Optional Netmask field is absent then 514 the first Prefix Length bits make up the Mobile Network 515 Prefix. Otherwise the Mobile Network Prefix is obtained by 516 masking this IPv4 address with the value of the Optional 517 Netmask field. 519 Optional Netmask: 521 32-bit unsigned integer in network byte-order containing an 522 IPv4 netmask. For example '255.255.0.255'. This field is 523 present when the subnet masking needs to be expressed as a 524 non-contiguous set of 1 bits. Otherwise it is absent. If 525 the Optional Netmask is present then the value of the field 526 Prefix Length is set to all-zero by sender and ignored by 527 receiver. 529 5. Mobile Router Operation 531 A Mobile Router's operation is generally derived from the behavior of 532 a Mobile Node, as set in RFC 3344 [RFC3344]. In addition to 533 maintaining mobility bindings for its Home Address, the Mobile 534 Router, together with the Home Agent, maintains forwarding 535 information for the Mobile Network Prefix(es) assigned to the Mobile 536 Router. 538 A Mobile Router SHOULD set the 'T' bit to 1 in all Registration 539 Request messages it sends to indicate the need for reverse tunnels 540 for all traffic. Without reverse tunnels, all the traffic from the 541 mobile network will be subject to ingress filtering in the visited 542 networks. Upon reception of a successful Registration Reply, the 543 Mobile Router processes the registration in accordance to RFC 3344 544 [RFC3344]. In addition, the following steps are taken: 546 o Check for Mobile Network Acknowledgement extension(s) in 547 Registration Reply 549 o Create tunnel to the Home Agent if registered in reverse tunneling 550 mode 552 o Set up default route via this tunnel or egress interface when 553 registered with or without reverse tunneling, respectively 555 In accordance with this specification, a Mobile Router may operate in 556 one of the following two modes: explicit and implicit. In explicit 557 mode, the Mobile Router includes Mobile Network Prefix information in 558 all Registration Requests (as Mobile Network Request extensions), 559 while in implicit mode it does not include this information in any 560 Registration Request. In this latter case, the Home Agent obtains 561 the Mobile Network Prefixes by other means than Mobile IP. One 562 example of obtaining the Mobile Network Prefix is through static 563 configuration on the Home Agent. 565 A Mobile Router can obtain a Collocated or Foreign Agent Care-of 566 Address while operating in explicit or implicit modes. 568 For de-registration, the Mobile Router sends a registration request 569 with lifetime set to zero without any Mobile Network Request 570 extensions. 572 5.1. Error Processing 574 In a Mobile IP Registration Reply message there may be two Code 575 fields: one proper to the Registration Reply header (the 'proper' 576 Code) and one within the Mobile Network Acknowledgement Extension 577 (simply the 'Code'). A Mobile Router interprets the values of the 578 Code field in the Mobile Network Acknowledgement Extension of the 579 Registration Reply in order to identify any error related to managing 580 the Mobile Network Prefixes by the Home Agent. It also interprets 581 the values of the Code field in the Registration Reply header (the 582 proper Code). 584 If the value of the Code field in the Registration Reply (the proper) 585 is set to HA_MOBNET_DISALLOWED, then the Mobile Router MUST stop 586 sending Registration Requests with any Mobile Network Prefix 587 extensions to that Home Agent. 589 If the value of the Code field in the Registration Reply (the proper) 590 is set to HA_MOBNET_ERROR then the Mobile Router MUST stop sending 591 Registration Requests that contain any of the Mobile Network Prefixes 592 that are defined by the values of the fields Prefix and Prefix Length 593 in the Mobile Network Acknowledgement extension. Note that the 594 registration is denied in this case and no forwarding for any Mobile 595 Network Prefixes would be set up by the Home Agent for the Mobile 596 Router. 598 It is possible that the Mobile Router receives a Registration Reply 599 with no mobile network extensions if the registration was processed 600 by a Mobile IPv4 home agent that does not support this specification 601 at all. In that case, the absence of mobile network extensions must 602 be interpreted by the Mobile Router as the case where the Home Agent 603 does not support mobile networks. 605 All the error code values are TBA (To Be Assigned) subject to IANA 606 allocation. 608 5.2. Mobile Router Management 610 Operating a Mobile Router in a Mobile IPv4 environment has certain 611 requirements on the management of the necessary initial configuration 612 and supervision of the ongoing status information. Mobile Router 613 maintenance indicators may need to be exposed in a manner consistent 614 with other Mobile IPv4 indicators. 616 The objects for the Management Information Base (MIB) for Mobile IPv4 617 are defined in RFC 2006 [RFC2006]. The structure of the basic model 618 of Mobile IP protocol describes three entities: Mobile Node, Home 619 Agent and Foreign Agent. In addition to these entities this document 620 proposes a functional entity to be the Mobile Router. 622 The necessary initial configuration at a NEMOv4-enabled Home Agent 623 includes, but is not limited to, the contents of the Prefix Table. 624 The Mobile Router MAY need to store the Mobile Network Prefixes as 625 the initial configuration. 627 The definition of MIB objects related to Mobile Router and of a 628 NEMOv4-enabled Home Agent is outside the scope of this document. 630 6. Home Agent Operation 632 6.1. Summary 634 A Home Agent MUST support all the operations specified in RFC 3344 635 [RFC3344] for Mobile Node support. The Home Agent MUST support both 636 implicit and explicit modes of operation for a Mobile Router. 638 The Home Agent processes the registration in accordance to RFC 3344 639 [RFC3344], which includes route set up to the Mobile Router's Home 640 Address via the tunnel to the Care-of Address. In addition, for a 641 Mobile Router registering in explicit mode, the following steps are 642 taken: 644 1. Check that the Mobile Network Prefix information is valid 646 2. Ensure the Mobile Network Prefix(es) is or are authorized to be 647 on the Mobile Router 649 3. Create tunnel to the Mobile Router if it does not already exist 651 4. Set up route for the Mobile Network Prefix via this tunnel 653 5. Propagate Mobile Network Prefix routes via routing protocol if 654 necessary 656 6. Send the Registration Reply with the Mobile Network 657 Acknowledgement extension(s) 659 If there are any subnet routes via the tunnel to the Mobile Router 660 that are not specified in the Mobile Network extensions, these routes 661 are removed. 663 In the case where the Mobile Node is not permitted to act as a Mobile 664 Router, the Home Agent sends a Registration Reply message whose Code 665 field is HA_MOBNET_DISALLOWED (the proper Code field of the 666 Registration Reply). 668 For a Mobile Router registering in implicit mode, the Home Agent 669 performs steps 3-6 above, once the registration request is processed 670 successfully. 672 For deregistration, the Home Agent removes the tunnel to the Mobile 673 Router and all routes using this tunnel. The Mobile Network 674 extensions are ignored. 676 6.2. Data Structures 678 6.2.1. Registration Table 680 The Registration Table in the Home Agent, in accordance with RFC 3344 681 [RFC3344], contains binding information for every Mobile Node 682 registered with it. RFC 3344 [RFC3344] defines the format of a 683 Registration Table. In addition to all the parameters specified by 684 RFC 3344 [RFC3344], the Home Agent MUST store the Mobile Network 685 Prefixes associated with the Mobile Router in the corresponding 686 registration entry, when the corresponding registration was performed 687 in explicit mode. When the Home Agent is advertising reachability to 688 Mobile Network Prefixes served by a Mobile Router, the information 689 stored in the Registration Table can be used. 691 6.2.2. Prefix Table 693 The Home Agent must be able to authorize a Mobile Router for use of 694 Mobile Network Prefixes when the Mobile Router is operating in 695 explicit mode. Also, when the Mobile Router operates in implicit 696 mode, the Home Agent must be able to locate the Mobile Network 697 Prefixes associated with that Mobile Router. The Home Agent may 698 store the Home Address of the Mobile Router along with the mobile 699 network prefixes associated with that Mobile Router. If the Mobile 700 Router does not have a Home Address assigned, this table may store 701 the NAI RFC 2794 [RFC2794] of the Mobile Router that will be used in 702 dynamic Home Address assignment. 704 6.3. Mobile Network Prefix Registration 706 The Home Agent must process registration requests coming from Mobile 707 Routers in accordance with this section. The document RFC 3344 708 [RFC3344] specifies that the Home Address of a mobile node 709 registering with a Home Agent must belong to a prefix advertised on 710 the home network. In accordance with this specification, however, 711 the Home Address must be configured from a prefix that is served by 712 the Home Agent, not necessarily the one on the home network. 714 If the registration request is valid, the Home Agent checks to see if 715 there are any Mobile Network Prefix extensions included in the 716 Registration Request. 718 If so, the Mobile Network Prefix information is obtained from the 719 included extensions, and the Home Address from the Home Address field 720 of the Registration Request. For every Mobile Network Prefix 721 extension included in the registration request, the Home Agent MUST 722 perform a check against the Prefix Table. If the Prefix Table does 723 not contain at least one entry pairing that Home Address to that 724 Mobile Network Prefix then the check fails, otherwise it succeeds. 726 Following this check against the Prefix Table, the Home Agent MUST 727 construct a Registration Reply containing Mobile Network 728 Acknowledgement extensions. For a Mobile Network Prefix for which 729 the check was unsuccessful the Code field in the corresponding Mobile 730 Network Acknowledgement extension should be set to 731 MOBNET_UNAUTHORIZED. 733 For a Mobile Network Prefix for which the check was successful the 734 Code field in the respective Mobile Network Acknowledgement 735 extensions should be set to 0. 737 The Home Agent MUST attempt to set up forwarding for each Mobile 738 Network Prefix extension for which the Prefix Table check was 739 successful. If the forwarding setup fails for a particular Mobile 740 Network Prefix (for reasons when, for example, there is not enough 741 memory available, or not enough devices available, or other reason) 742 the Code field in the respective Mobile Network Acknowledgement 743 extension should be set to MOBNET_FWDING_SETUP_FAILED. 745 If forwarding and setup was successful for at least one Mobile 746 Network Prefix then the Code field (proper) of the Registration Reply 747 message should be set to 0. Otherwise, when forwarding and setup was 748 unsuccessful for each and every Mobile Network Prefixes, that Code 749 (proper) should be HA_MOBNET_ERROR. 751 If the registration request is sent in implicit mode, i.e., without 752 any Mobile Network Request extension, the Home Agent may use pre- 753 configured mobile network prefix information for the Mobile Router to 754 set up forwarding. 756 If the Home Agent is updating an existing binding entry for the 757 Mobile Router, it MUST check all the prefixes in the registration 758 table against the prefixes included in the registration request. If 759 one or more mobile network prefix is missing from the included 760 information in the registration request, it MUST delete those 761 prefixes from the registration table. Also, the Home Agent MUST 762 disable forwarding for those prefixes. 764 If all checks are successful, the Home Agent either creates a new 765 entry for the Mobile Router or updates an existing binding entry for 766 it and returns a successful registration reply back to the Mobile 767 Router or the Foreign Agent (if the registration request was received 768 from a Foreign Agent). 770 In accordance with RFC 3344 [RFC3344], the Home Agent does proxy ARP 771 for the Mobile Router Home Address, when the Mobile Router Home 772 Address is derived from the home network. 774 If the 'T' bit is set, the Home Agent creates a bi-directional tunnel 775 for the corresponding mobile network prefixes or updates the existing 776 bi-directional tunnel. This tunnel is maintained independent of the 777 reverse tunnel for the Mobile Router home address itself. 779 6.4. Advertising Mobile Network Reachability 781 If the mobile network prefixes served by the Home Agent are 782 aggregated with the home network prefix and if the Home Agent is the 783 default router on the home network, the Home Agent does not have to 784 advertise the Mobile Network Prefixes. The routes for the Mobile 785 Network Prefix are automatically aggregated into the home network 786 prefix (it is assumed that the Mobile Network Prefixes are 787 automatically aggregated into the home network prefix). If the 788 Mobile Router updates the mobile network prefix routes via a dynamic 789 routing protocol, the Home Agent SHOULD propagate the routes on the 790 appropriate networks. 792 6.5. Establishment of Bi-directional Tunnel 794 The Home Agent creates and maintains a bi-directional tunnel for the 795 mobile network prefixes of a Mobile Router registered with it. A 796 home agent supporting IPv4 Mobile Router operation MUST be able to 797 forward packets destined to the mobile network prefixes served by the 798 Mobile Router to its Care-of Address. Also, the Home Agent MUST be 799 able to accept packets tunneled by the Mobile Router with the source 800 address of the outer header set to the Care-of Address of the Mobile 801 Router and that of the inner header set to the Mobile Router's Home 802 Address or an address from one of the registered mobile network 803 prefixes. 805 6.6. Sending Registration Replies 807 The Home Agent MUST set the status code in the registration reply to 808 0 to indicate successful processing of the registration request and 809 successful set up of forwarding for at least one mobile network 810 prefixes served by the Mobile Router. The registration reply MUST 811 contain at least one Mobile Network Acknowledgement extension. 813 If the Home Agent is unable to set up forwarding for one or more 814 mobile network prefixes served by the Mobile Router, it MUST set the 815 Mobile Network Acknowledgement Extension status Code in the 816 registration reply to MOBNET_FWDING_SETUP_FAILED. When the prefix 817 length is zero (and the Optional Netmask field is absent) or greater 818 than decimal 32, the status Code MUST be set to 819 MOBNET_INVALID_PREFIX_LEN. 821 If the Mobile Router is not authorized to forward packets to a mobile 822 network prefixes included in the request, the Home Agent MUST set the 823 Code to MOBNET_UNAUTHORIZED. 825 6.7. Mobile Network Prefix De-registration 827 If the received registration request is for de-registration of the 828 Care-of Address, the Home Agent, upon successful processing of it, 829 MUST delete the entry(ies) from its registration table. The home 830 agent tears down the bi-directional tunnel and stops forwarding any 831 packets to/from the Mobile Router. The Home Agent MUST ignore any 832 included Mobile Network Request extension in a de-registration 833 request. 835 7. Data Forwarding Operation 837 For traffic to the nodes in the Mobile Network, the Home Agent MUST 838 perform double tunneling of the packet, if the Mobile Router had 839 registered with a Foreign Agent Care-of Address. In this case, the 840 Home Agent MUST encapsulate the packet with tunnel header (source IP 841 address set to Home Agent and destination IP address set to Mobile 842 Router's Home Address) and then encapsulate one more time with tunnel 843 header (source IP address set to Home Agent and destination IP 844 address set to CoA). 846 For optimization, the Home Agent SHOULD only encapsulate the packet 847 with the tunnel header (source IP address set to Home Agent and 848 destination IP address set to CoA) for Collocated CoA mode. 850 When a Home Agent receives a packet from the mobile network prefix in 851 the bi-directional tunnel, it MUST de-encapsulate the packet and 852 route it as a normal IP packet. It MUST verify that the incoming 853 packet has the source IP address set to the Care-of Address of the 854 Mobile Router. The packet MUST be dropped if the source address is 855 not set to the Care-of Address of the Mobile Router. 857 For traffic from the nodes in the Mobile Network, the Mobile Router 858 encapsulates the packet with a tunnel header (source IP address set 859 to Mobile Router's Home Address and destination IP address set to 860 Home Agent) if reverse tunnel is enabled. Otherwise, the packet is 861 routed directly to the Foreign Agent or access router. 863 In Collocated CoA mode, the Mobile Router MAY encapsulate one more 864 times with a tunnel header (source IP address set to the CoA and 865 destination IP address set to Home Agent). 867 8. Nested Mobile Networks 869 Nested Network Mobility is a scenario where a Mobile Router allows 870 another Mobile Router to attach to its Mobile Network. There could 871 be arbitrary levels of nested mobility. The operation of each Mobile 872 Router remains the same whether the Mobile Router attaches to another 873 Mobile Router or to a fixed Access Router on the Internet. The 874 solution described here does not place any restriction on the number 875 of levels for nested mobility. Two issues should be noted though. 876 First, whenever physical loops occur in a nested aggregation of 877 mobile networks this protocol does neither detect nor solve them - 878 datagram forwarding may be blocked. Second, Mobile Routers in a deep 879 nested aggregation of mobile networks might introduce significant 880 overhead on the data packets as each level of nesting introduces 881 another tunnel header encapsulation. Applications that do not 882 support MTU discovery are adversely affected by the additional header 883 encapsulations, because the usable MTU is reduced with each level of 884 nesting. 886 9. Routing Protocol between Mobile Router and Home Agent 888 There are several benefits of running a dynamic routing protocol 889 between the Mobile Router and the Home Agent. If the mobile network 890 is relatively large, including several wireless subnets, then the 891 topology changes within the moving network can be exposed from the 892 Mobile Router to the Home Agent by using a dynamic routing protocol. 893 The purpose of the NEMOv4 protocol extensions to Mobile IPv4, as 894 defined in previous sections, is not to inform the Home Agent about 895 these topology changes, but to manage the mobility of the Mobile 896 Router. 898 Similarly, topology changes in the home network can be exposed to the 899 Mobile Router by using a dynamic routing protocol. This may be 900 necessary when new fixed networks are added in the home network. 901 Here too, the purpose of NEMOv4 extensions is not to inform the 902 Mobile Router about topology changes at home. 904 Examples of dynamic routing protocol include but are not limited to 905 OSPF Version 2 RFC 2328 [RFC2328], BGP RFC 4271 [RFC4271] and RIP 906 RFC 2453 [RFC2453]. 908 The recommendations are related to how the routing protocol and the 909 Mobile IPv4 implementation work in tandem on the Mobile Router and on 910 the Home Agent (1) without creating incoherent states in the 911 forwarding information bases at home and on the Mobile Router, (2) 912 without introducing topologically incorrect addressing information in 913 the visited domain and (3) efficiently avoid duplication of sent data 914 or over-provisioning of security. 916 The information exchanged between the Mobile Router and the Home 917 Agent is sent over the bi-directional tunnel established by the 918 Mobile IPv4 exchange Registration Request - Registration Reply (see 919 Section 6.5). If a network address and prefix about a subnet in the 920 moving network is sent by the Mobile Router within a routing protocol 921 message then they SHOULD NOT be sent in the Mobile IPv4 Registration 922 Request too, in order to avoid incoherencies in the forwarding 923 information bases. The Mobile Router SHOULD use NEMOv4 implicit mode 924 in this case (see Section 3). 926 The Mobile Router SHOULD NOT send routing protocol information 927 updates in the foreign network. The subnet addresses and prefixes 928 valid in the moving network are topologically incorrect in the 929 visited network. 931 If the Mobile Router and the Home Agent use a dynamic routing 932 protocol over the tunnel interface, and if that protocol offers 933 security mechanisms to protect that protocol's messages, then the 934 security recommendations in Section 10.1 apply. 936 10. Security Considerations 938 The Mobile Network extension is protected by the same rules for 939 Mobile IP extensions in registration messages. See the Security 940 Considerations section in RFC 3344 [RFC3344]. 942 The Home Agent MUST be able to verify that the Mobile Router is 943 authorized to provide mobility service for the Mobile Networks in the 944 registration request, before anchoring these Mobile Network Prefixes 945 on behalf of the Mobile Router. Forwarding for prefixes MUST NOT be 946 set up without successful authorization of the Mobile Router for 947 those prefixes. A registration failure MUST be notified to the 948 mobile router when it cannot be successfully authorized for prefixes 949 requested by it. 951 All registration requests and replies MUST be authenticated by the 952 MN-HA Authentication Extension as specified in RFC 3344 [RFC3344]. 954 When the registration request is sent in explicit mode, i.e., with 955 one or more Mobile Network Prefix extensions, all the Mobile Network 956 Prefix extensions MUST be included before the MN-HA Authentication 957 extension. Also, these extensions MUST be included in the 958 calculation of the MN-HA authenticator value. 960 The Mobile Router should perform ingress filtering on all the packets 961 received on the mobile network prior to reverse tunneling them to the 962 Home Agent. The Mobile Router MUST drop any packets that do not have 963 a source address belonging to the mobile network. 965 The Mobile Router MUST also ensure that the source address of packets 966 arriving on the mobile network is not the same as the Mobile Router's 967 IP address on any interface. These checks will protect against nodes 968 attempting to launch IP spoofing attacks through the bi-directional 969 tunnel. 971 The Home Agent, upon receiving packets through the bi-directional 972 tunnel, MUST verify that the source addresses of the outer IP header 973 of the packets are set to the Mobile Router's care-of-address. Also, 974 it MUST ensure that the source address of the inner IP header is a 975 topologically correct address on the mobile network. This will 976 prevent nodes from using the Home Agent to launch attacks inside the 977 protected network. 979 10.1. Security when Dynamic Routing Protocol is Used 981 If a dynamic routing protocol is used between the Mobile Router and 982 the Home Agent to propagate the mobile network information into the 983 home network, the routing updates SHOULD be protected with IPsec ESP 984 confidentiality between the Mobile Router and Home Agent, to prevent 985 information about home network topology from being visible to 986 eavesdroppers. 988 11. IANA Considerations 990 IANA to assign rules for the existing registry "Mobile IPv4 numbers - 991 per RFC 3344". The numbering space for Extensions that may appear in 992 Mobile IP control messages (those sent to and from UDP port number 993 434) should be modified. 995 The new Values and Names for the Type for Extensions appearing in 996 Mobile IP control messages are the following: 998 +-------+---------------------------------------------------+ 999 | Value | Name | 1000 +-------+---------------------------------------------------+ 1001 | TBA | Mobile Network Extension (To Be Assigned by IANA) | 1002 +-------+---------------------------------------------------+ 1004 Table 1: New Values and Names for Extensions in Mobile IP Control 1005 Messages 1007 A new number space should be created for the Values and Names for the 1008 Sub-Type for Mobile Network Extensions. This number space is 1009 initially defined to hold the following entries, allocated by this 1010 document: 1012 +-------+-----------------------------------------+ 1013 | Value | Name | 1014 +-------+-----------------------------------------+ 1015 | TBA | Mobile Network Request Extension | 1016 | TBA | Explicit Mode Acknowledgement Extension | 1017 | TBA | Implicit Mode Acknowledgement Extension | 1018 +-------+-----------------------------------------+ 1020 Table 2: New Values and Names for the Sub-Type for Mobile Network 1021 Extensions 1023 The policy of future assignments to this number space should be 1024 following Standards Action or IESG Approval (see [RFC2434]). 1026 The new Code Values for Mobile IP Registration Reply messages are the 1027 following (for a registration denied by the Home Agent): 1029 +-------+-----------------------------------------------------------+ 1030 | Value | Name | 1031 +-------+-----------------------------------------------------------+ 1032 | TBA | Mobile Network Prefix operation error (HA_MOBNET_ERROR) | 1033 | TBA | Mobile Router operation is not permitted | 1034 | | (HA_MOBNET_DISALLOWED) | 1035 +-------+-----------------------------------------------------------+ 1037 Table 3: New Code Values for Mobile IP Registration Reply 1039 A new number space should be created for the Code Values for the 1040 Mobile Network Acknowledgement Extension. This number space is 1041 initially defined to hold the following entries, allocated by this 1042 document (result of registration, as sent by the Home Agent): 1044 +-----+-------------------------------------------------------------+ 1045 | TBA | Success | 1046 | TBA | Invalid prefix length (MOBNET_INVALID_PREFIX_LEN) | 1047 | TBA | Mobile Router is not authorized for prefix | 1048 | | (MOBNET_UNAUTHORIZED) | 1049 | TBA | Forwarding setup failed (MOBNET_FWDING_SETUP_FAILED) | 1050 +-----+-------------------------------------------------------------+ 1052 Table 4: New Code Values for Mobile Network Acknowledgement Extension 1054 The policy of future assignments to this number space should be 1055 following Standards Action or IESG Approval (see [RFC2434]). 1057 The current non-modified numbering spaces could be consulted at the 1058 URL http://www.iana.org/assignments/mobileip-numbers (contents last 1059 updated 2007-12-20 and last browsed 2008-01-04). 1061 12. Acknowledgements 1063 The authors would like to thank Christophe Janneteau, George 1064 Popovich, Ty Bekiares, Ganesh Srinivasan, Alpesh Patel, Ryuji 1065 Wakikawa, George Tsirtsis, and Henrik Levkowetz for their helpful 1066 discussions, reviews and comments. Vijay Devarapalli extensively 1067 reviewed one of the later versions of the draft. Hans Sjostrand 1068 (Hans Sj\"ostrand) identified the last clarifications with respect to 1069 Foreign Agent mode treatment. Pete McCann contributed necessary 1070 refinements of many statements. 1072 Mobile IPv4 versions as early as 1996 (RFC 2002) described Mobile 1073 Networks and Mobile Routers support. Charles Perkins. 1075 Fred Templin indicated the potential confusion for the term "LFN". 1077 Amanda Baber of IANA agreed on the principles of allocating numbers 1078 for this specification and suggested improvements on the IANA 1079 section. 1081 Tim Polk of IESG identified a deeply entrenched error on managing the 1082 Code fields. 1084 Lars Eggert of IESG suggested the acommodation of the otherwise legal 1085 non-contiguous netmask fields, instead of simply prefix lengths. 1087 Dan Romascanu of IESG indicated the necessity of manageability of 1088 Mobile Routers and NEMOv4-enabled Home Agents and their deployability 1089 in MIP4 environments. 1091 David Borman of TSV-DIR reviewed this document as part of the 1092 transport area directorate's ongoing effort to review key IETF 1093 documents. The implications of the growth of usable MTU adversely 1094 affecting applications deep in a mobile network were suggested. 1096 Gonzalo Camarillo provided a generalist review by an additional set 1097 of eyes for documents as they are being considered for publication 1098 (General Area Review Team). 1100 Jari Arkko of IESG reviewed, suggested necessary improvements to, and 1101 diligently shepherded this document through IESG. 1103 13. References 1105 13.1. Normative References 1107 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 1108 for High Performance", RFC 1323, May 1992. 1110 [RFC2006] Cong, D., Hamlen, M., and C. Perkins, "The Definitions of 1111 Managed Objects for IP Mobility Support using SMIv2", 1112 RFC 2006, October 1996. 1114 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1115 Requirement Levels", BCP 14, RFC 2119, March 1997. 1117 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1119 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1120 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1121 October 1998. 1123 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 1124 November 1998. 1126 [RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access 1127 Identifier Extension for IPv4", RFC 2794, March 2000. 1129 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1130 August 2002. 1132 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1133 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1135 13.2. Informative References 1137 [I-D.ietf-mip4-nemov4-fa] 1138 Tsirtsis, G., Park, V., Narayanan, V., and K. Leung, "FA 1139 extensions to NEMOv4 Base", draft-ietf-mip4-nemov4-fa-02 1140 (work in progress), November 2007. 1142 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1143 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1144 RFC 3963, January 2005. 1146 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 1147 Terminology", RFC 4885, July 2007. 1149 Appendix A. ChangeLog 1151 [RFC Editor: please remove this section prior to publication. (said 1152 IESG member Russ Housley on 6th of February 2008: "Please delete 1153 Appendix A before publication as an RFC.")] 1155 The changes are listed in reverse chronological order, most recent 1156 changes appearing at the top of the list. 1158 From draft-ietf-mip4-nemo-v4-base-09.txt to 1159 draft-ietf-mip4-nemo-v4-base-10.txt: 1161 o Changed "192.168.1.1" notation to "192.0.2.0" documentation style 1162 addresses, as suggested by idnits. 1164 From draft-ietf-mip4-nemo-v4-base-08.txt to 1165 draft-ietf-mip4-nemo-v4-base-09.txt, following IANA and IESG 1166 comments: 1168 o Introduced an Optional Netmask field in both registrations and 1169 replies. This is used when address/prefixlength is not a 1170 sufficient expression of network mask, for example when the subnet 1171 mask needs to be expressed as a non-contiguous set of 1bits (e.g. 1172 255.255.0.255). Also described the reasoning of this in a section 1173 of its own. 1175 o Extended the Introduction section with two subsections: example of 1176 mobile network and overall protocol operation. Illustrated two 1177 figures. 1179 o Added Local Fixed Node term definition and some citations to 1180 reference rfc4885 "Network Mobility Support Terminology". 1182 o Clarified text about the Code field. There are two Code fields: 1183 one in Registration Reply header (the Code proper) and one in the 1184 Mobile Network Extension header. Also clarified conditions of 1185 proper Code being 0 successful and and relationships of proper 1186 Code 0 to Code in the Mobile Network Extension. 1188 o Added a sub-section 'Mobile Router Management' about the initial 1189 configuration, ongoing supervision and management indicators of a 1190 Mobile Router and Home Agent. 1192 o Substituted 'MOBNET_UNAUTHORIZED' for 'MOBNET_UNAUTHORIZED_MR'. 1194 o Substituted 'IANA to assign rules' for 'IANA to modify rules'. 1196 o Stressed that "applications that do not support MTU discovery are 1197 adversely affected by the additional header encapsulations, 1198 because the usable MTU is reduced with each level of nesting." 1200 o Removed citations and reference to rfc3344bis 1201 (draft-ietf-mip4-rfc3344bis-05). 1203 o Removed citations and reference to rfc2434bis 1204 (draft-narten-iana-considerations-rfc2434bis-08). 1206 o Extended the Acknowledgements section. 1208 From draft-ietf-mip4-nemo-v4-base-07.txt to 1209 draft-ietf-mip4-nemo-v4-base-08.txt, following AD Review (Jari 1210 Arkko): 1212 o HA propagates Mobile Network Prefix only if necessary (previously 1213 it was always doing it). 1215 o emphasized that within nested mobile networks looping may occur 1216 and this document doesn't do anything to address this. 1218 o dropped a phrase which said that Mobile-Home auth extension 1219 shouldn't be used when ESP protects the routing protocol message, 1220 because that extension is only applied to Registration messages 1221 (not tunneled data, which usually contains routing protocol 1222 exchange). 1224 o recommending "Standards Action or IESG Review" instead of "Expert 1225 Review" for this numbering space, and added reference to a draft 1226 for 2434bis. 1228 o editorial: re-phrased about how Mobile IPv4 claimed mobile 1229 networks support. 1231 o editorial: added a necessary paragraph in the Acknowledgements 1232 section. 1234 From draft-ietf-mip4-nemo-v4-base-06.txt to 1235 draft-ietf-mip4-nemo-v4-base-07.txt 1237 o encoded the draft into xml. Compiled with xml2rfc version 1238 1.33pre4. 1240 o checked against 'idnits' script version 2.05.03. 1242 o substituted 'Care-of Address' for 'CoA'. 1244 From draft-ietf-mip4-nemo-v4-base-05.txt to 1245 draft-ietf-mip4-nemo-v4-base-06.txt 1247 o substituted "TBA" for "1" in Sub-type of Mobile Network Request 1248 Extension. 1250 o substituted "TBA" for "0" in Code of Mobile Network 1251 Acknowledgement Extension and in the IANA Section. 1253 o modified the IANA section to request definition two new spaces 1254 (instead of just defining new values) for Sub-Type of Mobile 1255 Network Extensions and for Code Values for Mobile Network 1256 Acknowledgement Extension, and to suggest "Expert Review" as 1257 method of new assignments in these two spaces (and not necessarily 1258 "IETF Consensus"). 1260 From draft-ietf-mip4-nemo-v4-base-04.txt to 1261 draft-ietf-mip4-nemo-v4-base-05.txt 1263 o updated the Acknowledgements section. 1265 o capitalized all occurences of "Home Address", "Mobile Router" and 1266 "Care-of Address". 1268 o refined many statements. 1270 o checked against 'idnits' script version 2.04.16. 1272 From draft-ietf-mip4-nemo-v4-base-03.txt to 1273 draft-ietf-mip4-nemo-v4-base-04.txt 1275 o more changes in Introduction to say that with FA mode only the 1276 non-optimized double-encapsulation operation is supported and 1277 [I-D.ietf-mip4-nemov4-fa] proposes a optimization. 1279 From draft-ietf-mip4-nemo-v4-base-02.txt to 1280 draft-ietf-mip4-nemo-v4-base-03.txt 1282 o changed a sentence in the Introduction to say that FA mode _is_ 1283 supported but unoptimized, and that a reference 1284 [I-D.ietf-mip4-nemov4-fa] optimizes that mode. 1286 o added I-D.ietf-mip4-rfc3344bis reference to the rfc3344bis draft. 1288 From draft-ietf-mip4-nemo-v4-base-01.txt to 1289 draft-ietf-mip4-nemo-v4-base-02.txt 1291 o changed title from "IPv4 Network Mobility (NEMO) Protocol" to 1292 "Network Mobility (NEMO) Extensions for Mobile IPv4". 1294 From draft-ietf-mip4-nemo-v4-base-00.txt to 1295 draft-ietf-mip4-nemo-v4-base-01.txt 1297 o added a section on Routing Protocol between Mobile Router and Home 1298 Agent. 1300 o added a security subsection about running simultaneously a secure 1301 routing protocol with secure Mobile IPv4. 1303 o added a date tag on the IANA URL for Mobile IP numbering spaces. 1305 o substituted 'Mobile Router' for 'MR' everywhere. 1307 o updated reference to NEMOv4 FA draft. 1309 From draft-ietf-nemo-v4-base-01.txt to 1310 draft-ietf-mip4-nemo-v4-base-00.txt: 1312 o changed draft name, headers and footers. 1314 o changed title. 1316 o a more coherent use of terms 'subnet', 'prefix' and 'mobile 1317 network'. 1319 o clarified only co-located CoA mode is supported (not FA CoA) for 1320 Mobile Routers in this specification. And added reference to the 1321 FA NEMO optimizations draft. 1323 o changed 'devices' to 'hosts'. 1325 o changed 'moving networks' to 'mobile networks'. 1327 o clarified what 'reachability' in a certain context is: packets may 1328 be dropped if ingress filtering is turned on. 1330 o removed the MR-FA-CoA tunnel overhead optimization. There is 1331 still an issue with text at HA doing optimization. 1333 This document was first presented as an individual contribution to 1334 the NEMO Working Group, then adopted as a WG item to that group. The 1335 01 version in the NEMO WG has been Last Called on the INFORMATIONAL 1336 track. The evolution was: 1338 From version draft-ietf-nemo-v4-base-00 to 1339 draft-ietf-nemo-v4-base-01: 1341 o removed error code HA_MOBNET_UNSUPPORTED. 1343 o changed all values to be assigned by IANA, from specific numbers 1344 to "TBA" (To Be Assigned). 1346 o substituted "egress interface" for "roaming interface". 1348 o changed HA behaviour upon reception of MNPs. In 00 the HA replied 1349 positively only if all MNPs in RegReq were valid, in 01 a reply is 1350 constructed specifying which MNP was valid and which not. 1352 o clarified a 3-line paragraph saying that RegRep may contain both 1353 implicit and explicit acknowledgements. 1355 Authors' Addresses 1357 Kent Leung 1358 Cisco Systems 1359 170 W. Tasman Drive 1360 San Jose, CA 95134 1361 USA 1363 Phone: +1 408-526-5030 1364 Email: kleung@cisco.com 1365 Gopal Dommety 1366 Cisco Systems 1367 170 W. Tasman Drive 1368 San Jose, CA 95134 1369 USA 1371 Phone: +1 408-525-1404 1372 Email: gdommety@cisco.com 1374 Vidya Narayanan 1375 QUALCOMM, Inc. 1376 5775 Morehouse Dr 1377 San Diego, CA 1378 USA 1380 Phone: +1 858-845-2483 1381 Email: vidyan@qualcomm.com 1383 Alexandru Petrescu 1384 Motorola 1385 Parc les Algorithmes Saint Aubin 1386 Gif-sur-Yvette, Essonne 91140 1387 France 1389 Phone: +33 169354827 1390 Email: alexandru.petrescu@motorola.com 1392 Full Copyright Statement 1394 Copyright (C) The IETF Trust (2008). 1396 This document is subject to the rights, licenses and restrictions 1397 contained in BCP 78, and except as set forth therein, the authors 1398 retain all their rights. 1400 This document and the information contained herein are provided on an 1401 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1402 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1403 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1404 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1405 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1406 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1408 Intellectual Property 1410 The IETF takes no position regarding the validity or scope of any 1411 Intellectual Property Rights or other rights that might be claimed to 1412 pertain to the implementation or use of the technology described in 1413 this document or the extent to which any license under such rights 1414 might or might not be available; nor does it represent that it has 1415 made any independent effort to identify any such rights. Information 1416 on the procedures with respect to rights in RFC documents can be 1417 found in BCP 78 and BCP 79. 1419 Copies of IPR disclosures made to the IETF Secretariat and any 1420 assurances of licenses to be made available, or the result of an 1421 attempt made to obtain a general license or permission for the use of 1422 such proprietary rights by implementers or users of this 1423 specification can be obtained from the IETF on-line IPR repository at 1424 http://www.ietf.org/ipr. 1426 The IETF invites any interested party to bring to its attention any 1427 copyrights, patents or patent applications, or other proprietary 1428 rights that may cover technology that may be required to implement 1429 this standard. Please address the information to the IETF at 1430 ietf-ipr@ietf.org. 1432 Acknowledgment 1434 Funding for the RFC Editor function is provided by the IETF 1435 Administrative Support Activity (IASA).