idnits 2.17.1 draft-ietf-mobileip-protocol-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 97 instances of too long lines in the document, the longest one being 10 characters in excess of 72. ** There are 475 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 122: '...se, the datagram MUST be silently disc...' RFC 2119 keyword, line 123: '...P Destination Unreachable MUST NOT |...' RFC 2119 keyword, line 177: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 180: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 183: '... SHOULD This word, or the adjecti...' (47 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 1994) is 10938 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) -- Looks like a reference, but probably isn't: 'RFC-1548' on line 267 -- Looks like a reference, but probably isn't: 'RFC-1332' on line 268 -- Looks like a reference, but probably isn't: 'RFC-1256' on line 345 -- Looks like a reference, but probably isn't: 'RFC-768' on line 439 -- Looks like a reference, but probably isn't: 'RFC-1305' on line 520 == Missing Reference: '2' is mentioned on line 675, but not defined -- Looks like a reference, but probably isn't: 'RFC-791' on line 786 -- Looks like a reference, but probably isn't: 'RFC-826' on line 1300 -- Looks like a reference, but probably isn't: 'Bellovin89' on line 1444 == Unused Reference: '1' is defined on line 1441, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W A Simpson, Editor 2 Internet Draft Daydreamer 3 expires in six months May 1994 5 IP Mobility Support 6 draft-ietf-mobileip-protocol-02.txt | 8 Status of this Memo 10 This document is a submission to the Mobile-IP Working Group of the 11 Internet Engineering Task Force (IETF). Comments should be submitted 12 to the mobile-ip@ossi.com mailing list. 14 Distribution of this memo is unlimited. 16 Internet Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its Areas, and its Working Groups. Note that 18 other groups may also distribute working documents as Internet 19 Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months. Internet Drafts may be updated, replaced, or obsoleted by 23 other documents at any time. It is not appropriate to use Internet 24 Drafts as reference material or to cite them other than as a 25 ``working draft'' or ``work in progress.'' 27 Please check the 1id-abstracts.txt listing contained in the 28 internet-drafts Shadow Directories on nic.ddn.mil, ds.internic.net, 29 venera.isi.edu, nic.nordu.net, or munnari.oz.au to learn the current 30 status of any Internet Draft. 32 Abstract 34 This document specifies protocol enhancements that allow transparent 35 routing of IP datagrams to Mobile Nodes in the Internet. The Mobile 36 Node is always identified by its Home-Address, regardless of its 37 current point of attachment to the Internet. While situated away 38 from its home, a Mobile Node is also associated with a Care-Of- 39 Address, which provides information about its current point of 40 attachment to the Internet. The protocol provides for registering 41 the Care-Of-Address with the Home Agent. The Home Agent tunnels 42 traffic destined for the Mobile Node to the Care-Of-Address. 44 1. Introduction 46 Current versions of the Internet Protocol make an implicit assumption 47 that a node's attachment point remains fixed. Datagrams are sent to 48 a node based on the network and subnet number contained in the node's 49 IP address. 51 If a node moves while keeping its IP address unchanged, its network 52 number will not reflect its new point of attachment. The routing 53 protocols will not be able to route datagrams to it correctly. 55 This document defines new functions that allow a node to roam on the 56 Internet, without changing its IP address. 58 The following entities are defined: 60 Mobile Node 62 An IP host or router that changes connections from one network or | 63 subnetwork to another. 65 Home Agent 67 A router on a network that advertises reachability for a Mobile 68 Node, maintains a registry of the current Mobility Bindings for 69 that node while it is away from home, and tunnels datagrams for 70 delivery to a Mobile Node. 72 Foreign Agent 74 A router that assists a locally reachable Mobile Node that is away 75 from its home network. 77 The following support services are defined: 79 Agent Discovery 81 Agents advertise their availability on each link. 83 A newly arrived Mobile Node can send a solicitation on the link to 84 learn if any prospective Agents are present. 86 Care-Of-Address Assignment 88 The Care-Of-Address terminates the end of a tunnel toward a Mobile 89 Node. Depending on the foreign network configuration, the Care- | 90 Of-Address may be dynamically assigned to the Mobile Node, or | 91 associated with a Foreign Agent. 93 Registration 95 When the Mobile Node is away from home, it registers the Care-Of- | 96 Address with the Home Agent. 98 Depending on its method of attachment, the Mobile Node will 99 register either directly with a Home Agent, or through a Foreign 100 Agent which forwards the registration to the Home Agent. 102 Encapsulation 104 Once a Mobile Node has registered a Care-Of-Address with a Home 105 Agent, the Home Agent intercepts datagrams destined for the Mobile 106 Node, formulates another datagram with the intercepted datagram | 107 enclosed within, and forwards the resulting datagram to the Care- | 108 Of-Address. 110 Decapsulation 112 At the Care-Of-Address, the enclosed datagram is extracted. | 114 When the Mobile Node has its own Care-Of-Address, it decapsulates 115 its own datagrams. 117 When the Care-Of-Address is associated with a Foreign Agent, the | 118 Foreign Agent decapsulates the datagrams. If the datagram is 119 addressed to a Mobile Node which the Foreign Agent is currently 120 serving, it will deliver the datagram to the Mobile Node. | 122 Otherwise, the datagram MUST be silently discarded (rather than | 123 being further forwarded). ICMP Destination Unreachable MUST NOT | 124 be sent when a Foreign Agent is unable to forward a datagram. 126 1.1. Requirements 128 A Mobile Node using its Home-Address shall be able to communicate 129 with other nodes after having been disconnected from the Internet, 130 and then reconnected at a different point. 132 A Mobile Node shall continue to be capable of communicating directly 133 with existing nodes that do not implement the mobility functions 134 described in this document. 136 A Mobile Node shall provide authentication in its registration 137 messages. 139 1.2. Goals 141 As few administrative messages as possible are sent between a Mobile 142 Node and a Foreign Agent. The link is likely to be bandwidth 143 limited. 145 The size of messages on the Mobile Node's directly attached link are 146 to be kept as short as possible. The link is likely to be bandwidth 147 limited. 149 1.3. Assumptions 151 The protocols defined in this document place no additional 152 requirements on assignment of IP addresses. That is, a Mobile Node 153 will be assigned an IP address by the organization that owns the | 154 machine, and will be able to use that IP address regardless of the | 155 current point of attachment. 157 Mobile Nodes are able to change their point of attachment to the 158 Internet as frequently as once per second. 160 No protocol enhancements are required in hosts or routers that are 161 not serving any of the mobility functions. Similarly, no additional 162 protocols are needed by a router (that is not acting as a Home Agent | 163 or a Foreign Agent) to route datagrams to or from a Mobile Node. 165 The operation of this specification assumes that IP datagrams are 166 routed to a destination without regard to the source of the datagram. 168 If desired, the Mobile Node can tunnel to its Home Agent. The 169 definition of such tunneling mechanisms is outside the scope of this 170 specification. 172 1.4. Specification Language 174 In this document, several words are used to signify the requirements 175 of the specification. These words are often capitalized. 177 MUST This word, or the adjective "required", means that the 178 definition is an absolute requirement of the specification. 180 MUST NOT This phrase means that the definition is an absolute 181 prohibition of the specification. 183 SHOULD This word, or the adjective "recommended", means that there 184 may exist valid reasons in particular circumstances to 185 ignore this item, but the full implications must be 186 understood and carefully weighed before choosing a 187 different course. 189 MAY This word, or the adjective "optional", means that this 190 item is one of an allowed set of alternatives. An 191 implementation which does not include this option MUST be 192 prepared to interoperate with another implementation which 193 does include the option. 195 silently discard 196 The implementation discards the packet without further 197 processing, and without indicating an error to the sender. 198 The implementation SHOULD provide the capability of logging 199 the error, including the contents of the discarded packet, 200 and SHOULD record the event in a statistics counter. 202 1.5. Terminology 204 This document frequently uses the following terms: 206 Authentication Type 207 This includes the algorithm and algorithm mode. Note that 208 a single algorithm (such as DES) might have several modes 209 (for example, CBC and ECB). 211 Correspondent Host 212 The peer with which a Mobile Node is communicating. The 213 Correspondent Host may be either mobile or stationary. 215 Home-Address 216 A long term IP address that is assigned to a Mobile Node. 217 It remains unchanged regardless of where the node is 218 attached to the Internet. The Home-Address is intercepted 219 by the Home Agent while the Mobile Node is registered with 220 that Home Agent. 222 Link A communication facility or medium over which nodes can 223 communicate at the link layer; underlying the network 224 layer. 226 Mobility Binding 227 The association of a Home-Address with a Care-Of-Address, 228 and the remaining LifeTime of the association. 230 Routing Prefix 231 The high-order bits in an address, which are used by 232 routers to locate a link for delivery of a datagram. | 234 Mobility Security Association | 235 The security relationship between two nodes that is used | 236 with Mobile IP protocol messages. This relationship | 237 includes the authentication type (including algorithm and | 238 algorithm mode), the secret (such as a shared key, or | 239 appropriate public/private key pair), and possibly other | 240 information such as labelling. 242 Triangle Routing 243 A path followed by a datagram destined for a Mobile Node, 244 when that datagram arrives first at the Home Agent, and 245 then is encapsulated and tunneled by the Home Agent. 247 2. Agent Discovery | 249 To communicate with a Foreign or Home Agent, a Mobile Node must learn 250 either the IP address or the link address of that Agent. 252 It is assumed that a link-layer connection has been established 253 between the Agent and the Mobile Node. The method used to establish 254 such a link-layer connection is not specified in this document. 256 After establishing a link-layer connection that supports the 257 attachment of Mobile Nodes, the node must learn if there are any 258 prospective Foreign Agents available to serve it while it is away 259 from home. If the Mobile Node is returning home, it must learn if 260 its Home Agent is available. 262 There are often several methods of learning the availability of an | 263 Agent. Those described here are recommended. 265 Point-to-Point Link-Layers | 267 The Point-to-Point-Protocol (PPP) [RFC-1548] Internet Protocol | 268 Control Protocol (IPCP) [RFC-1332], negotiates the use of IP | 269 addresses. 271 When the Home-Address is not accepted, but a transient IP address | 272 is dynamically assigned, that address is used as the Care-Of- | 273 Address in registration. | 275 When no transient IP address is dynamically assigned, but an IP | 276 address is advertised by the peer, that address is assumed to be | 277 the IP address of an Agent. | 279 Multi-Point Link-Layers | 281 Another link establishment protocol, IEEE 802.11, might yield the 282 link address of an agent. This link-layer address is used to | 283 attempt registration. 285 ICMP Router Discovery | 287 An Agent which is not identified by a link-layer protocol MUST | 288 implement ICMP Router Discovery [RFC-1256]. The Router | 289 Advertisements indicate whether the router is also an Agent. 291 It is recommended that as few messages as possible which duplicate | 292 functionality be sent on mobile links. This is particularly | 293 important on wireless and congested links. | 294 When multiple methods are in use, the Mobile Node SHOULD first 295 attempt registration with routers sending Router Advertisements in | 296 preference to those sending link-layer advertisements. This ordering | 297 maximizes the likelihood that the registration will be recognized, 298 thereby minimizing the number of registration attempts. 300 An Administrative Domain MAY require registration with a Foreign 301 Agent even when another registration method is in use. This facility 302 is envisioned for service providers with packet filtering fire-walls, 303 or visiting policies (such as accounting) which require exchanges of 304 authorization. 306 2.1. Authentication 308 No authentication is required for the advertisement and solicitation 309 process. 311 These messages MAY be authenticated using a future IP Authentication 312 Header, which is external to the messages described here. Further | 313 work on authentication of advertisement and solicitation is outside | 314 of the scope of this document. | 316 Whenever an externally authenticated message fails authentication, 317 the message is silently discarded. | 319 2.2. Agent Solicitation | 321 Every Mobile Node is required to implement ICMP Router Solicitation. 322 However, the Router Solicitation is only sent when no link-layer 323 identification has been received. 325 Any Foreign Agent and Home Agent which is not identified by a link- 326 layer protocol MUST implement ICMP Router Solicitation. | 328 The same procedures, defaults, and constants are used as described in 329 "ICMP Router Discovery Messages" [RFC-1256]. 331 2.3. Agent Advertisement | 333 Every Mobile Node is required to correctly process ICMP Router | 334 Advertisements. 336 Any Foreign Agent and Home Agent which is not identified by a link- 337 layer protocol MUST implement ICMP Router Advertisements. | 339 An Agent which is identified by a link-layer protocol SHOULD also | 340 implement Router Advertisements. However, the Router Advertisements | 341 need not be sent, except when the site policy requires registration | 342 with the Agent, or as a response to a specific Router Solicitation. | 344 The same procedures, defaults, and constants are used as described in 345 "ICMP Router Discovery Messages" [RFC-1256], except as specified 346 herein. 348 The Router Advertisements are extended by examining the number of | 349 advertised addresses. When the IP total length indicates that the | 350 ICMP message is longer than needed for the number of addresses | 351 present, the remainder is interpreted as extensions. 353 The Mobility Extension is required, and indicates that the router is | 354 an Agent. Other extensions, such as the Short Encapsulation | 355 Extension indicate optionally supported features. | 357 The Code field of the ICMP Router Advertisement is interpreted as | 358 follows: | 360 0 If the Mobility Extension is present, the router supports | 361 mobility registration. The router is participating in routing | 362 common traffic. | 364 16 A Home or Foreign Agent which supports registration, but is not | 365 participating in routing common traffic. | 367 The Mobile Node chooses a Care-Of-Address from among advertising | 368 Agents in the same fashion as it would choose a first hop router. | 369 The Care-Of-Address chosen is the most preferred Router Address | 370 listed. 372 3. Registration 374 The registration function exchanges information between Mobile Nodes 375 and Home Agents. This function creates a Mobility Binding, linking 376 the Home-Address with the Care-Of-Address currently used by the 377 Mobile Node. 379 When assigned a transient Care-Of-Address, a Mobile Node can act 380 without a Foreign Agent. When registering or deregistering directly 381 with the Home Agent, the registration process involves the exchange 382 of only 2 messages. 384 a) The Mobile Node sends a Registration Request to the Home Agent, | 385 to ask the Home Agent to provide the requested service. 387 b) The Home Agent sends a Registration Reply to the Mobile Node to 388 grant or deny service. 390 An Administrative Domain MAY require registration through a Foreign | 391 Agent, as indicated in Agent Advertisements. 393 When the Care-Of-Address is associated with Foreign Agent, the 394 Foreign Agent acts as a relay between the Mobile Node and Home Agent. 395 The extended registration process involves the exchange of 4 396 messages: 398 a) The Mobile Node sends a Registration Request to the prospective | 399 Foreign Agent to begin the registration process. 401 b) The Foreign Agent relays the request by sending a Registration | 402 Request to the Home Agent, to ask the Home Agent to provide the 403 requested service. 405 c) The Home Agent sends a Registration Reply to the Foreign Agent 406 to grant or deny service. 408 d) The Foreign Agent sends a copy of the Registration Reply to the 409 Mobile Node to inform it of the disposition of its request. 411 3.1. Authentication 413 Each Mobile Node, Foreign Agent, and Home Agent MUST support an 414 internal table holding a list of IP addresses, and the Mobility | 415 Security Association for each address. 417 Mobile Node to Home Agent registration messages are required to be 418 authenticated with the Mobile-Home Authentication Extension. The 419 Mobile Node and Home Agent MUST support authentication using keyed | 420 MD5 and key sizes of 128 bits or greater, with manual key | 421 distribution. Additional authentication algorithms, algorithm modes, | 422 and key distribution methods MAY also be supported. 424 In addition, the Foreign Agent SHOULD support authentication using | 425 keyed MD5 and key sizes of 128 bits or greater, with manual key | 426 distribution. Additional authentication algorithms, algorithm modes, | 427 and key distribution methods MAY also be supported. 429 Only one Mobility Security Association exists between any given pair | 430 of participating nodes at any given time. 432 Whenever a Mobility Security Association exists between a pair of | 433 nodes, all registration messages between these nodes MUST be | 434 authenticated, using the appropriate authentication extension. 436 3.2. UDP | 438 The Registration messages defined herein use the User Datagram | 439 Protocol header [RFC-768]. The UDP well-known port is used. | 441 The UDP checksum is required. Any mobility message with an incorrect | 442 or zero UDP checksum is silently discarded. | 444 3.3. Registration Request | 446 The UDP Header is followed by the fields shown below: 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Type | Code | LifeTime | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Home Agent | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Home-Address | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 457 | Care-Of-Address | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | Reserved | Prefix-Size | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | | 462 + TimeStamp + 463 | | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Extensions ... 466 +-+-+-+-+-+-+-+- 468 IP fields: 470 Source The Home-Address of the Mobile Node. 472 Destination The IP address of the Agent, when known. 474 When the IP address is unknown (the agent was 475 discovered via a link-layer protocol), the "all 476 Mobile Agents" multicast address. The link-layer 477 unicast address is used to deliver the datagram to 478 the correct Agent. 480 UDP fields: 482 Source Port variable 484 Destination Port 486 MobileIP fields: 488 Type | 490 1 when sent by the Mobile Node 491 2 when sent by the Foreign Agent 492 Code Optional capabilities: 494 0 - remove prior registrations 495 1 - retain prior registrations 497 LifeTime The seconds remaining before the registration is 498 considered expired. A value of zero indicates a 499 request for de-registration. A value of all ones 500 indicates infinity. 502 The LifeTime SHOULD NOT be set to greater than the 503 LifeTime learned in an Agent Advertisement. 505 Home Agent The IP address of the Home Agent. | 507 Home-Address The Home IP address of the Mobile Node. 509 Care-Of-Address The IP address for the decapsulation end of a | 510 tunnel. | 512 Reserved Sent as zero; ignored on reception. 514 Prefix-Size The size of the left-justified bit-mask that is 515 applied to the Home-Address to determine the IP 516 subnet routing-prefix. Ranges from 0 to 30. Set to 517 zero by Mobile Nodes which are not routers. 519 TimeStamp 64 bits. A sequence number assigned by the Mobile 520 Node. A Network Time Protocol [RFC-1305] value is | 521 preferred, but the elapsed time since system 522 startup, or any other monotonically increasing 523 counter MAY be used. The value MUST NOT be the same 524 as an immediately preceeding request. 526 The Mobile-Home Authentication Extension is required, and immediately | 527 follows all non-authentication extensions. 529 Authenticator A hash value taken over a stream of bytes consisting 530 of the shared secret between the Mobile Node and 531 Home Agent, followed by (concatenated with) the 532 fields in the message beginning with the Code field, | 533 including all prior extensions, and the Type and | 534 Length of this extension, but not including the 535 Authenticator field itself, and finally the shared | 536 secret again. 538 The Mobile-Foreign or Foreign-Home Authentication Extension is | 539 optional, and immediately follows the Mobile-Home Authentication 540 Extension. * 542 When forwarded by a Foreign Agent, fields and extensions are copied | 543 from the Registration Request without modification. 545 3.4. Registration Reply 547 The UDP Header is followed by the fields shown below: 549 0 1 2 3 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Type | Code | LifeTime | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Home-Address | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Reserved | Prefix-Size | * 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | | 559 + TimeStamp + 560 | | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Extensions ... 563 +-+-+-+-+-+-+-+- 565 IP fields: 567 The Source and Destination of the Request message are swapped for the | 568 Reply message. 570 Note that the Source of the original Registration Request must be | 571 saved in order for the Foreign Agent to return the reply to the 572 correct Mobile Node. 574 UDP fields: 576 The Source Port and Destination Port of the Request message are | 577 swapped for the Reply message. 579 Note that the Source Port of the original Registration Request must | 580 be saved in order for the Foreign Agent to return the reply to the 581 correct Mobile Node port. 583 MobileIP fields: 585 Type 3 587 Code One of the following codes: 589 0 service will be provided. 591 denied by Foreign Agent, 592 16 reason unspecified. 594 17 administratively prohibited. 595 18 insufficient resources. 596 19 Mobile Node failed authentication. 597 20 Home Agent failed authentication. 598 21 Request LifeTime too long. | 600 denied by Home Agent, 601 32 reason unspecified. 602 33 administratively prohibited. 603 34 insufficient resources. 604 35 Mobile Node failed authentication. 605 36 Foreign Agent failed authentication. 607 Up-to-date values of the Code field are specified in 608 the most recent "Assigned Numbers" RFC [2]. 610 LifeTime The seconds remaining before the registration is 611 considered expired. A value of zero confirms a 612 request for de-registration. A value of all ones 613 indicates infinity. | 615 May be modified by the Home Agent. 617 Home-Address Copied from the Request message. | 619 Reserved Copied from the Request message. 621 Prefix-Size Copied from the Request message. | 623 TimeStamp Copied from the Request message. | 625 The Mobile-Home Authentication Extension is required, and immediately | 626 follows all non-authentication extensions. 628 Authenticator A hash value taken over a stream of bytes consisting 629 of the shared secret between the Mobile Node and 630 Home Agent, followed by (concatenated with) all of 631 the fields in the message beginning with the Code 632 field, including all prior extensions, and the Type | 633 and Length of this extension, but not including the 634 Authenticator field itself, and finally the shared | 635 secret again. 637 Note that the Care-Of-Address and Home Agent are not | 638 present in the message. This provides a separate 639 calculation value for mutual authentication from the 640 Home Agent to the Mobile Node. 642 The Mobile-Foreign or Foreign-Home Authentication Extension is | 643 optional, and immediately follows the Mobile-Home Authentication 644 Extension. 646 When forwarded by a Foreign Agent, fields and extensions are copied | 647 from the Registration Reply without modification. 649 4. Mobility Message Extensions | 651 To promote extensibility, each message begins with a short fixed | 652 part, which is followed by one or more extensions in Type-Length- | 653 Value format. 655 Extensions allow variable amounts of information to be carried within | 656 each datagram. The end of the list of Extensions is indicated by the | 657 Total Length of the IP datagram. | 659 0 1 2 660 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 662 | Extension | Length | Data ... 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 665 Extension Current values are assigned as follows: | 667 16 Mobility 668 32 Mobile-Home Authentication 669 33 Mobile-Foreign Authentication 670 34 Foreign-Home Authentication 671 64 Minimal Encapsulation 672 65 GRE Encapsulation 674 Up-to-date values are specified in the most recent | 675 "Assigned Numbers" RFC [2]. | 677 Length Indicates the length of the Data field. The Length | 678 does not include the Extension and Length bytes. | 680 Data This field is zero or more bytes and contains the | 681 value(s) for this Extension. The format and length | 682 of the Data field is determined by the Extension and | 683 Length fields. | 685 When an extension is encountered which is not recognized, it is | 686 ignored. The length field is used to skip the data field in | 687 searching for the next extension. | 689 4.1. Mobility Extension | 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Extension | Length | Sequence Number | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 |R| Reserved | 697 +-+-+-+-+-+-+-+-+ 699 Extension 16 | 701 Length 3 | 703 Sequence Number Contains the number of advertisement messages sent | 704 since the node was initialized. This number MUST | 705 include this advertisement. 707 When this value decreases, the Mobile Node MUST | 708 assume that any current registration has been lost. | 709 This field cannot roll over in less than 2**16 | 710 seconds, and rollover is unambiguously indicated by | 711 the value zero. | 713 R Registration required bit. When this bit is set to | 714 1, registration with the Foreign Agent is required, | 715 even when the Mobile Node has acquired a transient | 716 Care-Of-Address. | 718 Reserved Sent as zero; ignored on reception. | 720 4.2. Authentication Extensions | 722 0 1 2 3 | 723 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 | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 725 | Extension | Length | Authenticator | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 728 Extension | 730 32 Mobile-Home 731 33 Mobile-Foreign 732 34 Foreign-Home 734 Length The number of data bytes in the Extension (16 when | 735 MD5 is used). | 737 Authenticator Variable length (128 bits for MD5). | 739 For Mobile-Home authentication, the value differs | 740 depending on the direction the message is sent. | 741 These calculations are defined in the Registration | 742 Request and Reply messages. | 744 For Mobile-Foreign and Foreign-Home authentication, | 745 a hash value taken over a stream of bytes consisting | 746 of the shared secret, followed by (concatenated | 747 with) the Source, the Destination, the remaining | 748 fields in the message beginning with the UDP header, | 749 including all prior extensions, and the Type and | 750 Length of this extension, but not including the | 751 Authenticator field itself, and finally the shared | 752 secret again. | 754 4.3. Minimal Encapsulation Extension | 756 0 1 757 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Extension | Length | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 Extension 64 | 764 Length 0 | 766 5. Forwarding Datagrams to the Mobile Node | 768 5.1. IP in IP Encapsulation | 770 Support for IP in IP encapsulated tunneling is required. Use of | 771 other tunneling methods is optional. | 773 The full IP fragmentation header is inserted before the datagram's IP 774 header: 776 +---------------------------+ 777 | Outer IP Header | | 778 +---------------------------+ +---------------------------+ 779 | IP Header | | IP Header | | 780 +---------------------------+ ====> +---------------------------+ 781 | | | | 782 | IP Payload | | IP Payload | | 783 | | | | 784 +---------------------------+ +---------------------------+ 786 The format of the IP header is as described in [RFC-791]. The outer | 787 IP header Source and Destination addresses identify the "endpoints" | 788 of the tunnel. The inner IP header Source and Destination addresses | 789 identify the sender and recipient of the datagram. | 791 The Protocol field in the IP header is replaced by protocol number | 792 for the encapsulation protocol. | 794 The Destination field in the IP header is replaced by the Care-Of- | 795 Address of the Mobile Node. | 797 If the encapsulating agent is not the original source of the | 798 datagram, the Source field in the IP header is replaced by the IP | 799 address of the encapsulating agent. | 801 When the Home Agent encapsulates the datagram, it sets the IP Time To | 802 Live (TTL) field to be the same as the original datagram. | 804 When decapsulating, the outer IP TTL minus one is inserted into the | 805 inner IP TTL. Thus, IP hops are counted, but the actual routers | 806 interior to the tunnel are not identified. 808 5.2. Minimal Encapsulation | 810 A minimal forwarding header is defined for datagrams which are not | 811 fragmented prior to tunneling. When a datagram is already fragmented | 812 prior to tunneling, IP in IP is used. | 814 The minimal header is inserted between the datagram's IP header and | 815 the rest of the datagram: 817 +---------------------------+ +---------------------------+ | 818 | IP Header | | Modified IP Header | | 819 +---------------------------+ ====> +---------------------------+ | 820 | | | Forwarding Header | | 821 | IP Payload | +---------------------------+ | 822 | | | | | 823 +---------------------------+ | IP Payload | | 824 | | | 825 +---------------------------+ | 827 A Foreign Agent which is capable of decapsulating the minimal header | 828 will include the Minimal Encapsulation Extension in its Router | 829 Advertisements. 831 A Mobile Node indicates the capability of decapsulating the minimal | 832 header at the Care-Of-Address by the inclusion of the Minimal | 833 Encapsulation Extension in its Registration Request. 835 The Minimal Encapsulation Extension is not included in the | 836 Registration Reply. The use of the minimal header is entirely at the | 837 discretion of the Home Agent. 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Protocol |S| Reserved | Header Checksum | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Home-Address | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Correspondent Source Address | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 Protocol Copied from the Protocol field in the original IP * 850 header. 852 S Source field present bit, which indicates that the 853 Correspondent Source Address field is present. 855 0 not present. 856 1 present. 858 Reserved Sent as zero; ignored on reception. 860 Header Checksum The 16-bit one's complement of the one's complement 861 sum of the encapsulation header. For computing the 862 checksum, the Checksum field is set to 0. 864 Home-Address Copied from the Destination field in the original IP 865 header. 867 Correspondent Source Address 868 Copied from the Source field in the original IP 869 header. Present only if the S-bit is set. 871 The Protocol field in the IP header is replaced by protocol number 872 for the encapsulation protocol. 874 The Destination field in the IP header is replaced by the Care-Of- 875 Address of the Mobile Node. 877 If the encapsulating agent is not the original source of the 878 datagram, the Source field in the IP header is replaced by the IP 879 address of the encapsulating agent. 881 Finally, the Don't Fragment bit is set in the IP header. 883 When decapsulating a datagram, the fields in the forwarding header 884 are restored to the IP header, and the forwarding header is removed 885 from the datagram. 887 5.3. Tunneling Management | 889 It is possible that one of the routers along the tunnel interior | 890 might encounter an error while processing the datagram, causing it to | 891 return an IP ICMP error message to the source end of the tunnel. The | 892 three types of ICMP errors that can occur in this circumstance are: | 894 - Datagram too big. 895 - Time Exceeded. 896 - Destination Unreachable. 898 Unfortunately, ICMP only requires IP routers to return 8 bytes (64 | 899 bits) of the datagram beyond the IP header. This is not enough to | 900 include the encapsulated header, so it is not generally possible for | 901 the Home Agent to immediately reflect the ICMP message from the | 902 interior of a tunnel back to the source host. 904 However, by carefully maintaining "soft state" about its tunnels, a | 905 Home Agent can return accurate ICMP messages in most cases. The Home | 906 Agent SHOULD maintain at least the following soft state information | 907 about each tunnel: | 909 - MTU of the tunnel. 910 - TTL (path length) of the tunnel 911 - Reachability of the end of the tunnel. 913 The Home Agent uses the ICMP messages it receives from the interior | 914 of a tunnel to update the soft state information for that tunnel. | 915 When subsequent datagrams arrive that would transit the tunnel, the | 916 router checks the soft state for the tunnel. If the datagram would | 917 violate the state of the tunnel (such as, the TTL is less than the | 918 tunnel TTL) the Home Agent sends an ICMP error message back to the | 919 source, but also forwards the datagram into the tunnel. 921 Using this technique, the ICMP error messages sent by Home Agents | 922 will not always match up one-to-one with errors encountered within | 923 the tunnel, but they will accurately reflect the state of the | 924 network. 926 6. Mobile Node Considerations | 928 A Mobile Node listens for Beacons at all times that it has a link 929 connection. In this manner, it can learn that its Foreign Agent has 930 changed, or that it has arrived home. 932 Whenever a Mobile Node changes its point of attachment to the 933 Internet, it must initiate the registration process. If it is away 934 from home, it must register with a Foreign Agent. If it is returning 935 home, it must deregister with its Home Agent. 937 A Mobile Node will operate without the support of mobility functions 938 when it is at home. 940 6.1. Configuration and Registration Tables 942 Each Mobile Node will need: 944 - Home-Address 945 - Prefix-Size 946 - one or more Home Agents | 948 For each pending registration: | 950 - Media Address of Agent 951 - Care-Of-Address 952 - TimeStamp used 953 - LifeTime 955 For each Mobility Security Association: | 957 - Authentication Type 958 - Authentication Key 960 6.2. Registration When Away From Home 962 If a Mobile Node detects a change in the Incarnation Number of a 963 Foreign Agent with which it is registered, it SHOULD re-register with 964 that Agent. 966 A Mobile Node SHOULD re-register with its Foreign Agent(s) before the 967 LifeTime of its registration expires. The Mobile Node MAY re- 968 register with its Foreign Agent(s) at any time. 970 A Mobile Node can ask the Home Agent to terminate forwarding service 971 through a particular Care-Of-Address, by sending a registration with 972 a LifeTime of zero. 974 6.3. Registration without a Foreign Agent 976 In cases where a Mobile Node away from home is able to dynamically * 977 acquire a transient IP address, the Mobile Node can serve without a 978 Foreign Agent, using the transient address as the Care-Of-Address. 979 Thus, the registration function and the tunnel decapsulation function 980 can be co-located in a single node. This eliminates the need to 981 deploy separate entities as Foreign Agents. 983 The direct registration process involves the exchange of only two 984 messages: 986 a) The Mobile Node sends a Registration Request to the Home Agent, | 987 to ask the Home Agent to provide the requested service. 989 b) The Home Agent sends a Registration Reply to the Mobile Node to 990 grant or deny service. 992 All communication between the Mobile Node and its Home Agent is 993 direct, and there is no need to use the Agent Solicitation, Agent 994 Advertisement, and Registration Request. | 996 It is assumed that such a Mobile Node has mechanisms to detect 997 changes in its link-layer connectivity, and to initiate acquisition 998 of a new transient address each time such a change occurs. The 999 mechanisms will be specific to the particular link-layer technology, 1000 and are outside the scope of this document. 1002 6.4. De-registration When At Home 1004 At times, a Mobile Node will attach itself to its home link. Since a 1005 Mobile Node that is at home needs no forwarding, a de-registration 1006 procedure MAY be used between the Mobile Node and its Home Agent. 1008 The de-registration process involves the exchange of only two 1009 messages: 1011 a) The Mobile Node sends a Registration Request directly to its | 1012 Home Agent, with the LifeTime set to zero, and the Code field 1013 set to 0, to indicate that the Home Agent remove all related 1014 entries. 1016 b) The Home Agent sends a Registration Reply to the Mobile Node to 1017 grant or deny service. 1019 In this special case, for Authenticator calculation, the Care-Of- | 1020 Address is set to the Home-Address. 1022 This procedure is specified for the sake of convenience. The Mobile 1023 Node is not required to register with its Home Agent. It MAY de- 1024 register with each Foreign Agent, or it MAY allow its Mobility 1025 Bindings to simply expire. 1027 It is not necessary to re-register with a Home Agent when a change of 1028 Incarnation Number occurs, or the Advertisement LifeTime expires, 1029 since the Mobile Node is not seeking tunneling service. 1031 6.5. Registration Replies 1033 When a Mobile Node receives a Registration Reply which has a 1034 TimeStamp which is not the same as the TimeStamp of its most recent 1035 Registration Request to the putative sender, the message is silently 1036 discarded. 1038 When a Reply is received which has a Code indicating information from 1039 the Foreign Agent, the Mobile-Home Authenticator will be missing or | 1040 invalid. However, if no other reply has as yet been received, the 1041 reason for denial SHOULD be accepted, and result in an appropriate 1042 action. If a later authenticated reply is received, that reply 1043 supercedes the unauthenticated reply. 1045 When a Reply is received which has a Code indicating that 1046 authentication failed with the Home Agent, the reason for denial 1047 SHOULD result in an appropriate action. 1049 Otherwise, when a Reply is received with an invalid Authenticator, 1050 the message is silently discarded. 1052 When the LifeTime of the reply is greater than the original request, 1053 the excess time SHOULD be ignored. When the LifeTime of the reply is 1054 smaller than the original request, re-registration SHOULD occur 1055 before the LifeTime expires. 1057 The Mobile Node is not required to issue any message in reply to a 1058 Registration Reply. 1060 6.6. Simultaneous Registrations 1062 Under normal circumstances, sending a new Registration Request | 1063 removes other unexpired registrations for a Mobile Node from the Home 1064 Agent. 1066 An optional capability is to allow multiple simultaneous 1067 registrations. For example, this is particularly useful when a 1068 Mobile Node is on a border between multiple cellular systems. 1070 In order to request simultaneous registrations, the Mobile Node sends | 1071 the Registration Request with a Code set to 1. 1073 The return Code in the Registration Reply is the same. No error 1074 occurs if the Home Agent is unable to fulfill the request. 1076 IP explicitly allows duplication of datagrams. When the Home Agent 1077 is able to fulfill the request, the Home Agent will encapsulate a 1078 copy of each arriving datagram to each Care-Of-Address, and the 1079 Mobile Node will receive multiple copies of its datagrams. 1081 7. Foreign Agent Considerations 1083 It is the intent that Foreign Agent involvement be as minimal as 1084 possible. The role of the Foreign Agent is passive, passing 1085 registration requests to the Home Agent, and decapsulating tunneled 1086 datagrams to pass to the Mobile Node. 1088 When no Mobility Security Association exists, this also reduces the | 1089 risks resulting from absence of authentication from Foreign Agent 1090 messages. 1092 The Foreign Agent MUST NOT originate a Request or Reply that has not 1093 been prompted by the Mobile Node. No Request or Reply is generated 1094 to indicate that the service LifeTime has expired. 1096 A Foreign Agent MUST NOT originate a message which revokes the 1097 registration of a different Foreign Agent. A Foreign Agent SHOULD 1098 forward such revocations without modification when such revocation 1099 messages originated from an appropriate Mobile Node or Home Agent. * 1101 7.1. Configuration and Registration Tables 1103 Each Foreign Agent will need: 1105 - Care-Of-Address 1107 For each pending or current registration, the Foreign Agent will need 1108 a Visitor List: 1110 - Media Address of Mobile 1111 - Home-Address 1112 - Prefix-Size 1113 - Home Agent 1114 - LifeTime 1116 A Foreign Agent that has implemented and is using authentication will | 1117 also need to have the Mobility Security Association information for 1118 each pending or current authenticated registration. Even if a 1119 Foreign Agent implements authentication, it might not use 1120 authentication with each registration, because of the key management 1121 difficulties. 1123 7.2. Receiving Registration Requests | 1125 Upon receipt of a Registration Request, the Foreign Agent may: | 1127 - immediately deny service to the Mobile Node, by sending a 1128 Registration Reply with the appropriate Code set. 1130 - request permission from the Home Agent to provide service to the 1131 Mobile Node, by sending a Registration Request. | 1133 If the Foreign Agent is unable to satisfy the request for some | 1134 reason, such as the Mobile Node proposes a Lifetime longer than the | 1135 Foreign Agent has advertised, then the Foreign Agent sends a | 1136 Registration Reply with an appropriate Code, and does not forward the | 1137 request to the Home Agent. 1139 The Foreign Agent must maintain a list of pending Requests, which * 1140 includes the IP Source Address and UDP Source Port, in order that the 1141 Reply can be returned to the Mobile Node. * 1143 7.3. Receiving Registration Replies 1145 A Registration Reply which does not relate to a pending Registration 1146 Request, or to a currently registered Mobile Node, is silently 1147 discarded. 1149 If the Registration Reply granted permission to provide service to 1150 the Mobile Node, then the Foreign Agent updates its Visitor List 1151 accordingly. 1153 8. Home Agent Considerations 1155 It is the intent that the Home Agent have primary responsibility for 1156 processing and coordinating services. 1158 The Home Agent for a given Mobile Node SHOULD be located on the link 1159 identified by the Home-Address. This link MAY be virtual. 1161 8.1. Configuration and Registration Tables 1163 Each Home Agent will need: 1165 - an IP Address 1167 For each authorized Mobile Node, the Home Agent will need: 1169 - Home-Address * 1170 - Prefix-Size 1172 For each registered Mobile Node, the Home Agent will need a 1173 Forwarding List: 1175 - Home-Address 1176 - Prefix-Size 1177 - Care-Of-Address 1178 - LifeTime 1180 For each Mobility Security Association: | 1182 - Authentication Type 1183 - Authentication Key 1185 8.2. Receiving Requests from the Foreign Agent | 1187 Upon receipt of a Registration Request from the Foreign Agent, the | 1188 Home Agent grants or denies the service requested by sending a 1189 Registration Reply to the sender of the request, with the appropriate 1190 Code set. 1192 When a Registration Request has an invalid Authenticator for the 1193 Mobile Node, a Reply is sent to the Foreign Agent, in order that the 1194 Foreign Agent can clear its pending request list. 1196 If permission is granted for the Foreign Agent to provide service to 1197 the Mobile Node, the Home Agent will update its Forwarding List with 1198 the Home-Address of the Mobile Node, and the Care-Of-Address of the 1199 tunnel. 1201 The Home Agent MAY shorten the LifeTime of the request. 1203 If the Request asks for termination of service by indicating a 1204 LifeTime of zero, the Home Agent removes the Mobility Binding for 1205 that Care-Of-Address from its Forwarding List. 1207 8.3. Receiving Requests from the Mobile Node | 1209 Upon receipt of a Registration Request from the Mobile Node, the Home | 1210 Agent grants or denies the service requested by sending a 1211 Registration Reply to the sender of the request, with the appropriate 1212 Code set. 1214 In this special case, for Authenticator calculation, the Care-Of- 1215 Address is a copy of the Home-Address. 1217 The Home Agent MAY shorten the LifeTime of the request. | 1219 If the Request asks for termination of service by indicating a 1220 LifeTime of zero, and the Code field set to 0, the Home Agent removes 1221 the Mobility Bindings for all Foreign Agents associated with that 1222 Mobile Node from its Forwarding List. 1224 No special Reply is sent to associated Foreign Agents. The entries 1225 in their Visiting Lists are allowed to expire naturally. 1227 8.4. Simultaneous Registrations 1229 When a Home Agent supports the optional capability of multiple 1230 simultaneous registrations, any datagrams forwarded are simply 1231 duplicated, and a copy is sent to each Care-Of-Address. 1233 The return Code in the Registration Reply is the same. No error 1234 occurs if the Home Agent is unable to fulfill the request, and 1235 earlier entries in the Forwarding List are removed. 1237 8.5. Registration Expiration 1239 If the LifeTime for a given Mobile Node expires before the Home Agent 1240 has received a re-registration request, then the associated Mobility 1241 Binding is erased from the Forwarding List. 1243 No special Registration Reply is sent to the Foreign Agents. The 1244 entries in the Visiting Lists will expire naturally, and probably at 1245 the same time. 1247 A. Mobile Networks 1249 A Mobile Node can be a router, which is responsible for the mobility 1250 of an entire network moving together, such as on an airplane, a ship, 1251 a train, an automobile, a bicycle, or a kayak. Provision for a 1252 Routing-Prefix in registration messages allows such a Mobile Router 1253 to register with a Foreign or Home Agent. 1255 Every Foreign Agent MUST be capable of passing all arriving 1256 encapsulated traffic for the routing-prefix to the correct Mobile 1257 Router. The Foreign Agent SHOULD NOT advertise the presence of the 1258 Mobile Router to other routers in its routing domain. 1260 When a transient IP address has been assigned, the Mobile Router can 1261 act as its own Foreign Agent, and register directly with the Home 1262 Agent, as described above. Such a Mobile Router MAY advertise to 1263 other routers in the foreign routing domain. 1265 The Mobile Router continues to participate in its home routing domain 1266 through the tunnel to the Home Agent. 1268 When the Mobile Router returns home, and de-registers with the Home 1269 Agent, it MAY participate in routing with other routers in its home 1270 routing domain. 1272 DISCUSSION: 1274 Dissatisfaction has been expressed that this restricts the roaming 1275 net to a single contiguous subnet. 1277 Language changes have been requested for "location privacy". 1279 B. Gratuitous and Proxy ARP | 1281 Many people will use their computers for extended periods of time on 1282 a single link, whether or not it is at their Home Network. When 1283 doing so, they will expect the same level of service from their 1284 infrastructure as they receive today on the Home Network. Special 1285 care has to be taken with handling ARP Requests from other nodes on 1286 the same link. 1288 A problem can arise if a Mobile Node which has previously answered an 1289 ARP Request moves away from the link, leaving behind a stale entry in 1290 another node's ARP cache. For example, if a router which forwards 1291 datagrams into the Home Network has a stale ARP cache entry for the 1292 Mobile Node, any datagrams arriving through that router for the 1293 Mobile Node will be lost. Thus, it is important that ARP caches of 1294 nodes populating the link be updated as soon as possible. 1296 A gratuitous ARP is an ARP Reply that is broadcast to all nodes on a 1297 link, which is not in response to any ARP Request. When an ARP Reply 1298 is broadcast, all hosts are required to update their local ARP 1299 caches, whether or not the ARP Reply was in response to an ARP 1300 Request they had issued [RFC-826]. 1302 Therefore, a reasonably good solution is that a gratuitous proxy ARP 1303 is issued by the Home Agent on behalf of a Mobile Node whenever the 1304 Home Agent receives a valid registration. The gratuitous proxy ARP 1305 will indicate that all remaining nodes should associate the Home- 1306 Address of the Mobile Node with the link-layer address of the Home 1307 Agent that is now serving the Mobile Node. 1309 For this purpose, the source IP address would be the Home-Address, 1310 the source link-layer address would be for the interface used, the 1311 target IP address would be the all-systems multicast address, and the 1312 target link-layer address would be the general broadcast. 1314 The gratuitous ARP SHOULD NOT be repeated. Another proxy ARP will be 1315 sent in response to further Mobile Node registration requests, or 1316 Correspondent Host ARP Requests. 1318 While the Mobile Node is away from its Home Network, the Home Agent 1319 performs proxy ARP Replies for the Mobile Node. 1321 When a Mobile Node returns to its Home Network, it SHOULD issue a 1322 gratuitous ARP on its own behalf, just before de-registering itself 1323 from the Home Agent. 1325 After a Mobile Node de-registers, the Home Agent SHOULD issue ICMP 1326 Redirects when it receives a datagram from a Correspondent Host that 1327 could be sent directly to the Mobile Node. 1329 DISCUSSION 1331 This has pretty much the same set of problems (compounded by broken 1332 proxy ARP implementations) as gratuitous ARP. I would suggest to 1333 remove this as well. 1335 1. The block of addresses (routing prefix) given to a HA shall be 1336 used *exclusively* for mobile hosts. A non-mobile host should 1337 not be assigned an address out of this block. If a mobile 1338 host is assigned address out of this block, then it may 1339 adversely impact its operations with mobile hosts. 1341 2. Communication from CH to MH goes always through the HA associated 1342 with the MH (regardless of whether CH and MH are on a common subnet or not), 1343 unless triangular route elimination is employed. 1345 3. From (2) it follows that the only 1346 IP <-> Link Layer address mapping an MH has to perform is for the 1347 MH's first hop router (usually the FA). In the case of a separate 1348 FA, MH learns FA's address as part of the registration, so MH 1349 doesn't need to do any ARP. In the case of an MH acting as its own 1350 tunnel end-point the MH acquires the IP address of its first hop 1351 router by means outside of the document (e.g. via DHCP), and that is 1352 the only IP address that MH may require ARP. So, a MH should be 1353 constrained NOT to use ARP if the MH doesn't act as its own tunnel 1354 end-point, and to use ARP to resolve ONLY the address of its first 1355 hop router if the MH acts as its own tunnel end-point. 1357 Specifically, it is well know that in real life packets (including 1358 ARP packets) can be lost. Thus a node that has a stale ARP cache 1359 may not receive the gratuitous ARP, and thus wouldn't purge its 1360 ARP entry. Since the gratuitous ARP mechanism is inherently 1361 unreliable and has unpredictable behaviour (you don't know 1362 whether a host would or wouldn't be able to receive such an ARP), 1363 it would be unwise to build any dependencies on it. As such 1364 all the text on gratuitous ARP should be removed from the document. 1366 COUNTER: 1368 Having a separate address block for mobile hosts would require a 1369 person with a home network to have a router between the laptop 1370 (which is mobile) and the non-mobile servers. This is bad. 1372 In fact, you can't STOP someone from doing this. You CAN indicate 1373 what features need to be in the MH and HA to enter and leave gracefully. 1375 C. TCP Timers 1377 Most hosts and routers which implement TCP/IP do not permit easy | 1378 configuration of the TCP Timer values. When high-delay (e.g. SATCOM) | 1379 or low-bandwidth (e.g. High-Frequency Radio) links are in use, the | 1380 default TCP Timer values in many systems will cause retransmissions | 1381 or timeouts when the link and network is actually operating properly, | 1382 though with greater than usual delays because of the media in use. | 1383 This can cause an inability to create or maintain connections over | 1384 such links, and can also cause unneeded retransmissions which consume | 1385 already scarce bandwidth. Vendors are encouraged to make TCP Timers | 1386 more configurable. Vendors of systems designed for the mobile | 1387 computing markets should pick default timer values more suited to | 1388 low-bandwidth, high-delay links. Users of Mobile Nodes should be | 1389 sensitive to the possibility of timer-related difficulties. 1391 Security Considerations 1393 The mobile computing environment is potentially very different from 1394 the ordinary computing environment. In many cases, mobile computers 1395 will be connected to the network via wireless links. Such links are 1396 particularly vulnerable to passive eavesdropping, active replay 1397 attacks, and other active attacks. 1399 The registration protocol described here will result in a host's 1400 traffic being source routed to its mobile location. Such traffic 1401 redirection could be a significant vulnerability when the 1402 registration were not authentic. Also, source routing is widely 1403 understood to be a security problem in the current Internet. 1404 [Bellovin89] The Address Resolution Protocol (ARP) is not 1405 authenticated, and can potentially be used to steal another host's 1406 traffic. The use of "Gratuitous ARP" as described in this 1407 specification increases the risks of ARP because ARP is not 1408 authenticatable. 1410 This specification includes a strong authentication mechanism (keyed 1411 MD5) which precludes many potential attacks based on the Mobile IP 1412 registration protocol. However, because key distribution is 1413 difficult in the absence of a network key management protocol, not 1414 all messages with the Foreign Agent are authenticated. 1415 Vulnerabilities remain in the registration protocol whenever a 1416 registration message is not authenticated. For example, in a 1417 commercial environment it might be important to authenticate all 1418 messages between the Foreign Agent and the Home Agent, so that 1419 billing is possible, and service providers don't provide service to 1420 users that are not legitimate customers of that service provider. 1422 The strength of any authentication mechanism is dependent on several 1423 factors, including the innate strength of the authentication 1424 algorithm, the secrecy of the key used, the strength of the key used, 1425 and the quality of the particular implementation. This specification 1426 requires implementation of keyed MD5 for authentication, but does not 1427 preclude the use of other authentication algorithms and modes. For 1428 keyed MD5 authentication to be useful, the 128-bit key must be both 1429 secret (that is, known only to authorised parties) and pseudo-random. 1430 RFC-XXXX provides more information on generating pseudo-random 1431 numbers. 1433 Users who have sensitive data that they do not wish others to see 1434 should use mechanisms outside the scope of this specification (such 1435 as encryption) to provide appropriate protection. Users concerned 1436 about traffic analysis should consider appropriate use of link 1437 encryption. 1439 References 1441 [1] "V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level | 1442 Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983." 1444 Also, the [Bellovin89] reference is: | 1446 "Steven M. Bellovin, "Security Problems in the TCP/IP Protocol | 1447 Suite", ACM Computer Communications Review, Vol. 19, No. 2, | 1448 March 1989." | 1450 RFC-1256, RFC-1305, RFC-1321, and RFC-1548 here. 1452 Acknowledgments 1454 Special thanks to John Ioannidis (Columbia), for his inspiration and 1455 experimentation which began this most recent round of IP mobility 1456 development. 1458 Many thanks to Charlie Perkins (IBM), who tirelessly proposed common 1459 definitions and summaries, without which we may still have 1460 uncomparable proposals with different terminologies. Charlie also 1461 coalesed the Home and Foreign Agent objects. 1463 Security details are primarily the work of Randall Atkinson (NRL). 1465 Tunnel soft state was originally developed for the "IP Address 1466 Encapsulation (IPAE)" specification, by Robert E. Gilligan, Erik 1467 Nordmark, and Bob Hinden (all of Sun Microsystems). 1469 Much of the text of this specification is derived from earlier drafts 1470 by Charlie Kunzinger (IBM), the former Working Group Editor, who 1471 never put his name on the document. 1473 Thanks to the verbose members of the Working Group, particularly 1474 those who contributed text, including Dave Johnson (Carnegie Mellon 1475 University), Tony Li (Cisco Systems), Andrew Myles (Macquarie 1476 University), John Penners (US West), Fumio Taraoka (Sony), and John 1477 Zao (Harvard). 1479 Finally, the Editor wishes to thank Phil Karn (Qualcomm), whose 1480 decade of IP mobility experimentation in the amateur radio community, 1481 and widespread freeware dissemination of his KA9Q software, provided 1482 the impetus and availability for many thousands throughout the world 1483 to join the Internet community. 1485 Chair's Address 1487 The working group can be contacted via the current chairs: 1489 Stephen Deering Greg Minshall 1490 3333 Coyote Hill Road 1491 Palo Alto, CA 94304 1493 415-812-4839 617-873-4153 1495 Deering@PARC.Xerox.com minshall@wc.novell.com 1497 Editor's Address 1499 Questions about this memo can also be directed to: 1501 William Allen Simpson 1502 Daydreamer 1503 Computer Systems Consulting Services 1504 1384 Fontaine 1505 Madison Heights, Michigan 48071 1507 Bill.Simpson@um.cc.umich.edu 1508 bsimpson@MorningStar.com 1509 Table of Contents 1511 1. Introduction .......................................... 1 1512 1.1 Requirements .................................... 2 1513 1.2 Goals ........................................... 3 1514 1.3 Assumptions ..................................... 3 1515 1.4 Specification Language .......................... 3 1516 1.5 Terminology ..................................... 4 1518 2. Agent Discovery ....................................... 6 1519 2.1 Authentication .................................. 7 1520 2.2 Agent Solicitation .............................. 7 1521 2.3 Agent Advertisement ............................. 7 1523 3. Registration .......................................... 9 1524 3.1 Authentication .................................. 9 1525 3.2 UDP .............................................10| 1526 3.3 Registration Request ............................11| 1527 3.4 Registration Reply .............................. 14 1529 4. Mobility Message Extensions ...........................17| 1530 4.1 Mobility Extension ..............................18| 1531 4.2 Authentication Extensions .......................18| 1532 4.3 Minimal Encapsulation Extension .................19| 1534 5. Forwarding Datagrams to the Mobile Node ...............20| 1535 5.1 IP in IP Encapsulation ..........................20| 1536 5.2 Minimal Encapsulation ...........................21| 1537 5.3 Tunneling Management ............................22| 1539 6. Mobile Node Considerations ............................ 24 1540 6.1 Configuration and Registration Tables ........... 24 1541 6.2 Registration When Away From Home ................ 24 1542 6.3 Registration without a Foreign Agent ............ 25 1543 6.4 De-registration When At Home .................... 25 1544 6.5 Registration Replies ............................ 26 1545 6.6 Simultaneous Registrations ...................... 27 1547 7. Foreign Agent Considerations .......................... 27 1548 7.1 Configuration and Registration Tables ........... 27 1549 7.2 Receiving Registration Requests .................28| 1550 7.3 Receiving Registration Replies .................. 28 1552 8. Home Agent Considerations ............................. 29 1553 8.1 Configuration and Registration Tables ........... 29 1554 8.2 Receiving Requests from the Foreign Agent .......29| 1555 8.3 Receiving Requests from the Mobile Node .........30| 1556 8.4 Simultaneous Registrations ...................... 30 1557 8.5 Registration Expiration ......................... 31 1559 APPENDICES ................................................... 32 1561 A. Mobile Networks ....................................... 32 1563 B. Gratuitous and Proxy ARP .............................. 32 1565 C. TCP Timers ............................................ 34 1567 SECURITY CONSIDERATIONS ...................................... 36 1569 REFERENCES ................................................... 37 1571 ACKNOWLEDGEMENTS ............................................. 37 1573 CHAIR'S ADDRESS .............................................. 38 1575 EDITOR'S ADDRESS ............................................. 38