idnits 2.17.1 draft-perkins-mobility-ipv6-00.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-16) 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. == 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. ** 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 252: '... MUST This word, or...' RFC 2119 keyword, line 256: '... MUST NOT This phrase m...' RFC 2119 keyword, line 259: '... SHOULD This word, or...' RFC 2119 keyword, line 266: '... MAY This word, or...' RFC 2119 keyword, line 269: '...nclude this option MUST be prepared to...' (65 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 640 has weird spacing: '...ination copi...' == Line 647 has weird spacing: '...on Port vari...' == Line 829 has weird spacing: '...Address a fo...' -- 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 (27 May 1995) is 10552 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '8' is defined on line 1809, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1541 (ref. '5') (Obsoleted by RFC 2131) ** Obsolete normative reference: RFC 1750 (ref. '6') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 1510 (ref. '9') (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 1305 (ref. '10') (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 1700 (ref. '13') (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '14') -- Possible downref: Non-RFC (?) normative reference: ref. '15' Summary: 16 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Perkins, editor 2 INTERNET DRAFT IBM 3 27 May 1995 5 IPv6 Mobility Support 6 draft-perkins-mobility-ipv6-00.txt 8 Status of This Memo 10 This document is a submission to the IPv6 Working Group of the 11 Internet Engineering Task Force (IETF). Comments should be submitted 12 either to the editor, or to the IPng@sunroof.eng.sun.com mailing 13 list. The proposals contained herein follow as closely as possible 14 the protocol specification under development by the Mobile-IP Working 15 Group of the IETF. However, the editor has submitted this document 16 for consideration in the IPv6 working group without consultation with 17 the Mobile-IP working group at large, as a service to the former 18 group. 20 Distribution of this memo is unlimited. 22 This document is an Internet-Draft. Internet Drafts are working 23 documents of the Internet Engineering Task Force (IETF), its Areas, 24 and its Working Groups. Note that other groups may also distribute 25 working documents as Internet Drafts. 27 Internet Drafts are draft documents valid for a maximum of six 28 months, and may be updated, replaced, or obsoleted by other documents 29 at any time. It is not appropriate to use Internet Drafts as 30 reference material, or to cite them other than as a ``working draft'' 31 or ``work in progress.'' 33 To learn the current status of any Internet-Draft, please check 34 the ``1id-abstracts.txt'' listing contained in the internet-drafts 35 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 36 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 37 Rim). 39 Abstract 41 This document specifies protocol enhancements that allow transparent 42 routing of IPv6 datagrams to mobile nodes in the Internet. Each 43 mobile node is always identified by its home address, regardless of 44 its current point of attachment to the Internet. While situated 45 away from its home, a mobile node is also associated with a 46 care-of address, which provides information about its current point 47 of attachment to the Internet. The protocol provides for registering 48 the care-of address with a home agent. The home agent sends traffic 49 destined for the mobile node through a tunnel to the care-of address. 51 Contents 53 Status of This Memo i 55 Abstract i 57 1. Introduction 1 58 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 2 59 1.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.4. Specification Language . . . . . . . . . . . . . . . . . 3 62 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Agent Discovery 6 65 2.1. Agent Solicitation . . . . . . . . . . . . . . . . . . . 6 66 2.2. Agent Advertisement . . . . . . . . . . . . . . . . . . . 7 68 3. Registration 9 69 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . 10 70 3.2. Registration Request . . . . . . . . . . . . . . . . . . 10 71 3.3. Registration Reply . . . . . . . . . . . . . . . . . . . 12 73 4. Mobility Message Extensions 16 74 4.1. Mobility Extension . . . . . . . . . . . . . . . . . . . 17 75 4.2. Key Identifier Extension . . . . . . . . . . . . . . . . 18 76 4.3. Mobile-Home Authentication Extension . . . . . . . . . . 18 77 4.4. Mobile-Foreign Authentication Extension . . . . . . . . . 19 78 4.5. Foreign-Home Authentication Extension . . . . . . . . . . 20 80 5. Forwarding Datagrams to the Mobile Node 21 81 5.1. IPv6 in IPv6 Encapsulation . . . . . . . . . . . . . . . 21 82 5.2. Minimal Encapsulation . . . . . . . . . . . . . . . . . . 21 84 6. Mobile Node Considerations 24 85 6.1. Configuration and Registration Tables . . . . . . . . . . 24 86 6.2. Registration When Away From Home . . . . . . . . . . . . 24 87 6.3. Registration with a dynamically assigned care-of address 25 88 6.4. Deregistration When At Home . . . . . . . . . . . . . . . 26 89 6.5. Registration Replies . . . . . . . . . . . . . . . . . . 26 90 6.6. Registration Retransmission . . . . . . . . . . . . . . . 27 91 6.7. Simultaneous mobility bindings . . . . . . . . . . . . . 27 92 6.8. Mobile Routers . . . . . . . . . . . . . . . . . . . . . 27 94 7. Foreign Agent Considerations 29 95 7.1. Configuration and Registration Tables . . . . . . . . . . 29 96 7.2. Receiving Registration Requests . . . . . . . . . . . . . 30 97 7.3. Receiving Registration Replies . . . . . . . . . . . . . 30 98 7.4. Decapsulation . . . . . . . . . . . . . . . . . . . . . . 30 100 8. Home Agent Considerations 31 101 8.1. Configuration and Registration Tables . . . . . . . . . . 31 102 8.2. Receiving Registration Requests . . . . . . . . . . . . . 31 103 8.3. Simultaneous mobility bindings . . . . . . . . . . . . . 33 104 8.4. Registration Expiration . . . . . . . . . . . . . . . . . 33 105 8.5. Encapsulation . . . . . . . . . . . . . . . . . . . . . . 33 106 8.6. Broadcast packets . . . . . . . . . . . . . . . . . . . . 34 107 8.7. Multicast packets . . . . . . . . . . . . . . . . . . . . 34 109 9. Security Considerations 35 110 9.1. Message Authentication Codes . . . . . . . . . . . . . . 35 111 9.2. Tunneling to Care-of Addresses . . . . . . . . . . . . . 35 112 9.3. Key management . . . . . . . . . . . . . . . . . . . . . 35 113 9.4. Picking good random numbers . . . . . . . . . . . . . . . 36 114 9.5. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 36 115 9.6. Replay Protection for Registration Requests . . . . . . . 36 116 9.6.1. Replay Protection using Nonces . . . . . . . . . 37 117 9.6.2. Replay Protection using Timestamps . . . . . . . 38 119 10. Acknowledgements 38 121 A. TCP Considerations 39 122 A.1. TCP Timers . . . . . . . . . . . . . . . . . . . . . . . 39 123 A.2. TCP Congestion Management . . . . . . . . . . . . . . . . 39 125 Editor's Address 41 126 1. Introduction 128 Current versions of the Internet Protocol make an implicit assumption 129 that a node's point of attachment remains fixed, and that its IPv6 130 address identifies the network to which it is attached. Datagrams 131 are sent to a node based on the location information contained in the 132 node's IPv6 address. 134 If a node moves while keeping its IPv6 address unchanged, its network 135 number will not reflect its new point of attachment. Existing 136 routing protocols will be unable to route datagrams to it correctly. 138 This document defines new functions that allow a node to roam on the 139 Internet, without changing its IPv6 address. 141 The following entities are defined: 143 Mobile Node 145 A host or router that changes its point of attachment from one 146 network or subnetwork to another. 148 Home Agent 150 A router that maintains a registry of the current mobility 151 bindings for that mobile node, and encapsulates datagrams for 152 delivery to the mobile node while it is away from home. 154 Foreign Agent 156 A router that assists a locally reachable mobile node that is 157 away from its home network. 159 Care-of Address 161 The care-of address terminates the end of a tunnel toward a 162 mobile node. Depending on the network configuration, the 163 care-of address may be either dynamically assigned to the 164 mobile node or associated with a foreign agent. 166 The following support services are defined: 168 Agent Discovery 170 Home agents and foreign agents advertise their availability 171 on each link for which they provide service. A newly arrived 172 mobile node can send a solicitation on the link to learn if any 173 prospective agents are present. 175 Registration 177 When the mobile node is away from home, it registers its 178 care-of address with its home agent. Depending on its method 179 of attachment, the mobile node will register either directly 180 with its home agent, or through a foreign agent which forwards 181 the registration to the home agent. 183 Encapsulation 185 Encapsulation, as used in this draft, means the process of 186 enclosing the data within an IPv6 datagram inside another IPv6 187 header. This process is also known as "tunneling", since 188 it can be used to hide the original IPv6 header information 189 during delivery to the new IPv6 destination specified in the 190 encapsulated datagram. 192 The enclosing IPv6 header can (and usually will) contain a 193 IPv6 destination address, and/or IPv6 source address, and/or 194 different protocol field which differs from the original IPv6 195 header. 197 Decapsulation 199 Decapsulation is the inverse process to encapsulation. At 200 the destination, the enclosed datagram is extracted by 201 removing the encapsulating IPv6 header, and possibly creating 202 a new IPv6 header based on the information available in 203 the encapsulating IPv6 header and the data that had been 204 encapsulated. Typically, after decapsulating the resulting 205 datagram may be delivered to another destination. 207 1.1. Requirements 209 A mobile node using its home address shall be able to communicate 210 with other nodes after having been disconnected from the Internet, 211 and then reconnected at a different point of attachment. 213 Implementation of the protocol described in this document shall not 214 adversely affect a mobile node's capability to communicate with other 215 nodes that do not implement these mobility functions. No protocol 216 enhancements are required in hosts or routers that are not serving 217 any of the mobility functions. 219 A mobile node shall provide authentication in its registration 220 messages, ad described in subsection 3.1. 222 1.2. Goals 224 The mobile node's directly attached link is likely to be bandwidth 225 limited. Only a few administrative messages should be sent between a 226 mobile node and an agent. The size of these messages should be kept 227 as short as possible. 229 As few messages as possible which duplicate functionality are sent 230 on mobile links. This is particularly important on wireless and 231 congested links. 233 1.3. Assumptions 235 The protocols defined in this document place no additional 236 constraints on assignment of IPv6 addresses. That is, a mobile node 237 can be assigned an IPv6 address by the organization that owns the 238 machine, and will be able to use that IPv6 address regardless of the 239 current point of attachment. 241 It is assumed that mobile nodes will not change their point of 242 attachment to the Internet more frequently than once per second. 244 It is assumed that IPv6 unicast datagrams are routed based on the 245 destination address in the datagram header. 247 1.4. Specification Language 249 In this document, several words are used to signify the requirements 250 of the specification. These words are often capitalized. 252 MUST This word, or the adjective "required", means 253 that the definition is an absolute requirement 254 of the specification. 256 MUST NOT This phrase means that the definition is an 257 absolute prohibition of the specification. 259 SHOULD This word, or the adjective "recommended", 260 means that there may exist valid reasons in 261 particular circumstances to ignore this item, 262 but the full implications must be understood 263 and carefully weighed before choosing a 264 different course. 266 MAY This word, or the adjective "optional", means 267 that this item is one of an allowed set of 268 alternatives. An implementation which does 269 not include this option MUST be prepared to 270 interoperate with another implementation which 271 does include the option. 273 silently discard The implementation discards the packet without 274 further processing, and without indicating an 275 error to the sender. The implementation SHOULD 276 provide the capability of logging the error, 277 including the contents of the discarded packet, 278 and SHOULD record the event in a statistics 279 counter. 281 1.5. Terminology 283 This document frequently uses the following terms: 285 Agent Advertisement 287 A periodic advertisement constructed by attaching a special 288 extension to a router advertisement [15] message. 290 Correspondent 292 A peer with which a mobile node is communicating. The 293 correspondent may be either mobile or stationary. 295 Home Address 297 A long-term IPv6 address that is assigned to a mobile node. 298 It remains unchanged regardless of where the node is attached 299 to the Internet. Datagrams addressed to the home address 300 are intercepted by the home agent while the mobile node is 301 registered with that home agent. 303 Link 305 A communication facility or medium over which nodes can 306 communicate at the link layer; a link underlies the network 307 layer. 309 Link-Layer Address 311 The address used to identify the endpoints of the communication 312 over a physical link. Also commonly known as a MAC address. 314 Mobility Agent 316 Either a home agent or a foreign agent. 318 Mobility Binding 320 The association of a home address with a care-of address, and 321 the remaining lifetime of the association. 323 Mobility Security Association 325 The mobility security association between a pair of nodes 326 identifies the security context to be applied to Mobile IPv6 327 protocol messages which they exchange. This relationship 328 includes the authentication type (i.e., algorithm and algorithm 329 mode), the secret (such as a shared key, or appropriate 330 public/private key pair), and information about the style 331 of replay protection in use. Note that a single algorithm 332 (such as DES) might have several modes (for example, CBC and 333 ECB)(see [11], [9]). 335 2. Agent Discovery 337 To communicate with a foreign or home agent, a mobile node must learn 338 either the IPv6 address or the link address of that agent. It is 339 assumed that a link-layer connection has been established between 340 the agent and the mobile node. The method used to establish such 341 a link-layer connection is not specified in this document. After 342 establishing a link-layer connection, the mobile node learns whether 343 there are any agents available. If the address of any agent matches 344 the mobile node's stored address for its home agent, the mobile node 345 is at home. 347 An agent which is not indicated by a link-layer protocol MUST 348 implement IPv6 Router Discovery [15]. The router advertisements 349 indicate whether the router is also a home agent or a foreign agent. 351 When multiple methods of agent identification are in use, the 352 mobile node SHOULD first attempt registration with routers sending 353 router advertisements in preference to those sending link-layer 354 advertisements. This ordering maximizes the likelihood that the 355 registration will be recognized, thereby minimizing the number of 356 registration attempts. 358 No authentication is required for the advertisement and solicitation 359 process. These messages MAY be authenticated using the IP 360 Authentication Header [1], which is external to the messages 361 described here. Further specification of authentication of 362 advertisement and solicitation is outside of the scope of this 363 document. 365 There is the potential for a key management problem: 367 - if the Mobile Node doesn't know the authentication type and key 368 used by the advertiser. 369 - if the Foreign Agent doesn't know the authentication type and key 370 used by the Mobile Host. 372 This key management issue is simplified when asymmetric 373 authentication algorithms are used, because each node's public 374 authentication key can published without enabling masquerading 375 attacks. However, asymmetric algorithms are often more 376 computationally intensive than symmetric algorithms. 378 2.1. Agent Solicitation 380 Every mobile node MUST implement ICMP Router Solicitation [15]. if 381 it needs to obtain a care-of address in an agent advertisement. 383 However, the solicitation is only sent when no care-of address 384 has been determined through a link-layer protocol or prior router 385 advertisement. Any mobility agent which is not identified by 386 a link-layer protocol MUST respond to ICMP Router Solicitation. 387 Mobility agents SHOULD respond to ICMP Router Solicitation. 389 The same procedures, defaults, and constants are used as described 390 in Neighbor Discovery [15], except that the mobile node may solicit 391 more often than once every three seconds and MAX_SOLICITATIONS does 392 not apply for mobile nodes that are currently unconnected to any 393 foreign agent. A mobile node MAY send a solicitation once each 394 MOBILE_SOLICITATION_INTERVAL (1 second) until the solicitation is 395 answered by a mobility agent, and the mobile node can finally issue a 396 registration request. 398 2.2. Agent Advertisement 400 Mobile nodes must process ICMP router advertisements[15]. Any 401 mobility agent which is not indicated by a link-layer protocol MUST 402 send ICMP Router Advertisements. An agent which is indicated by a 403 link-layer protocol SHOULD also implement router advertisements. 404 However, the advertisements need not be sent, except when the site 405 policy requires registration with the agent, or as a response to a 406 specific solicitation. 408 ICMP router advertisements that carry the required Mobility 409 Extension (subsection 4.1) are called agent advertisements in this 410 document, and can be identified by examining the number of advertised 411 addresses. When the IPv6 total length indicates that the ICMP 412 message is longer than needed for the number of addresses present, 413 the remaining data is interpreted as extensions. The extensions are 414 described in section 4. Other extensions may indicate optionally 415 supported features. 417 The same procedures, defaults, and constants are used as described in 418 "IPv6 Neighbor Discovery -- ICMP Message Formats" [15]. except as 419 specified herein; a foreign agent MUST NOT send agent advertisements 420 more often than once per second. 422 The sequence number in agent advertisements ranges from 0 to 423 0xffff. After booting, an agent shall use the number 0 for its first 424 advertisement. Each subsequent advertisement shall use the sequence 425 number one greater, with the exception that the sequence number 426 0xffff shall be followed by sequence number 256. In this way, mobile 427 clients can distinguish reductions in sequence numbers that result 428 from reboots, from reductions that result in rollover of the sequence 429 number after it attains the value 0xffff. 431 The Code field of the ICMP router advertisement is interpreted as 432 follows: 434 0 The router handles common traffic -- that is, IPv6 data 435 packets not necessarily related to mobile nodes. 437 16 A home or foreign agent which supports registration, but is 438 not routing common traffic. 440 3. Registration 442 The registration function exchanges information between a mobile 443 node and its home agent. Registration creates a mobility binding, 444 associating the mobile node's home address with a care-of address 445 which can be used to reach the mobile node. 447 When it has been dynamically assigned a care-of address, a mobile 448 node can act without a foreign agent, and register or deregister 449 directly with a home agent by the exchange of only 2 messages: 451 a) The mobile node sends a registration request to a home agent, 452 asking it to provide service. 454 b) The home agent sends a registration reply to the mobile node, 455 granting or denying service. 457 When the care-of address is associated with a foreign agent, the 458 foreign agent acts as a relay between the mobile node and home 459 agent. This extended registration process involves the exchange of 4 460 messages: 462 a) The mobile node sends a registration request to the prospective 463 foreign agent to begin the registration process. 465 b) The foreign agent relays the request to the home agent, asking it 466 to provide service to the mobile node. 468 c) The home agent sends a registration reply to the foreign agent to 469 grant or deny service. 471 d) The foreign agent relays the registration reply to the mobile 472 node to inform it of the disposition of its request. 474 The registration messages defined in this section(3.2, 3.3) use the 475 User Datagram Protocol header [12]. A nonzero UDP checksum SHOULD be 476 included in the header, and checked by each recipient. 478 An administrative domain MAY require a visiting mobile node to 479 register via a foreign agent (see the description of the "R" bit, in 480 subsection 4.1). This facility is envisioned for service providers 481 with packet filtering fire-walls, or visiting policies (such as 482 accounting) which require exchanges of authorization. 484 3.1. Authentication 486 Each mobile node, foreign agent, and home agent MUST support 487 the maintenance of an internal table holding a list of security 488 associations for mobile entities, indexed by their IPv6 address. See 489 section 9.1 for support requirements for authentication algorithms. 490 Only one mobility security association at a time is in effect between 491 any given pair of participating nodes. Whenever a mobility security 492 association exists between a pair of nodes, all registration messages 493 between these nodes MUST be authenticated. 495 In particular, registration messages between mobile node and 496 home agent are required to be authenticated with the Mobile-Home 497 Authentication Extension (subsection 4.3). This extension 498 immediately follows all non-authentication extensions, except those 499 foreign agent specific extensions which may be added to the packet 500 after the mobile node computes the authentication. 502 3.2. Registration Request 504 A mobile node sends a registration request message so that its home 505 agent can create a new mobility binding for that mobile node (with a 506 new lifetime). The request may be relayed to the home agent by the 507 foreign agent from which the mobile node is accepting service, or it 508 may be sent directly in case the mobile node has received a temporary 509 care-of address by some other means (e.g, DHCP [5]). 511 IPv6 fields: 513 Source For registering with a foreign agent whose IPv6 514 address is known, the source address of Registration 515 Request from the mobile node to the foreign agent 516 is the IPv6 address of the interface from which the 517 packet is sent. For registering without a foreign 518 agent, the source address on the registration 519 request MUST be the temporary address that has been 520 acquired by the mobile node for its care-of address. 522 Destination When the IPv6 address is unknown (the agent was 523 discovered via a link-layer protocol), the "All 524 Mobility Agents" multicast address (224.0.0.11) is 525 used. The link-layer unicast address is used to 526 deliver the datagram to the correct agent. 528 For registering with a foreign agent, the 529 Registration Request from the mobile node to the 530 foreign agent should have the destination address of 531 the foreign agent, copied from the source address 532 of the Agent Advertisement in which the mobile node 533 learned of that foreign agent. The foreign agent 534 then sends the Registration Request to the home 535 agent, using the destination address copied from the 536 Home Agent field of the Registration Request 538 For registering without a foreign agent, the 539 destination address should be the address that the 540 mobile node uses for its home agent. 542 UDP fields: 544 Source Port variable 546 Destination Port 434 548 The UDP header is followed by the Mobile-IPv6 fields shown below: 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Type |S|B|F|M|G|rsvd | Lifetime | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | | 556 | Home Address | 557 | | 558 | | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | | 561 | Home Agent | 562 | | 563 | | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | | 566 | Care-of Address | 567 | | 568 | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Identification | 571 | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Extensions ... 574 |-+-+-+-+-+-+-+- 576 Type 1, for version 1 of this protocol 577 S If the 'S' bit is set, the mobile client is 578 requesting that the home agent retain its prior 579 mobility bindings. In this way, the mobile 580 client can be registered at multiple care-of 581 addresses. 583 B If the 'B' bit is set, the mobile client 584 requests that the home agent send to it, 585 all broadcasts on the home network. See 586 subsection 8.6 for a full discussion. 588 F If the 'F' bit is set, the mobile client is 589 registering with a dynamically assigned care-of 590 address it has obtained. This typically implies 591 that the mobile host will decapsulate datagrams 592 which are sent to the care-of address. 594 M If the 'M' bit is set, the mobile node requests 595 home agent to encapsulate using minimal 596 encapsulation (section 5.2) 598 G If the 'G' bit is set, the mobile node 599 requests home agent to encapsulate using GRE 600 encapsulation ([7]). 602 Lifetime The number of seconds remaining before the 603 registration is considered expired. A value of 604 zero indicates a request for deregistration. A 605 value of all ones indicates infinity. 607 Home Address The IPv6 address of the mobile node. 609 Home Agent The IPv6 address of a home agent. 611 Care-of Address The IPv6 address for the decapsulation end of a 612 tunnel. 614 Identification A 64-bit number, constructed by the mobile 615 node, used to assist in matching requests with 616 replies, and in protecting against replay 617 attacks (see subsections 9.4, 9.6). 619 3.3. Registration Reply 621 The registration reply message is returned by a home agent to a 622 mobile node which has sent a registration request (subsection 3.2) 623 message. If the mobile node is accepting service from a foreign 624 agent, that foreign agent will receive the reply from the home 625 agent and subsequently relay it to the mobile node. The reply 626 message contains the necessary codes to inform the mobile node about 627 the status of its request, along with the lifetime granted by the 628 home agent, which MAY be smaller than the original request. See 629 subsection 8.2 for details regarding the selection of the reply 630 identification. When the lifetime of the reply is greater than 631 the original request, the excess time MUST be ignored. When the 632 lifetime of the reply is smaller than the original request, another 633 registration SHOULD occur before the lifetime expires. 635 IPv6 fields: 637 Source copied from the destination address of the 638 Registration Request to which the agent is replying 640 Destination copied from the source address of the Registration 641 Request to which the agent is replying 643 UDP fields: 645 Source Port variable 647 Destination Port variable, depending upon the source port of the 648 request 650 A foreign agent that has received a registration request message 651 must save the IPv6 source address and the UDP source port from that 652 message so that it will be able to send the subsequent registration 653 reply message to the correct UDP port on the mobile node. 655 The UDP header is followed by the Mobile-IPv6 fields shown below: 657 0 1 2 3 658 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 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Type | Code | Lifetime | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | | 663 | Home Address | 664 | | 665 | | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | | 668 | Home Agent | 669 | | 670 | | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Identification | 673 | | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Extensions ... 676 +-+-+-+-+-+-+-+- 678 Type 3 680 Code One of the following codes: 682 0 service will be provided 683 1 service will be provided; simultaneous 684 mobility bindings unsupported 686 Service denied by the foreign agent: 688 16 reason unspecified 689 17 administratively prohibited 690 18 insufficient resources 691 19 mobile node failed authentication 692 20 home agent failed authentication 693 21 requested lifetime too long 694 22 home agent unreachable (ICMP error) 695 23 poorly formed request 696 24 poorly formed reply 698 Service denied by the home agent: 700 32 reason unspecified 701 33 administratively prohibited 702 34 insufficient resources 703 35 mobile node failed authentication 704 36 foreign agent failed authentication 705 37 identification mismatch 706 38 poorly formed request 707 39 too many simultaneous mobility bindings 709 Up-to-date values of the Code field are specified 710 in the most recent "Assigned Numbers" [13]. 712 Lifetime The seconds remaining before the registration is 713 considered expired. A value of zero confirms a 714 request for deregistration. A value of all ones 715 indicates infinity. 717 Home Address The IPv6 address of the mobile node. 719 Home Agent The IPv6 address of a home agent. 721 Identification The registration identification is derived from 722 the request message, for use by the mobile 723 node in matching its reply with an outstanding 724 request. 726 4. Mobility Message Extensions 728 Each message begins with a short fixed part, followed by one or more 729 mobility message extensions in type-length-value format. These 730 extensions may apply to agent advertisement messages (subsection 2.2) 731 and registration messages (section 3). 733 0 1 2 734 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 736 | Extension | Length | Data ... 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 739 Extension 741 Current values are assigned as follows: 743 16 Mobility 744 18 Key Identifier 745 32 Mobile-Home Authentication 746 33 Mobile-Foreign Authentication 747 34 Foreign-Home Authentication 749 Up-to-date values are specified in the most recent "Assigned 750 Numbers" [13]. 752 Length 754 Indicates the length (in bytes) of the data field. The length 755 does not include the Extension and Length bytes. 757 Data 759 This field is zero or more bytes in length and contains the 760 value(s) for this extension. The format and length of the data 761 field is determined by the extension and length fields. 763 Extensions allow variable amounts of information to be carried within 764 each datagram. The end of the list of extensions is indicated by the 765 total length of the IPv6 datagram. 767 When an extension numbered in the range 0-127 is encountered but not 768 recognized, the packet containing the extension must be dropped. 769 When an extension numbered in the range 128-255 is encountered which 770 is not recognized, that particular extension is ignored, but the rest 771 of the packet data can still be processed. The length field of the 772 extension is used to skip the data field in searching for the next 773 extension. 775 4.1. Mobility Extension 777 The Mobility Extension is used to indicate that a router 778 advertisement message is actually an agent advertisement being sent 779 by a mobility agent (see subsection 2.2). When foreign agents cannot 780 accept new requests for service from mobile clients, they will set 781 the Busy bit; if the Busy bit is turned off, the agent may attract 782 new mobile clients. An agent which wishes to serve as a foreign 783 agent, sets the 'F' bit in the mobility extension; likewise an 784 agent which wishes to serve as a home agent sets the 'H' bit in the 785 mobility extension. Any home agent must always be prepared to serve 786 its mobile clients; it is an error to have the 'B' bit set without 787 also having the 'F' bit set. When the 'R' bit is set to 1, the 788 mobile node SHOULD register through the foreign agent, even when the 789 mobile node has acquired a transient care-of address. 791 0 1 2 3 792 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 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Extension | Length | Sequence Number | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Lifetime |R|B|H|F|M|G| reserved | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | zero or more Care-of Addresses | 799 | ... | 801 Extension 16 803 Length (6 + 16*N), where N is the number of 804 care-of addresses advertised. 806 Sequence number The count of advertisement messages sent since 807 the agent was initialized (see section 2.2). 809 Lifetime The longest lifetime (measured in seconds) 810 that the agent is willing to accept in any 811 registration request. A value of all ones 812 indicates infinity. 814 R Foreign agent registration required bit. 816 B Busy bit. The foreign agent is not willing to 817 accept any more registrations. 819 H Agent offers service as a home agent. 821 F Agent offers service as a foreign agent. 823 M Agent offers minimal encapsulation (section 5.2) 825 G Agent offers GRE encapsulation (see [7]). 827 reserved Sent as zero; ignored on reception. 829 Care of Address a foreign agent's care-of addresses 831 DISCUSSION: Should the agent advertisement include the subnet 832 prefix(es) of the medium to which the mobile client 833 is attached? 835 4.2. Key Identifier Extension 837 The key identifier extension is found in registration requests 838 (see subsection 3.2). This extension informs the home agent that 839 authentication is performed using a cryptographic key or algorithm 840 different than the home agent would use by default. If a home 841 agent receives a registration request which does not contain this 842 extension, the home agent must assume that the mobile node used 843 the default Message Authentication Code (see subsection 9.1) to 844 authenticate the registration. 846 0 1 2 3 847 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 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Extension | Length | Key Identifier | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 Extension 18 854 Length 2 856 reserved Sent as zero; ignored on reception. 858 Key Identifier 860 The key identifier may be chosen from a list which is privately 861 configured between the home agent and the mobile node. In this case, 862 the identifier is completely opaque; the cryptographic algorithm to 863 be used cannot be determined from the value of the key identifier. 865 4.3. Mobile-Home Authentication Extension 867 This extension must be present in all registration requests and 868 replies, and is intended to eliminate problems([2]) which result from 869 the uncontrolled propagation of remote redirects in the Internet. 870 See subsection 9.1 for information about support requirements for 871 message authentication codes, etc. 873 0 1 2 3 874 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 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Extension | Length | Authenticator ... 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 Extension 32 881 Length The number of data bytes in the extension. 883 Authenticator (variable length) A value computed from a 884 stream of bytes including the shared secret, the 885 destination port number from the UDP header, 886 the UDP payload (that is, the registration 887 request or reply data), all prior extensions in 888 their entirety, and the type and length of this 889 extension, but not including the Authenticator 890 field itself. 892 4.4. Mobile-Foreign Authentication Extension 894 This extension may be found in registration requests and replies 895 where a security association exists between the mobile node and a 896 foreign agent. See subsection 9.1 for information about support 897 requirements for message authentication codes, etc. 899 0 1 2 3 900 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 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 902 | Extension | Length | Authenticator ... 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 Extension 33 907 Length The number of data bytes in the extension. 909 Authenticator (variable length) A value computed from a 910 stream of bytes including the shared secret, the 911 destination port number from the UDP header, 912 the UDP payload (that is, the registration 913 request or reply data), all prior extensions in 914 their entirety, and the type and length of this 915 extension, but not including the Authenticator 916 field itself. 918 DISCUSSION: How can the Key Identifier extension be used? 920 4.5. Foreign-Home Authentication Extension 922 This extension may be found in registration requests and replies 923 where a security association exists between the foreign agent and 924 a home agent. See subsection 9.1 for information about support 925 requirements for message authentication codes, etc. 927 0 1 2 3 928 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 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Extension | Length | Authenticator ... 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 Extension 34 935 Length The number of data bytes in the extension. 937 Authenticator (variable length) A value computed from a 938 stream of bytes including the shared secret, the 939 destination port number from the UDP header, 940 the UDP payload (that is, the registration 941 request or reply data), all prior extensions in 942 their entirety, and the type and length of this 943 extension, but not including the Authenticator 944 field itself. 946 DISCUSSION: How can the Key Identifier extension be used? 948 5. Forwarding Datagrams to the Mobile Node 950 5.1. IPv6 in IPv6 Encapsulation 952 Support for IPv6 in IPv6 encapsulated datagrams is required in 953 home agents and foreign agents, and any mobile node which has been 954 dynamically assigned its own care-of address. When a datagram is 955 already fragmented prior to encapsulating, IPv6 in IPv6 is used. 957 An outer IPv6 header is inserted before the datagram's IPv6 header: 959 +---------------------------+ 960 | Outer IPv6 Header | 961 +---------------------------+ +---------------------------+ 962 | IPv6 Header | | IPv6 Header | 963 +---------------------------+ ====> +---------------------------+ 964 | | | | 965 | IPv6 Payload | | IPv6 Payload | 966 | | | | 967 +---------------------------+ +---------------------------+ 969 The format of the IPv6 header is described in "Internet Protocol, 970 Version 6 (IPv6) Specification"[8]. The outer IPv6 header source 971 and destination addresses identify the "endpoints" of the tunnel. 972 The inner IPv6 header source and destination addresses identify the 973 sender and recipient of the datagram. 975 The protocol field in the outer IPv6 header is set to protocol number 976 6 for the encapsulation protocol. The destination field in the outer 977 IPv6 header is set to the care-of address of the mobile node. The 978 source field in the outer IPv6 header is set to the IPv6 address of 979 the encapsulating agent. 981 When the datagram is encapsulated, the Time To Live (TTL) field 982 in the outer IPv6 header is set to be the same as the original 983 datagram. When decapsulating, the outer TTL minus one is inserted 984 into the inner IPv6 TTL. Thus, hops are counted, but the actual 985 routers interior to the tunnel are not identified. This provides 986 loop protection. 988 5.2. Minimal Encapsulation 990 A minimal forwarding header is defined for datagrams which are not 991 fragmented prior to encapsulating. Use of this encapsulating method 992 is optional. Minimal encapsulation must not be used when an original 993 datagram is already fragmented. 995 A foreign agent which is capable of decapsulating the minimal header 996 includes the 'M' bit (subsection 4.1) in its agent advertisements. 997 A mobile node, after receiving this indication in an agent 998 advertisement, indicates the capability of decapsulating the minimal 999 header at the care-of address by setting the 'M' bit (subsection 3.2) 1000 in its registration request. A mobile node MUST NOT set this bit 1001 unless its foreign agent has advertised support for it. The use of 1002 the minimal header is entirely at the discretion of the home agent. 1003 Similar considerations hold for use of GRE encapsulation and setting 1004 the 'G' bit (subsections 4.1, 3.2) 1006 The minimal encapsulation process produces a datagram structured as 1007 shown below; the IPv6 header of the original datagram is modified, 1008 then followed by the minimal forwarding header, followed by the 1009 unmodified IPv6 payload of the original datagram. 1011 +---------------------------+ +---------------------------+ 1012 | IPv6 Header | | Modified IPv6 Header | 1013 +---------------------------+ ====> +---------------------------+ 1014 | | | Minimal Forwarding Header | 1015 | IPv6 Payload | +---------------------------+ 1016 | | | | 1017 +---------------------------+ | IPv6 Payload | 1018 | | 1019 +---------------------------+ 1021 Encapsulation is performed as follows. The protocol field in 1022 the IPv6 header is replaced by protocol number 55 for the minimal 1023 encapsulation protocol. The destination field in the IPv6 header 1024 is replaced by the care-of address of the mobile node. If the 1025 encapsulating agent is not the original source of the datagram, the 1026 source field in the IPv6 header is replaced by the IPv6 address of 1027 the encapsulating agent. 1029 When decapsulating a datagram, the fields in the forwarding header 1030 are restored to the IPv6 header, and the forwarding header is removed 1031 from the datagram. 1033 The format of the minimal forwarding header is as follows: 1035 0 1 2 3 1036 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 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Protocol |S| reserved | Header Checksum | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | | 1041 + Home Address + 1042 | | 1043 + + 1044 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 1045 : : 1046 : Correspondent Source Address : 1047 : : 1048 : : 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 Protocol 1053 Copied from the protocol field in the original IPv6 header. 1055 S 1057 Source field present bit, which indicates that the 1058 Correspondent Source Address field is present. 1060 0 not present. 1061 1 present. 1063 reserved 1065 Sent as zero; ignored on reception. 1067 Header Checksum 1069 The 16-bit one's complement of the one's complement sum of the 1070 encapsulation header. For computing the checksum, the checksum 1071 field is set to 0. 1073 Home Address 1075 Copied from the destination field in the original IPv6 header. 1077 Correspondent Source Address 1079 Copied from the source field in the original IPv6 header. 1080 Present only if the S-bit is set. 1082 6. Mobile Node Considerations 1084 A mobile node listens for agent advertisements at all times that 1085 it has a link connection. In this manner, it can learn that its 1086 foreign agent has changed, or that it has arrived home. Whenever a 1087 mobile node detects such a change in its network connectivity, it 1088 should initiate the registration process. When it is away from home, 1089 the mobile node's (de)registration request allows its home agent to 1090 create a mobility binding, (see subsections 3.2, 2.2). When it is at 1091 home, the mobile node's registration request allows its home agent 1092 to erase any previous mobility binding (subsection 6.4). A mobile 1093 node operates without the support of mobility functions when it is at 1094 home. 1096 A mobile node MUST NOT register with a new foreign agent because 1097 it has received an ICMP Redirect from the foreign agent that is 1098 currently providing service to it. 1100 6.1. Configuration and Registration Tables 1102 A mobile node must be configured with: 1104 - home address 1105 - mobility security association for each home agent 1107 In addition, a mobile node may be configured with the address of one 1108 or more of its home agents. For each pending registration: 1110 - link-layer address of foreign agent, if applicable 1111 - care-of address 1112 - registration identification 1113 - lifetime 1115 6.2. Registration When Away From Home 1117 In the absence of link-layer indications of changes in point of 1118 attachment, agent advertisements from new agents do not necessarily 1119 affect a current registration. In the absence of link-layer 1120 indications, a mobile node MUST NOT attempt to register more 1121 often than once per second. A mobile node may register with a 1122 different agent when transport-layer protocols indicate excessive 1123 retransmissions. Within these constraints, the mobile node MAY 1124 register again at any time. 1126 If a mobile node detects two successive values of the sequence number 1127 in the agent advertisement, the second of which is less than the 1128 first and inside the range 0 to 255, the mobile node MUST register 1129 again. If the second value is less than the first, but greater than 1130 or equal to 256, the mobile node may assume that the sequence number 1131 has rolled over past its maximum value (0xffff), and that there is no 1132 need to re-register (see subsection 2.2). 1134 If the mobile node does not know the address of any of its 1135 home agents, it may send a registration request is sent to the 1136 directed broadcast address of the home network. In this case, any 1137 registration reply that is returned to the mobile node will contain a 1138 valid address for a home agent, so that the mobile node can re-issue 1139 the registration request with the correct home agent address if 1140 necessary. 1142 A mobile node SHOULD NOT request a lifetime for its registration that 1143 exceeds the lifetime learned in an agent advertisement. When the 1144 method by which the care-of address is learned does not include a 1145 lifetime, the default router advertisement lifetime (1800 seconds) 1146 may be used. The lifetime MAY be modified by the home agent in its 1147 reply. A mobile node SHOULD register again before the lifetime of 1148 its registration expires. A mobile node MAY ask a home agent to 1149 terminate forwarding service to a particular care-of address, by 1150 sending a registration with a lifetime of zero (see subsection 8.2). 1152 The mobile node SHOULD construct its registration identification by 1153 concatenating another value of its own choice to the most recent 1154 nonce received from its home agent. This value in the low order 32 1155 bits of the identification can be another nonce, or a duplicate of 1156 the nonce received from the home agent (see subsection 9.6.1). 1158 6.3. Registration with a dynamically assigned care-of address 1160 In cases where a mobile node away from home is able to dynamically 1161 acquire a transient IPv6 address (e.g, via DHCP [5]), the mobile 1162 node can serve without a foreign agent, using the transient address 1163 as the care-of address. Then all communication between the mobile 1164 node and its home agent can proceed without the intervention of 1165 foreign agents. This eliminates the need to deploy foreign agents as 1166 separate entities. This feature MUST NOT be used unless the mobile 1167 node has mechanisms to detect changes in its link-layer connectivity, 1168 and can initiate acquisition of a new transient address each time 1169 such a change occurs. The lifetime of such a registration is chosen 1170 by the mobile node. 1172 When the mobile node is away from home and detects a foreign agent 1173 advertisement that has the "R" bit (registration required) set in 1174 the Mobility Extension (see subsection 2.2), the mobile node SHOULD 1175 register through an appropriate foreign agent, even when it has 1176 obtained a dynamically assigned care-of address. 1178 6.4. Deregistration When At Home 1180 When a mobile node is attached to its home link, it will no longer 1181 need any forwarding service from its home agent. A deregistration 1182 procedure SHOULD be used between the mobile node and its home 1183 agent. The deregistration process involves the exchange of only two 1184 messages: 1186 a) The mobile node sends a registration request directly to its home 1187 agent, with the lifetime set to zero, and the Code field set to 1188 0, to indicate that the home agent remove all related entries. 1189 The care-of address is set to the home address. 1191 b) The home agent sends a registration reply to the mobile node to 1192 indicate the success or failure of the mobile node's attempted 1193 deregistration. 1195 A mobile node on its home network need not register again with a home 1196 agent when a change of sequence number occurs, or the advertisement 1197 lifetime expires, or even when the home agent crashes, since it isn't 1198 seeking service from the home agent. 1200 6.5. Registration Replies 1202 To be accepted, the reply must match the registration identification 1203 of its most recent registration request to the sender; otherwise, the 1204 message is silently discarded. If nonces are in use, the mobile node 1205 records the first 32 bits for use in its next registration request; 1206 otherwise, if timestamps are in use, the entire 64 bit field may be 1207 used for identification (see subsection 9.6). 1209 When a reply is received which has a code indicating rejection by 1210 the foreign agent, the Mobile-Home Authenticator will be missing or 1211 invalid. If a later authenticated reply is received, and if the 1212 previous registration is remembered, that later reply supersedes the 1213 unauthenticated reply. Otherwise, when a reply is received with 1214 an invalid authenticator, the message is silently discarded. The 1215 mobile node is not required to issue any message in response to a 1216 registration reply. 1218 6.6. Registration Retransmission 1220 When no reply has been received within a reasonable time, another 1221 registration request is transmitted. When timestamps are used, a 1222 new registration identification is chosen for each retransmission; 1223 thus it counts as a new registration. When nonces are used, the 1224 unanswered request is retransmitted unchanged. (See subsection 9.6) 1226 The maximum time until a new registration request is sent SHOULD be 1227 no greater than the requested lifetime of the registration request. 1228 The minimum value SHOULD be large enough to account for the size 1229 of the packets, twice the round trip time for transmission at the 1230 link speed, and at least an additional 100 milliseconds to allow 1231 for processing the packets before responding. Some circuits add 1232 another 200 milliseconds of satellite delay. The minimum time 1233 between registration requests MUST NOT be less than 1 second. Each 1234 successive wait SHOULD be at least twice the previous wait, as long 1235 as that is less than the maximum. 1237 6.7. Simultaneous mobility bindings 1239 Multiple simultaneous mobility bindings are likely to be useful when 1240 a mobile node moves within range of multiple cellular systems. IPv6 1241 explicitly allows duplication of datagrams. When the home agent 1242 allows simultaneous bindings, it will encapsulate a separate copy of 1243 each arriving datagram to each care-of address, and the mobile node 1244 will receive multiple copies of its datagrams. 1246 In order to request this optional capability, the mobile node sends 1247 the registration request with the Code set to 1. The return code 1248 in the registration reply is the same. No error occurs if the home 1249 agent is unable to fulfill the request. When the need for multiple 1250 mobility bindings has passed, the mobile node SHOULD register again 1251 with the Code set to 0, to remove the other bindings. 1253 6.8. Mobile Routers 1255 A mobile node can be a router, which is responsible for the mobility 1256 of one or more entire networks moving together, perhaps on an 1257 airplane, a ship, a train, an automobile, a bicycle, or a kayak. 1258 The nodes connected to a network served by the mobile router may 1259 themselves be fixed nodes or mobile nodes or routers. In this 1260 subsection, such networks are called "mobile networks". 1262 A mobile router may provide a care-of address to mobile nodes 1263 connected to the mobile network. In this case, when a correspondent 1264 host sends a packet to the mobile node, the following actions should 1265 occur. 1267 Normal routing procedures will route the packet addressed to the 1268 mobile node from the correspondent host to the mobile node's home 1269 agent. This home agent's binding for the mobile node causes it to 1270 tunnel the packet to the mobile router. Normal routing procedures 1271 will route the packet from this home agent to the mobile router's 1272 home agent. That home agent's binding for the mobile router causes 1273 the packet to be doubly tunneled to the mobile router's care-of 1274 address. For the sake of discussion, assume there is a foreign agent 1275 available at that care-of address. 1277 The mobile router's foreign agent will then detunnel the packet 1278 and use its visitor list entry to deliver the packet to the mobile 1279 router. The mobile router will then detunnel the packet and use its 1280 visitor list entry to deliver the packet finally to the mobile node. 1282 If a fixed node is connected to a mobile network then either of two 1283 methods may be used to cause packets from correspondent hosts to be 1284 routed to the fixed node. 1286 A home agent may be configured that has a permanent registration for 1287 the fixed node that indicates the mobile router's address as the 1288 fixed host's care-of address. The mobile router's home agent will 1289 usually be used for this purpose. The home agent is then responsible 1290 for advertising connectivity using normal routing protocols to 1291 the fixed node. Any packets sent to the fixed node will thus use 1292 recursive tunneling as described above. 1294 Alternatively, the mobile router may advertise connectivity to the 1295 fixed node using normal routing protocols through its own home agent. 1296 This method avoids the need for recursive tunneling of packets. 1298 7. Foreign Agent Considerations 1300 The foreign agent is passive and has a minimal role; it relays 1301 registration requests between the home agent and the mobile node, 1302 and decapsulates datagrams for delivery to the mobile node. It may 1303 advertise its services to prospective mobile clients as described in 1304 sections 2.2, 4.1. 1306 The foreign agent MUST NOT originate a request or reply that has not 1307 been prompted by the mobile node. No request or reply is generated 1308 to indicate that the service lifetime has expired. A foreign agent 1309 MUST NOT originate a message that asks for deregistration of a mobile 1310 node; however, it MUST relay valid deregistration requests originated 1311 by the mobile node. 1313 The foreign agent MUST NOT advertise to other routers in its routing 1314 domain, nor to any other mobile node, the presence of a mobile 1315 router. 1317 7.1. Configuration and Registration Tables 1319 Each foreign agent will need a care-of address. In addition, for 1320 each pending or current registration, the foreign agent will need a 1321 visitor list entry containing: 1323 - Media address of mobile node 1324 - home address 1325 - home agent 1326 - lifetime 1328 For each pending registration, a foreign agent must also store the 1329 low-order 32 bits of the registration identification, as sent by the 1330 mobile node. (The high-order 32 bits may differ in the registration 1331 reply. See subsection 9.6). In addition, the foreign agent must 1332 store the source port from which the mobile node's registration 1333 request was sent, so that the foreign agent can properly return the 1334 eventual registration reply. As with any host on the internet, a 1335 foreign agent may also maintain a security association for each 1336 pending or current registrant, and use it to authenticate the 1337 registration requests and replies of the mobile node or its home 1338 agent (subsections 4.4, 4.5). The foreign agent may use an available 1339 security association with the home agent to create an authentication 1340 for the foreign-home authentication extension. Even if a foreign 1341 agent implements authentication, it might not use authentication with 1342 each registration, because of the key management difficulties. 1344 7.2. Receiving Registration Requests 1346 If the foreign agent is able to satisfy an incoming registration 1347 request, then it relays the request to the home agent. Otherwise, 1348 it denies the request by sending a registration reply to the mobile 1349 node with an appropriate code. If the request is being denied 1350 because the requested lifetime is too long, the foreign agent puts 1351 in an acceptable value for the lifetime in the registration reply 1352 containing the rejection code. The foreign agent must maintain a 1353 list of pending requests, which includes the IPv6 source address and 1354 UDP source port, in order that a correctly addressed reply can be 1355 returned to the mobile node. 1357 7.3. Receiving Registration Replies 1359 A registration reply which does not match the identification of to 1360 any pending registration request must be silently discarded. If the 1361 registration reply is sent from the home agent with a status code 1362 indicating a successful registration, then the foreign agent updates 1363 its visitor list accordingly. If the foreign agent receives an ICMP 1364 error instead of a registration reply in response to the registration 1365 request, then it returns the "Home Agent Unreachable" failure code to 1366 the mobile node. 1368 7.4. Decapsulation 1370 Every foreign agent which receives an encapsulated packet sent to 1371 its advertised care-of address MUST compare the inner destination 1372 address to those entries in its visitor list. When the destination 1373 does not match any node currently in the visitor list, the foreign 1374 agent MUST NOT forward the datagram without modifications to the 1375 original IPv6 header, because otherwise a routing loop is likely to 1376 result. The datagram SHOULD be silently discarded. ICMP Destination 1377 Unreachable MUST NOT be sent when a foreign agent is unable to 1378 forward an incoming tunneled datagram. 1380 8. Home Agent Considerations 1382 The home agent has primary responsibility for processing and 1383 coordinating mobility services. Packets destined for mobile clients 1384 will arrive at a home agents that advertises connectivity to the home 1385 network containing the addresses of those mobile clients. The home 1386 agent will then encapsulate the packet and deliver it to the care-of 1387 address most recently reported by the mobile client. 1389 Often, the home agent will advertise connectivity to a home network 1390 which does not correspond to any particular physical medium (e.g, 1391 extent of Ethernet cabling). This is described by saying that the 1392 mobile clients have addresses on a virtual home network. 1394 The home agent for a given mobile node SHOULD be located on the link 1395 identified by the home address, if the home network is not merely a 1396 virtual network. In this case, the home agent MUST send out agent 1397 advertisements with the 'H' bit (see subsection 4.1) set, so that 1398 mobile nodes on their home network will be able to determine that 1399 they are indeed at home. 1401 8.1. Configuration and Registration Tables 1403 Each home agent will need an IPv6 address, and the prefix size for 1404 the home network, if the home network is not a virtual network. For 1405 each authorized mobile node, the home agent will need: 1407 - home address 1408 - mobility security association 1409 - prefix size(s) for the mobile network(s), if any 1411 For each registered mobile node, the home agent will need a mobility 1412 binding list entry containing: 1414 - care-of address 1415 - registration identification 1416 - lifetime 1418 8.2. Receiving Registration Requests 1420 Upon receipt of a registration request (subsection 3.2), the 1421 home agent grants or denies the service requested, by sending a 1422 registration reply (subsection 3.2) to the sender of the request with 1423 the appropriate code set. The home agent sends the registration 1424 reply back to the same UDP port from which it was sent. If service 1425 permission is granted, the home agent will update its mobility 1426 binding list with the care-of address of the tunnel. The home 1427 agent MAY impose a shorter lifetime than was requested for in the 1428 Registration Request message. If the Registration Request duplicates 1429 an accepted current Registration Request, the new lifetime MUST NOT 1430 extend beyond the lifetime originally granted. 1432 The request is validated by checking the registration identification 1433 (see subsection 9.6), and the Mobile-Home Authentication Extension 1434 (subsection 4.3) according to the mobility security association. 1435 Other authentication extensions are also validated when present. 1436 When the registration request is valid, the home agent may select 1437 a new nonce for use by the mobile node upon its next registration 1438 request, and include it in the first 32 bits of the identification 1439 field of the registration reply. The low order 32 bits of that 1440 field remain unmodified for use by the mobile node in matching the 1441 registration reply with one of its outstanding registration requests. 1443 When a registration request is invalid, a registration reply is 1444 sent with the appropriate error code. This reply will be used by a 1445 foreign agent to delete its pending request list entry, if a foreign 1446 agent was involved in relaying the registration request. If the 1447 request was invalid because of the use of an unexpected value in the 1448 identification field of the registration request, the home agent 1449 SHOULD use the high-order bits of the current identification to 1450 provide a new identification value for the mobile node. In this 1451 case, the home agent MAY report an authentication exception to its 1452 network management support software. The registration reply status 1453 code in this case is 37. If the registration request was invalid 1454 because of an invalid authenticator value, the home agent MUST issue 1455 an authentication exception. The registration reply status code is 1456 then 35. 1458 If the registration request is sent to the directed broadcast 1459 address of the home network, the home agent may deny the registration 1460 request. In this case, the registration reply will contain the 1461 home agent's address, so that the mobile node can re-issue the 1462 registration request with the correct home agent address. 1464 A mobile node requests termination of service by indicating a 1465 lifetime of zero. If the Code field set to 1, the home agent removes 1466 the mobility binding for that care-of address from its forwarding 1467 list. Otherwise, if the Code field is set to 0, the home agent 1468 removes the mobility bindings for all foreign agents associated with 1469 that mobile node from its mobility binding list. On termination, no 1470 reply is sent to additional associated foreign agents. The entries 1471 in their visitor lists are allowed to expire naturally. 1473 8.3. Simultaneous mobility bindings 1475 When a home agent supports the optional capability of multiple 1476 simultaneous mobility bindings, any datagrams forwarded are 1477 simply duplicated, and a copy is sent to each care-of address. 1478 If the home agent is unable to fulfill requests for simultaneous 1479 bindings, it returns the appropriate status in the registration 1480 reply (subsection 3.3) to the mobile node. When the mobile 1481 node makes future registration requests, it will then be able to 1482 determine whether it can expect simultaneous service at multiple 1483 care-of addresses. If the home agent has a limit on the number of 1484 simultaneous registrations that it can support for a mobile client, 1485 then it can just reject any registrations that would cause that limit 1486 to be exceeded. 1488 8.4. Registration Expiration 1490 If the lifetime for a given mobility binding expires before the home 1491 agent has received another registration request, then that binding is 1492 erased from the mobility binding list. No special registration reply 1493 is sent to the foreign agents. The entries in the visitor lists will 1494 expire naturally, and probably at the same time. When a mobility 1495 binding's lifetime expires, the home agent drops it regardless of 1496 whether or not simultaneous bindings are supported. 1498 8.5. Encapsulation 1500 Every home agent must examine the IPv6 header of all arriving 1501 traffic to see if it contains a destination address equal to the 1502 home address of any of its mobile nodes. Packets with matching 1503 destination addresses are encapsulated and delivered to the indicated 1504 care-of address found in the associated mobility binding. If the 1505 mobile node is at home, the home agent will simply forward the 1506 datagram directly to it; however, in this case, it is expected that 1507 the datagram will never be received by the home agent. 1509 Suppose an encapsulated datagram arrives at the home agent, that is 1510 to be delivered to one of its mobile clients. If the destination 1511 of the inner header is also the mobile client, the home agent may 1512 simply alter the outer destination to the care-of address, unless 1513 the care-of address is the same as the origination point of the 1514 encapsulated datagram. Otherwise, if the home agent receives a 1515 datagram for one of its mobile clients, and the packet's IPv6 source 1516 address is identical to the care-of address contained in the mobility 1517 binding list, the home agent MUST discard that packet. If the packet 1518 were forwarded back to the care-of address, a loop might result. 1520 The mechanism just described is intended to avoid recursive 1521 encapsulation. Other encapsulated datagrams arriving at the home 1522 agent may be recursively encapsulated. 1524 8.6. Broadcast packets 1526 Mobile nodes may request to receive broadcast packets by setting the 1527 'B' bit in their Registration Request packets (subsection 3.2). The 1528 method used to forward each depends on whether the mobile node is 1529 using its own dynamically-assigned care-of address or is registered 1530 using a care-of address associated with a foreign agent (indicated 1531 by the 'D' bit in the Registration Request packet). When using a 1532 dynamically-assigned care-of address, the home agent simply tunnels 1533 each received broadcast IPv6 datagram to this care-of address. When 1534 registered through a foreign agent, an extra level of encapsulation 1535 is required to indicate to the foreign agent which mobile node to 1536 deliver the tunneled datagram to when it is received by the foreign 1537 agent. The home agent first encapsulated the broadcast datagram in 1538 a unicast datagram addressed to the mobile node's home address, and 1539 then tunnels this encapsulated datagram to the foreign agent. When 1540 received by the foreign agent, the the unicast encapsulated datagram 1541 is detunneled and delivered to the mobile node in the same way as 1542 any other datagram. The mobile node must decapsulate this datagram 1543 to receive the original broadcast datagram. The extra level of 1544 encapsulation is necessary, since otherwise, the mobile node's home 1545 address would not appear anywhere in the tunneled datagram received 1546 by the foreign agent. Similar extra encapsulation is not required 1547 when using a dynamically-assigned care-of address, since the tunnel 1548 then terminates with the mobile node rather than with a foreign 1549 agent. 1551 When a home agent receives a broadcast packet, it transmits the 1552 packet to only those mobile nodes on its mobility binding list that 1553 have requested broadcast service. If it is determined that some 1554 broadcasts should be forwarded to mobile nodes by the home agent, 1555 those broadcasts will be specifically mentioned as exceptions. 1557 8.7. Multicast packets 1559 The rules regarding multicast packets to mobile clients are much the 1560 same as those relevant to multicast to other clients. 1562 9. Security Considerations 1564 The mobile computing environment is potentially very different from 1565 the ordinary computing environment. In many cases, mobile computers 1566 will be connected to the network via wireless links. Such links 1567 are particularly vulnerable to passive eavesdropping, active replay 1568 attacks, and other active attacks. 1570 9.1. Message Authentication Codes 1572 Home agents and mobile nodes MUST be able to perform authentication. 1573 The default algorithm is keyed MD5 [14], with a key size of 128 1574 bits. The default mode of operation is to both precede and follow 1575 the data to be hashed, by the 128-bit key; that is, MD5 is to be 1576 used in suffix+prefix mode. The foreign agent SHOULD also support 1577 authentication using keyed MD5 and key sizes of 128 bits or greater, 1578 with manual key distribution. More authentication algorithms, 1579 algorithm modes, key distribution methods, and key sizes MAY also be 1580 supported. 1582 9.2. Tunneling to Care-of Addresses 1584 The registration protocol described in this document will result 1585 in a mobile node's traffic being tunneled to its care-of address. 1586 This tunneling feature could be a significant vulnerability if the 1587 registration were not authentic. Such remote redirection, for 1588 instance as performed by the mobile registration protocol, is widely 1589 understood to be a security problem in the current Internet([2]). 1591 9.3. Key management 1593 This specification requires a strong authentication mechanism 1594 (keyed MD5) which precludes many potential attacks based on 1595 the Mobile IPv6 registration protocol. However, because key 1596 distribution is difficult in the absence of a network key management 1597 protocol, messages with the foreign agent are not all required to be 1598 authenticated. In a commercial environment it might be important 1599 to authenticate all messages between the foreign agent and the home 1600 agent, so that billing is possible, and service providers don't 1601 provide service to users that are not legitimate customers of that 1602 service provider. 1604 9.4. Picking good random numbers 1606 The strength of any authentication mechanism is dependent on 1607 several factors, including the innate strength of the authentication 1608 algorithm, the secrecy of the key used, the strength of the key used, 1609 and the quality of the particular implementation. This specification 1610 requires implementation of keyed MD5 for authentication, but does not 1611 preclude the use of other authentication algorithms and modes. For 1612 keyed MD5 authentication to be useful, the 128-bit key must be both 1613 secret (that is, known only to authorized parties) and pseudo-random. 1614 If nonces are used in connection with replay protection, they must 1615 also be selected carefully. Eastlake, et.al. ([6]) provides more 1616 information on generating pseudo-random numbers. 1618 9.5. Privacy 1620 Users who have sensitive data that they do not wish others to see 1621 should use mechanisms outside the scope of this document (such as 1622 encryption) to provide appropriate protection. Users concerned about 1623 traffic analysis should consider appropriate use of link encryption. 1624 If absolute location privacy is desired, the Mobile Node can create a 1625 tunnel to its Home Agent. Then, packets destined for correspondent 1626 hosts will appear to emanate from the Home Network, and it may be 1627 more difficult to pinpoint the location of the mobile node. 1629 9.6. Replay Protection for Registration Requests 1631 The Identification field is used to let the home agent verify that a 1632 registration message has been freshly generated by the mobile node, 1633 not replayed by an attacker from some previous registration. The 1634 exact method of using the field depends upon the mobile security 1635 association defined between the mobile node and home agent. Two 1636 methods are described here: using random "nonce" values (preferred), 1637 and another method using timestamps. A mobile node and its home 1638 agent must agree on the use of replay protection, because if a home 1639 agent expects only a nonce, it is unlikely to accept the mobile 1640 node's time value. 1642 Whatever method is used, the low order 32 bits of the identification 1643 MUST be copied unchanged from the registration request to the reply. 1644 The foreign agent uses those bits to match registration requests with 1645 corresponding replies. The mobile node MUST verify that the low 1646 order 32 bits of any registration reply are identical to the bits it 1647 sent in the registration request. 1649 The Identification in a new registration request MUST NOT be the same 1650 as in an immediately preceding request, and SHOULD NOT repeat during 1651 the lifetime of the mobility security association between the mobile 1652 node and the home agent. Retransmission as in subsection 6.6 is 1653 allowed. 1655 9.6.1. Replay Protection using Nonces 1657 The basic principle of nonce replay protection is that Node A 1658 includes a new random number in every message to node B, and checks 1659 that Node B returns that same number in its next message to node 1660 A. Both messages use a cryptographic checksum to protect against 1661 alteration by an attacker. At the same time Node B can send its own 1662 nonces in all messages to Node A (to be echoed by node A), so that it 1663 too can verify that it is receiving fresh messages. 1665 The home agent may be expected to have resources for computing 1666 pseudo-random numbers useful as nonces[6]. It inserts a new nonce 1667 as the high-order 32 bits of the identification field of every 1668 registration reply. The home agent copies the low-order 32 bits of 1669 the Identification from the registration request message. When the 1670 mobile node receives an authenticated registration reply from the 1671 home agent, it saves the high order 32 bits of the identification for 1672 use as the high-order 32 bits of its next registration request. 1674 The mobile node is responsible for generating the low order 32 1675 bits of the Identification in each registration request. Ideally 1676 it should generate its own random nonces. However it may use any 1677 expedient method, including duplication of the random value sent by 1678 the home agent. The method chosen is of concern only to the mobile 1679 node, because it is the node that checks for valid values in the 1680 registration reply. The high-order and low-order 32 bits of the 1681 identification chosen SHOULD both differ from their previous values. 1682 The home agent needs a new high order value and the mobile node needs 1683 a new low-order value for replay protection. The foreign agent needs 1684 a new low-order value to correctly match registration replies with 1685 pending requests (see subsection 7.1). 1687 If a registration message is rejected because of an invalid nonce, 1688 the reply always provides the mobile node with a new nonce to 1689 be used in the next registration. Thus the nonce protocol is 1690 self-synchronizing. 1692 9.6.2. Replay Protection using Timestamps 1694 The basic principle of timestamp replay protection is that the node 1695 generating a message inserts the current time of day, and the node 1696 receiving the message checks that this timestamp is sufficiently 1697 close to its own time of day. Obviously the two nodes must have 1698 adequately synchronized time of day clocks. As usual all messages 1699 are protected against tampering by a cryptographic checksum. 1701 If timestamps are used, the mobile node sets the Identification 1702 field to a 64-bit value formated as specified by the Network Time 1703 Protocol [10]. The low-order 32 bits of the NTP format represent 1704 fractional seconds, and those bits which are not available from a 1705 time source SHOULD be generated from a good source of randomness. 1707 If the timestamp in a registration request that has passed 1708 authentication is close enough to the home agent's time of day, the 1709 home agent copies the entire Identification into the registration 1710 reply. If the timestamp is unacceptable, the home agent copies only 1711 the low order 32 bits into the registration reply, and supplies the 1712 high order 32 bits from its own time of day. The error code in the 1713 registration reply indicates an identification mismatch. The mobile 1714 node MUST verify that the low order 32 bits of the identification 1715 in the registration reply are identical to those in the rejected 1716 registration attempt, before using the high order bits for clock 1717 resynchronization. Time tolerances and resynchronization details are 1718 specific to a particular mobile security association. 1720 10. Acknowledgements 1722 Thanks to the active members of the Mobile-IP working group, 1723 particularly those who contributed text, including (in alphabetical 1724 order) 1726 - Ran Atkinson (Naval Research Lab), 1727 - Dave Johnson (Carnegie Mellon University), 1728 - Andrew Myles (Macquarie University), 1729 - John Penners (US West), 1730 - Al Quirt (Bell Northern Research), 1731 - Yakov Rekhter (IBM), and 1732 - Fumio Teraoka (Sony). 1734 Thanks to Charlie Kunzinger, the editor who produced the first drafts 1735 for the Working Group, and to Bill Simpson, who has produced a lot 1736 of the text of this draft, reflecting the discussions of the Working 1737 Group. 1739 Much of the material in this draft which is absent from the text of 1740 the Mobile-IP working group was taken from an earlier draft by Bill 1741 Simpson describing a similar method of supporting mobility with IPv6. 1743 A. TCP Considerations 1745 A.1. TCP Timers 1747 Most hosts and routers which implement TCP/IP do not permit easy 1748 configuration of the TCP timer values. When high-delay (e.g. 1749 SATCOM) or low-bandwidth (e.g. High-Frequency Radio) links are 1750 in use, the default TCP timer values in many systems may cause 1751 retransmissions or timeouts, even when the link and network is 1752 actually operating properly with greater than usual delays because 1753 of the medium in use. This can cause an inability to create or 1754 maintain connections over such links, and can also cause unneeded 1755 retransmissions which consume already scarce bandwidth. Vendors are 1756 encouraged to make TCP timers more configurable. Vendors of systems 1757 designed for the mobile computing markets should pick default timer 1758 values more suited to low-bandwidth, high-delay links. Users of 1759 mobile nodes should be sensitive to the possibility of timer-related 1760 difficulties. 1762 A.2. TCP Congestion Management 1764 Mobility nodes are likely to use media which have low bandwidth and 1765 are more likely to introduce errors, effectively causing more packets 1766 to be dropped. This introduces a conflict with the mechanisms for 1767 congestion management found in modern versions of TCP. Now, when 1768 a packet is dropped, the correspondent's TCP implementation is 1769 likely to react as if there were a source of network congestion, 1770 and initiate the slow-start mechanisms [4] designed for controlling 1771 that problem. However, those mechanisms are inappropriate for 1772 overcoming errors introduced by the links themselves, and have the 1773 effect of magnifying the discontinuity introduced by the dropped 1774 packet. This problem has been analyzed by Caceres, et. al.([3]); 1775 there is no easy solution available, and certainly no solution likely 1776 to be installed soon on all correspondents. While this problem has 1777 nothing to do with any of the specifications in this document, it 1778 does illustrate that providing performance transparency to mobile 1779 nodes involves understanding mechanisms outside the network layer. 1780 It also indicates the need to avoid designs which systematically drop 1781 packets; such designs might otherwise be considered favorably when 1782 making engineering tradeoffs. 1784 References 1786 [1] R. Atkinson. IPv6 Encapsulating Security Payload (ESP). 1787 draft-ietf-ipngwg-esp-00.txt -- work in progress, February 1995. 1789 [2] S.M. Bellovin. Security Problems in the TCP/IP Protocol Suite. 1790 ACM Computer Communications Review, 19(2), March 1989. 1792 [3] Ramon Caceres and Liviu Iftode. The Effects of Mobility on 1793 Reliable Transport Protocols. In Proceedings of the 14th 1794 International Conference on Distributed Computing Systems, June 1795 1994. 1797 [4] Douglas E. Comer. Internetworking with TCP/IP, volume 1. 1798 Prentice Hall, 1991. 1800 [5] R. Droms. Dynamic Host Configuration Protocol. RFC 1541, 1801 October 1993. 1803 [6] D.E. Eastlake, S.D. Crocker, and J.I. Schiller. Randomness 1804 Requirements for Security. RFC 1750, December 1994. 1806 [7] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic routing 1807 encapsulation (gre). RFC 1701, October 1994. 1809 [8] Bob Hinden. Internet Protocol, Version 6 (IPv6) Specification 1810 . Internet draft -- work in progress, October 1994. 1812 [9] J. Kohl and C. Newman. The Kerberos Network Authentication 1813 Service (V5). RFC 1510, September 1993. 1815 [10] D. Mills. Network Time Protocol (Version 3). RFC 1305, March 1816 1992. 1818 [11] National Bureau of Standards. Data Encryption Standard. 1819 Federal Information Processing Standards, 1977. 1821 [12] J. Postel. User Datagram Protocol. RFC 768, August 1980. 1823 [13] J. Reynolds and J. Postel. Assigned Numbers. RFC 1700, October 1824 1994. 1826 [14] R. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, April 1827 1992. 1829 [15] Bill Simpson. IPv6 Neighbor Discover -- Processing. Internet 1830 Draft -- work in progress, November 1994. 1832 Editor's Address 1834 Questions about this memo can be directed to: 1836 Charles Perkins 1837 Room J1-A25 1838 T. J. Watson Research Center 1839 IBM Corporation 1840 30 Saw Mill River Rd. 1841 Hawthorne, NY 10532 1843 Work: +1-914-784-7350 1844 Fax: +1-914-784-7007 1845 E-mail: perk@watson.ibm.com