idnits 2.17.1 draft-ietf-mobileip-rfc2344-bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (July 2000) is 8685 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: 'IPIP' on line 1023 == Outdated reference: A later version (-08) exists of draft-ietf-mobileip-rfc2002-bis-02 -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-09 -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1826 (ref. '6') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. '7') (Obsoleted by RFC 2406) ** Obsolete normative reference: RFC 2267 (ref. '8') (Obsoleted by RFC 2827) ** Obsolete normative reference: RFC 2486 (ref. '11') (Obsoleted by RFC 4282) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Montenegro, Editor 3 INTERNET DRAFT Sun Microsystems, Inc. 4 July 2000 5 Reverse Tunneling for Mobile IP, revised 6 draft-ietf-mobileip-rfc2344-bis-02.txt 8 Status of This Memo 10 This document is a submission by the Mobile IP Working Group of 11 the Internet Engineering Task Force (IETF). Comments should be 12 submitted to the Mobile IP mailing list at 13 "MOBILE-IP@STANDARDS.NORTELNETWORKS.COM". 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet 19 Engineering Task Force (IETF), its areas, and its working 20 groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as "work 27 in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Mobile IP uses tunneling from the home agent to the mobile 38 node's care-of address, but rarely in the reverse direction. 39 Usually, a mobile node sends its packets through a router on the 40 foreign network, and assumes that routing is independent of 41 source address. When this assumption is not true, it is 42 convenient to establish a topologically correct reverse tunnel 43 from the care-of address to the home agent. 45 This document proposes backwards-compatible extensions to Mobile 46 IP to support topologically correct reverse tunnels. This 47 document does not attempt to solve the problems posed by 48 firewalls located between the home agent and the mobile node's 49 care-of address. 51 Table of Contents 53 1. Introduction ................................................... 3 54 1.1. Terminology .................................................. 4 55 1.2. Assumptions .................................................. 4 56 1.3. Justification ................................................ 5 57 2. Overview ....................................................... 5 58 3. New Packet Formats ............................................. 5 59 3.1. Mobility Agent Advertisement Extension ....................... 5 60 3.2. Registration Request ......................................... 6 61 3.3. Encapsulating Delivery Style Extension ....................... 7 62 3.4. New Registration Reply Codes ................................. 8 63 4. Changes in Protocol Behavior ................................... 9 64 4.1. Mobile Node Considerations ................................... 9 65 4.1.1. Sending Registration Requests to the Foreign Agent ......... 9 66 4.1.2. Receiving Registration Replies from the Foreign Agent ...... 10 67 4.2. Foreign Agent Considerations ................................. 11 68 4.2.1. Receiving Registration Requests from the Mobile Node ....... 11 69 4.2.2. Relaying Registration Requests to the Home Agent ........... 11 70 4.3. Home Agent Considerations .................................... 12 71 4.3.1. Receiving Registration Requests from the Foreign Agent ..... 12 72 4.3.2. Sending Registration Replies to the Foreign Agent .......... 12 73 5. Mobile Node to Foreign Agent Delivery Styles ................... 13 74 5.1. Direct Delivery Style ........................................ 13 75 5.1.1. Packet Processing .......................................... 13 76 5.1.2. Packet Header Format and Fields ............................ 14 77 5.2. Encapsulating Delivery Style ................................. 14 78 5.2.1 Packet Processing ........................................... 15 79 5.2.2. Packet Header Format and Fields ............................ 15 80 5.3. Support for Broadcast and Multicast Datagrams ................ 16 81 5.4. Selective Reverse Tunneling .................................. 17 82 6. Security Considerations ........................................ 17 83 6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks ....... 17 84 6.2. Ingress Filtering ............................................ 18 85 6.3. Reverse Tunneling for Disparate Address Spaces ............... 18 86 Appendix: Disparate Address Space Support ......................... 19 87 A.1. Scope of the Reverse Tunneling Solution ................... 19 88 A.2. Terminating Forward Tunnels at the Foreign Agent .......... 23 89 A.3. Initiating Reverse Tunnels at the Foreign Agent ........... 24 90 A.4. Limited Private Address Scenario .......................... 25 91 7. Acknowledgements ............................................... 27 92 Changes from Previous Version of the Draft ........................ 27 93 References ........................................................ 28 94 Editor and Chair Addresses ........................................ 29 95 1. Introduction 97 Section 1.3 of the Mobile IP specification [1] lists the following 98 assumption: 100 It is assumed that IP unicast datagrams are routed based on the 101 destination address in the datagram header (i.e., not by source 102 address). 104 Because of security concerns (for example, IP spoofing attacks), and 105 in accordance with RFC 2267 [8] and CERT [3] advisories to this 106 effect, routers that break this assumption are increasingly more 107 common. 109 In the presence of such routers, the source and destination IP 110 address in a packet must be topologically correct. The forward 111 tunnel complies with this, as its endpoints (home agent address and 112 care-of address) are properly assigned addresses for their 113 respective locations. On the other hand, the source IP address of a 114 packet transmitted by the mobile node does not correspond to the 115 network prefix from where it emanates. 117 This document discusses topologically correct reverse tunnels. 119 Mobile IP does dictate the use of reverse tunnels in the context of 120 multicast datagram routing and mobile routers. However, the source 121 IP address is set to the mobile node's home address, so these 122 tunnels are not topologically correct. 124 Notice that there are several uses for reverse tunnels regardless of 125 their topological correctness: 127 - Mobile routers: reverse tunnels obviate the need for recursive 128 tunneling [1]. 130 - Multicast: reverse tunnels enable a mobile node away from home 131 to (1) join multicast groups in its home network, and (2) 132 transmit multicast packets such that they emanate from its home 133 network [1]. 135 - The TTL of packets sent by the mobile node (for example, when 136 sending packets to other hosts in its home network) may be so 137 low that they might expire before reaching their destination. 138 A reverse tunnel solves the problem as it represents a TTL 139 decrement of one [5]. 141 1.1. Terminology 143 The discussion below uses terms defined in the Mobile IP 144 specification. Additionally, it uses the following terms: 146 Forward Tunnel 148 A tunnel that shuttles packets towards the mobile node. It 149 starts at the home agent, and ends at the mobile node's 150 care-of address. 152 Reverse Tunnel 154 A tunnel that starts at the mobile node's care-of address and 155 terminates at the home agent. 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 159 this document are to be interpreted as described in RFC 2119 [9]. 161 1.2. Assumptions 163 Mobility is constrained to a common IP address space (that is, the 164 routing fabric between, say, the mobile node and the home agent is 165 not partitioned into a "private" and a "public" network). 167 This document does not attempt to solve the firewall traversal 168 problem. Rather, it assumes one of the following is true: 170 - There are no intervening firewalls along the path of the 171 tunneled packets. 173 - Any intervening firewalls share the security association 174 necessary to process any authentication [6] or encryption [7] 175 headers which may have been added to the tunneled packets. 177 The reverse tunnels considered here are symmetric, that is, they use 178 the same configuration (encapsulation method, IP address endpoints) 179 as the forward tunnel. IP in IP encapsulation [2] is assumed unless 180 stated otherwise. 182 Route optimization [4] introduces forward tunnels initiated at a 183 correspondent host. Since a mobile node may not know if the 184 correspondent host can decapsulate packets, reverse tunnels in that 185 context are not discussed here. 187 1.3. Justification 189 Why not let the mobile node itself initiate the tunnel to the home 190 agent? This is indeed what it should do if it is already operating 191 with a topologically correct co-located care-of address. 193 However, one of the primary objectives of the Mobile IP 194 specification is not to require this mode of operation. 196 The mechanisms outlined in this document are primarily intended for 197 use by mobile nodes that rely on the foreign agent for forward 198 tunnel support. It is desirable to continue supporting these mobile 199 nodes, even in the presence of filtering routers. 201 2. Overview 203 A mobile node arrives at a foreign network, listens for agent 204 advertisements and selects a foreign agent that supports reverse 205 tunnels. It requests this service when it registers through the 206 selected foreign agent. At this time, and depending on how the 207 mobile node wishes to deliver packets to the foreign agent, it also 208 requests either the Direct or the Encapsulating Delivery Style 209 (section 5). 211 In the Direct Delivery Style, the mobile node designates the foreign 212 agent as its default router and proceeds to send packets directly to 213 the foreign agent, that is, without encapsulation. The foreign 214 agent intercepts them, and tunnels them to the home agent. 216 In the Encapsulating Delivery Style, the mobile node encapsulates 217 all its outgoing packets to the foreign agent. The foreign agent 218 decapsulates and re-tunnels them to the home agent, using the 219 foreign agent's care-of address as the entry-point of this new 220 tunnel. 222 3. New Packet Formats 224 3.1. Mobility Agent Advertisement Extension 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type | Length | Sequence Number | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Lifetime |R|B|H|F|M|G|r|T| reserved | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | zero or more Care-of Addresses | 233 | ... | 235 The only change to the Mobility Agent Advertisement Extension [1] is 236 the additional 'T' bit: 238 T Agent offers reverse tunneling service. 240 A foreign agent that sets the 'T' bit MUST support the Direct 241 Delivery Style. Encapsulating Delivery Style SHOULD be supported 242 as well (section 5). 244 Using this information, a mobile node is able to choose a foreign 245 agent that supports reverse tunnels. Notice that if a mobile node 246 does not understand this bit, it simply ignores it as per [1]. 248 3.2. Registration Request 250 Reverse tunneling support is added directly into the Registration 251 Request by using one of the "rsvd" bits. If a foreign or home agent 252 that does not support reverse tunnels receives a request with the 253 'T' bit set, the Registration Request fails. This results in a 254 registration denial (failure codes are specified in section 3.4). 256 Home agents SHOULD NOT object to providing reverse tunnel 257 support, because they "MUST be able to decapsulate and further 258 deliver packets addressed to themselves, sent by a mobile node" 259 [1]. In the case of topologically correct reverse tunnels, the 260 packets are not sent by the mobile node as distinguished by its 261 home address. Rather, the outermost (encapsulating) IP source 262 address on such datagrams is the care-of address of the mobile 263 node. 265 In Registration Requests sent by a mobile node, the Time to Live 266 field in the IP header MUST be set to 255. This limits a denial of 267 service attack in which malicious hosts send false Registration 268 Requests (see Section 6). 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Type |S|B|D|M|G|r|T|-| Lifetime | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Home Address | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Home Agent | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Care-of Address | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Identification | 282 | | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Extensions ... 285 +-+-+-+-+-+-+-+- 287 The only change to the Registration Request packet is the additional 288 'T' bit: 290 T If the 'T' bit is set, the mobile node asks its home 291 agent to accept a reverse tunnel from the care-of 292 address. Mobile nodes using a foreign agent care-of 293 address ask the foreign agent to reverse-tunnel its 294 packets. 296 3.3. Encapsulating Delivery Style Extension 298 The Encapsulating Delivery Style Extension MAY be included by 299 the mobile node in registration requests to further specify 300 reverse tunneling behavior. It is expected to be used only by 301 the foreign agent. Accordingly, the foreign agent MUST consume 302 this extension (that is, it must not relay it to the home agent 303 or include it in replies to the mobile node). As per Section 304 3.6.1.3 of [1], the mobile node MUST include the Encapsulating 305 Delivery Style Extension after the Mobile-Home Authentication 306 Extension, and before the Mobile-Foreign Authentication 307 Extension, if present. 309 The Encapsulating Delivery Style Extension MUST NOT be included 310 if the 'T' bit is not set in the Registration Request. 312 If this extension is absent, Direct Delivery is assumed. 313 Encapsulation is done according to what was negotiated for the 314 forward tunnel (that is, IP in IP is assumed unless specified 315 otherwise). For more details on the delivery styles, please 316 refer to section 5. 318 Foreign agents SHOULD support the Encapsulating Delivery Style 319 Extension. 321 0 1 322 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Type | Length | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Type 329 130 331 Length 333 0 335 3.4. New Registration Reply Codes 337 Foreign and home agent registration replies MUST convey if the 338 reverse tunnel request failed. These new reply codes are defined: 340 Service denied by the foreign agent: 342 74 requested reverse tunnel unavailable 343 75 reverse tunnel is mandatory and 'T' bit not set 344 76 mobile node too distant 345 79 delivery style not supported 347 NOTE: Code 79 has not yet been assigned by IANA. 349 and 351 Service denied by the home agent: 353 137 requested reverse tunnel unavailable 354 138 reverse tunnel is mandatory and 'T' bit not set 355 139 requested encapsulation unavailable 357 In response to a Registration Request with the 'T' bit set, mobile 358 nodes may receive (and MUST accept) code 70 (poorly formed request) 359 from foreign agents and code 134 (poorly formed request) from home 360 agents. However, foreign and home agents that support reverse 361 tunneling MUST use codes 74 and 137, respectively. 363 In addition to setting the 'T' bit, the mobile node also MAY 364 request the Encapsulating Delivery Style by including the 365 corresponding extension. If a foreign agent does not implement 366 the Encapsulating Delivery Style, it MUST respond to the mobile 367 node with code 79 (delivery style not supported). This also 368 applies if the foreign agent does not support a requested 369 delivery style that may be defined in the future. 371 Absence of the 'T' bit in a Registration Request MAY elicit denials 372 with codes 75 and 138 at the foreign agent and the home agent, 373 respectively. 375 Forward and reverse tunnels are symmetric, that is, both are able to 376 use the same tunneling options negotiated at registration. This 377 implies that the home agent MUST deny registrations if an 378 unsupported form of tunneling is requested (code 139). Notice that 379 Mobile IP [1] already defines the analogous failure code 72 for use 380 by the foreign agent. 382 4. Changes in Protocol Behavior 384 Unless otherwise specified, behavior specified by Mobile IP [1] 385 is assumed. In particular, if any two entities share a mobility 386 security association, they MUST use the appropriate 387 Authentication Extension (Mobile-Foreign, Foreign-Home or 388 Mobile-Home Authentication Extension) when exchanging 389 registration protocol datagrams. An admissible authentication 390 extension (for example the Mobile-Home Authentication Extension) 391 MUST always be present to authenticate registration messages 392 between a mobile node and its home agent. 394 Reverse tunneling imposes additional protocol processing 395 requirements on mobile entities. Differences in protocol 396 behavior with respect to Mobile IP [1] are specified in the 397 subsequent sections. 399 4.1. Mobile Node Considerations 401 This section describes how the mobile node handles registrations 402 that request a reverse tunnel. 404 4.1.1. Sending Registration Requests to the Foreign Agent 406 In addition to the considerations in [1], a mobile node sets the 'T' 407 bit in its Registration Request to petition a reverse tunnel. 409 The mobile node MUST set the TTL field of the IP header to 255. This 410 is meant to limit the reverse tunnel hijacking attack (Section 6). 412 The mobile node MAY optionally include an Encapsulating Delivery 413 Style Extension. 415 4.1.2. Receiving Registration Replies from the Foreign Agent 417 Possible valid responses are: 419 - A registration denial issued by either the home agent or the 420 foreign agent: 422 a. The mobile node follows the error checking guidelines 423 in [1], and depending on the reply code, MAY try 424 modifying the registration request (for example, by 425 eliminating the request for alternate forms of 426 encapsulation or delivery style), and issuing a new 427 registration. 429 b. Depending on the reply code, the mobile node MAY try 430 zeroing the 'T' bit, eliminating the Encapsulating 431 Delivery Style Extension (if one was present), and 432 issuing a new registration. Notice that after doing so 433 the registration may succeed, but due to the lack of a 434 reverse tunnel data transfer may not be possible. 436 - The home agent returns a Registration Reply indicating that the 437 service will be provided. 439 In this last case, the mobile node has succeeded in establishing a 440 reverse tunnel between its care-of address and its home agent. If 441 the mobile node is operating with a co-located care-of address, it 442 MAY encapsulate outgoing data such that the destination address of 443 the outer header is the home agent. This ability to selectively 444 reverse-tunnel packets is discussed further in section 5.4. 446 If the care-of address belongs to a separate foreign agent, the 447 mobile node MUST employ whatever delivery style was requested 448 (Direct or Encapsulating) and proceed as specified in section 5. 450 A successful registration reply is an assurance that both the 451 foreign agent and the home agent support whatever alternate forms of 452 encapsulation (other than IP in IP) were requested. Accordingly, the 453 mobile node MAY use them at its discretion. 455 4.2. Foreign Agent Considerations 457 This section describes how the foreign agent handles registrations 458 that request a reverse tunnel. 460 4.2.1. Receiving Registration Requests from the Mobile Node 462 A foreign agent that receives a Registration Request with the 463 'T' bit set processes the packet as specified in the Mobile IP 464 specification [1], and determines whether it can accomodate the 465 forward tunnel request. If it cannot, it returns an appropriate 466 code. In particular, if the foreign agent is unable to support 467 the requested form of encapsulation it MUST return code 72. If 468 it cannot support the requested form of delivery style it MUST 469 return code 79 (delivery style not supported). 471 The foreign agent MAY reject Registration Requests without the 472 'T' bit set by denying them with code 75 (reverse tunnel is 473 mandatory and 'T' bit not set). 475 The foreign agent MUST verify that the TTL field of the IP 476 header is set to 255. Otherwise, it MUST reject the registration 477 with code 76 (mobile node too distant). The foreign agent MUST 478 limit the rate at which it sends these registration replies 479 to a maximum of one per second. 481 As a last check, the foreign agent verifies that it can support 482 a reverse tunnel with the same configuration. If it cannot, 483 it MUST return a Registration Reply denying the request with 484 code 74 (requested reverse tunnel unavailable). 486 4.2.2. Relaying Registration Requests to the Home Agent 488 Otherwise, the foreign agent MUST relay the Registration Request to 489 the home agent. 491 Upon receipt of a Registration Reply that satisfies validity checks, 492 the foreign agent MUST update its visitor list, including indication 493 that this mobile node has been granted a reverse tunnel and the 494 delivery style expected (section 5). 496 While this visitor list entry is in effect, the foreign agent MUST 497 process incoming traffic according to the delivery style, 498 encapsulate it and tunnel it from the care-of address to the home 499 agent's address. 501 4.3. Home Agent Considerations 503 This section describes how the home agent handles registrations that 504 request a reverse tunnel. 506 4.3.1. Receiving Registration Requests from the Foreign Agent 508 A home agent that receives a Registration Request with the 'T' bit 509 set processes the packet as specified in the Mobile IP specification 510 [1] and determines whether it can accomodate the forward tunnel 511 request. If it cannot, it returns an appropriate code. In 512 particular, if the home agent is unable to support the requested 513 form of encapsulation it MUST return code 139 (requested 514 encapsulation unavailable). 516 The home agent MAY reject registration requests without the 'T' bit 517 set by denying them with code 138 (reverse tunnel is mandatory and 518 'T' bit not set). 520 As a last check, the home agent determines whether it can support a 521 reverse tunnel with the same configuration as the forward tunnel. If 522 it cannot, it MUST send back a registration denial with code 137 523 (requested reverse tunnel unavailable). 525 Upon receipt of a Registration Reply that satisfies validity checks, 526 the home agent MUST update its mobility bindings list to indicate 527 that this mobile node has been granted a reverse tunnel and the type 528 of encapsulation expected. 530 4.3.2. Sending Registration Replies to the Foreign Agent 532 In response to a valid Registration Request, a home agent MUST issue 533 a Registration Reply to the mobile node. 535 After a successful registration, the home agent may receive 536 encapsulated packets addressed to itself. Decapsulating such packets 537 and blindly injecting them into the network is a potential security 538 weakness (section 6.1). Accordingly, the home agent MUST implement, 539 and, by default, SHOULD enable the following check for encapsulated 540 packets addressed to itself: 542 The home agent searches for a mobility binding whose care-of 543 address is the source of the outer header, and whose mobile node 544 address is the source of the inner header. 546 If no such binding is found, or if the packet uses an encapsulation 547 mechanism that was not negotiated at registration the home agent 548 MUST silently discard the packet and SHOULD log the event as a 549 security exception. 551 Home agents that terminate tunnels unrelated to Mobile IP (for 552 example, multicast tunnels) MAY turn off the above check, but this 553 practice is discouraged for the aforementioned reasons. 555 While the registration is in effect, a home agent MUST process each 556 valid reverse tunneled packet (as determined by checks like the 557 above) by decapsulating it, recovering the original packet, and then 558 forwarding it on behalf of its sender (the mobile node) to the 559 destination address (the correspondent host). 561 5. Mobile Node to Foreign Agent Delivery Styles 563 This section specifies how the mobile node sends its data traffic 564 via the foreign agent. In all cases, the mobile node learns the 565 foreign agent's link-layer address from the link-layer header in the 566 agent advertisement. 568 5.1. Direct Delivery Style 570 This delivery mechanism is very simple to implement at the mobile 571 node, and uses small (non-encapsulated) packets on the link between 572 the mobile node and the foreign agent (potentially a very slow 573 link). However, it only supports reverse-tunneling of unicast 574 packets, and does not allow selective reverse tunneling (section 575 5.4). 577 5.1.1. Packet Processing 579 The mobile node MUST designate the foreign agent as its default 580 router. Not doing so will not guarantee encapsulation of all the 581 mobile node's outgoing traffic, and defeats the purpose of the 582 reverse tunnel. The foreign agent MUST: 584 - detect packets sent by the mobile node, and 586 - modify its forwarding function to encapsulate them before 587 forwarding. 589 5.1.2. Packet Header Format and Fields 591 This section shows the format of the packet headers used by the 592 Direct Delivery style. The formats shown assume IP in IP 593 encapsulation [2]. 595 Packet format received by the foreign agent (Direct Delivery 596 Style): 598 IP fields: 599 Source Address = mobile node's home address 600 Destination Address = correspondent host's address 601 Upper Layer Protocol 603 Packet format forwarded by the foreign agent (Direct Delivery 604 Style): 606 IP fields (encapsulating header): 607 Source Address = foreign agent's care-of address 608 Destination Address = home agent's address 609 Protocol field: 4 (IP in IP) 610 IP fields (original header): 611 Source Address = mobile node's home address 612 Destination Address = correspondent host's address 613 Upper Layer Protocol 615 These fields of the encapsulating header MUST be chosen as follows: 617 IP Source Address 619 Copied from the Care-of Address field within the Registration 620 Request. 622 IP Destination Address 624 Copied from the Home Agent field within the most recent 625 successful Registration Reply. 627 IP Protocol Field 629 Default is 4 (IP in IP [2]), but other methods of 630 encapsulation MAY be used as negotiated at registration time. 632 5.2. Encapsulating Delivery Style 634 This mechanism requires that the mobile node implement 635 encapsulation, and explicitly directs packets at the foreign agent 636 by designating it as the destination address in a new outermost 637 header. Mobile nodes that wish to send either broadcast or 638 multicast packets MUST use the Encapsulating Delivery Style. 640 5.2.1 Packet Processing 642 The foreign agent does not modify its forwarding function. 643 Rather, it receives an encapsulated packet and after verifying that 644 it was sent by the mobile node, it: 646 - decapsulates to recover the inner packet, 648 - re-encapsulates, and sends it to the home agent. 650 If a foreign agent receives an un-encapsulated packet from a mobile 651 node which had explicitly requested the Encapsulated Delivery Style, 652 then the foreign agent MUST NOT reverse tunnel such a packet and 653 rather MUST forward it using standard, IP routing mechanisms. 655 5.2.2. Packet Header Format and Fields 657 This section shows the format of the packet headers used by the 658 Encapsulating Delivery style. The formats shown assume IP in IP 659 encapsulation [2]. 661 Packet format received by the foreign agent (Encapsulating Delivery 662 Style): 664 IP fields (encapsulating header): 665 Source Address = mobile node's home address 666 Destination Address = foreign agent's address 667 Protocol field: 4 (IP in IP) 668 IP fields (original header): 669 Source Address = mobile node's home address 670 Destination Address = correspondent host's address 671 Upper Layer Protocol 673 The fields of the encapsulating IP header MUST be chosen as 674 follows: 676 IP Source Address 678 The mobile node's home address. 680 IP Destination Address 682 The address of the agent as learned from the IP source address 683 of the agent's most recent successful registration reply. 685 IP Protocol Field 687 Default is 4 (IP in IP [2]), but other methods of 688 encapsulation MAY be used as negotiated at registration time. 690 Packet format forwarded by the foreign agent (Encapsulating Delivery 691 Style): 693 IP fields (encapsulating header): 694 Source Address = foreign agent's care-of address 695 Destination Address = home agent's address 696 Protocol field: 4 (IP in IP) 697 IP fields (original header): 698 Source Address = mobile node's home address 699 Destination Address = correspondent host's address 700 Upper Layer Protocol 702 These fields of the encapsulating IP header MUST be chosen as 703 follows: 705 IP Source Address 707 Copied from the Care-of Address field within the Registration 708 Request. 710 IP Destination Address 712 Copied from the Home Agent field within the most recent 713 successful Registration Reply. 715 IP Protocol Field 717 Default is 4 (IP in IP [2]), but other methods of 718 encapsulation MAY be used as negotiated at registration time. 720 5.3. Support for Broadcast and Multicast Datagrams 722 If a mobile node is operating with a co-located care-of address, 723 broadcast and multicast datagrams are handled according to Sections 724 4.3 and 4.4 of the Mobile IP specification [1]. Mobile nodes using a 725 foreign agent care-of address MAY have their broadcast and multicast 726 datagrams reverse-tunneled by the foreign agent. However, any 727 mobile nodes doing so MUST use the encapsulating delivery style. 729 This delivers the datagram only to the foreign agent. The latter 730 decapsulates it and then processes it as any other packet from the 731 mobile node, namely, by reverse tunneling it to the home agent. 733 5.4. Selective Reverse Tunneling 735 Packets destined to local resources (for example, a nearby printer) 736 might be unaffected by ingress filtering. A mobile node with a 737 co-located care-of address MAY optimize delivery of these packets by 738 not reverse tunneling them. On the other hand, a mobile node using 739 a foreign agent care-of address MAY use this selective reverse 740 tunneling capability by requesting the Encapsulating Delivery Style, 741 and following these guidelines: 743 Packets NOT meant to be reversed tunneled: 745 Sent using the Direct Delivery style. The foreign agent 746 MUST process these packets as regular traffic: they MAY be 747 forwarded but MUST NOT be reverse tunneled to the home agent. 749 Packets meant to be reverse tunneled: 751 Sent using the Encapsulating Delivery style. The foreign agent 752 MUST process these packets as specified in section 5.2: they 753 MUST be reverse tunneled to the home agent. 755 6. Security Considerations 757 The extensions outlined in this document are subject to the security 758 considerations outlined in the Mobile IP specification [1]. 759 Essentially, creation of both forward and reverse tunnels involves 760 an authentication procedure, which reduces the risk for attack. 762 6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks 764 Once the tunnel is set up, a malicious node could hijack it to 765 inject packets into the network. Reverse tunnels might exacerbate 766 this problem, because upon reaching the tunnel exit point packets 767 are forwarded beyond the local network. This concern is also present 768 in the Mobile IP specification, as it already dictates the use of 769 reverse tunnels for certain applications. 771 Unauthenticated exchanges involving the foreign agent allow a 772 malicious node to pose as a valid mobile node and re-direct an 773 existing reverse tunnel to another home agent, perhaps another 774 malicious node. The best way to protect against these attacks is by 775 employing the Mobile-Foreign and Foreign-Home Authentication 776 Extensions defined in [1]. 778 If the necessary mobility security associations are not available, 779 this document introduces a mechanism to reduce the range and 780 effectiveness of the attacks. The mobile node MUST set to 255 the 781 TTL value in the IP headers of Registration Requests sent to the 782 foreign agent. This prevents malicious nodes more than one hop away 783 from posing as valid mobile nodes. Additional codes for use in 784 registration denials make those attacks that do occur easier to 785 track. 787 With the goal of further reducing the attacks the Mobile IP Working 788 Group considered other mechanisms involving the use of 789 unauthenticated state. However, these introduce the possibilities of 790 denial-of-service attacks. The consensus was that this was too much 791 of a trade-off for mechanisms that guarantee no more than weak 792 (non-cryptographic) protection against attacks. 794 6.2. Ingress Filtering 796 There has been some concern regarding the long-term effectiveness of 797 reverse-tunneling in the presence of ingress filtering. The 798 conjecture is that network administrators will target 799 reverse-tunneled packets (IP in IP encapsulated packets) for 800 filtering. The ingress filtering recommendation spells out why this 801 is not the case [8]: 803 Tracking the source of an attack is simplified when the source is 804 more likely to be "valid." 806 6.3. Reverse Tunneling for Disparate Address Spaces 808 There are security implications involved with the foreign 809 agent's using link-layer information to select the proper 810 reverse tunnel for mobile node packets (section A.3). 811 Unauthenticated link-layers allow a malicious mobile node to 812 misuse another's existing reverse tunnel, and inject packets 813 into the network. 815 For this solution to be viable, the link-layer MUST securely 816 authenticate traffic received by the foreign agent from the 817 mobile nodes. Unauthenticated link-layer technologies (for 818 example shared ethernet) are not recommended to implement 819 disparate address support. 821 Appendix: Disparate Address Space Support 823 Mobile IP [1] assumes that all the entities involved (mobile 824 node, foreign agent and home agent) have addresses within the 825 same globally routable address space. In many deployment 826 scenarios, when a mobile node leaves its home network it may 827 wander into a region where its home address is not routable or 828 known by the local routing fabric. Similarly, the IP addresses 829 of the foreign agent and the home agent may belong to disparate 830 address spaces, which precludes their exchanging registration 831 protocol messages directly. These issues are possible 832 particularly if the entities involved use addresses from the 833 ranges specified in RFC1918 [12] to support private networks. 835 Accurately speaking, the use of private addresses is not the 836 only cause. It may, in fact, be the most common, but the root of 837 the problem lies in the use of disparate address spaces. For 838 example, corporations often have several properly allocated 839 address ranges. They typically advertise reachability to only a 840 subset of those ranges, leaving the others for use exclusively 841 within the corporate network. Since these ranges are not 842 routable in the general Internet, their use leads to the same 843 problems encountered with "private" addresses, even though they 844 are not taken from the ranges specified in RFC1918. 846 Even if the mobile node, home agent and foreign agent all reside 847 within the same address space, problems may arise if the 848 correspondent node does not. However, this problem is not 849 specific to Mobile IP, and is beyond the scope of this 850 document. The next section limits even further the scope of the 851 issues relevant to this document. A subsequent section explains 852 how reverse tunneling may be used to tackle them. 854 A.1. Scope of the Reverse Tunneling Solution 856 Reverse tunneling (as defined in this document) may be used to 857 cope with disparate address spaces, within the following 858 constraints: 860 - There are no provisions to solve the case in which the 861 correspondent node and the mobile node are in disparate 862 address spaces. This limits the scope of the problem to 863 only those issues specific to Mobile IP. 865 - The foreign agent and the home agent are directly reachable 866 to each other by virtue of residing in the same address 867 space. This limits the scope of the problem to only the 868 simplest of cases. This also implies that the registration 869 protocol itself has a direct path between the foreign 870 agent and the home agent, and, in this respect, is not 871 affected by disparate address spaces. This restriction 872 also applies to mobile nodes operating with a co-located 873 care-of address. In this case, reverse tunneling is a 874 complete and elegant solution. 876 - There are no additional protocol elements beyond those 877 defined by Mobile IP [1] and reverse tunneling. In 878 particular, additional extensions to the registration 879 requests or replies, or additional bits in the 880 header--although potentially useful--are outside the scope 881 of this document. 883 In spite of the limitations, reverse tunneling may be used to 884 solve the most common issues. The range of problems that can be 885 solved are best understood by looking at some simple diagrams: 887 Figure A1: NON-ROUTABLE PACKETS IN DISPARATE ADDRESS SPACES 889 Mc Fa Fb Hb Hc Yc 890 [MN]-----------------[FA]----------------[HA]---------------[Y] 891 Addr space A Addr space B Addr space C 893 In this diagram, there are three disparate address spaces: A, B 894 and C. The home agent (HA) has one address each on address 895 spaces B and C, and the foreign agent (FA), on address spaces A 896 and B. The mobile node's (MN) has a permanent address, Mc, 897 within address space C. 899 In the most common scenario both A and C are "private" address 900 spaces, and B is the public Internet. 902 Suppose MN sends a packet to correspondent node (Y) in its home 903 network. Presumably, MN has no difficulties delivering this 904 packet to the FA, because it does so using layer 2 mechanisms. 905 Somehow, the FA must realize that this packet must be reverse 906 tunneled, and it must fetch the proper binding to do so. 907 Possible mechanisms are outlined in section A.3. 909 However, once the packet is in address space B it becomes 910 non-routable. Note that ingress filtering only exacerbates the 911 problem, because it adds a requirement of topological 912 significance to the source IP address in addition to the that of 913 the destination address. As Mobile IP matures, others entities 914 may be defined (for example, AAA servers). Their addition places 915 even more requirements on the address spaces in use. 917 Reverse tunneling adds a topologically significant IP header to 918 the packet (source IP address of Fb, destination of Hb) during 919 its transit within address space B. Assuming IP in IP 920 encapsulation (although others, like GRE are also possible), 921 this is what the packet looks like: 923 Figure A2: IP IN IP REVERSE TUNNELED PACKET FROM FA TO HA 924 +-----------------+ 925 | +-------+| 926 | Fb->Hb | Mc->Yc|| 927 | +-------+| 928 +--------+--------+ 930 HA receives this packet, recovers the original packet, and since 931 it is cognizant of address space C, delivers it to the 932 appropriate interface. 934 Of course, for this to happen, the care-of address registered by 935 the MN is not the usual Fa, but Fb. How this happens is outside 936 the scope of this document. Some possible mechanisms are: 938 - FA recognizes mobile nodes whose addresses fall within 939 the private address ranges specified by RFC1918. In this 940 case, the foreign agent could force the use of Fb as 941 the care-of address, perhaps by rejecting the initial 942 registration request with an appropriate error message 943 and supplemental information. 945 - FA could be configured to always advertise Fb as long 946 as H->Fb and Fb->H are guaranteed to be valid forward 947 and reverse tunnels, respectively, for all values of H. 948 Here, H is the address of any home agent whose mobile 949 nodes may register via FA. 951 - FA could indicate that it supports disparate address spaces 952 via a currently undefined 'P' bit in its advertisements, 953 and an indication of the relevant address space for any or 954 all of its care-of addressed by including an NAI [11] or a 955 realm indicator (perhaps a variant of the NAI). 956 Alternatively, mobile nodes so configured could solicit the 957 NAI or realm indicator information in response to 958 advertisements with the 'P' bit set. 960 Additionally, the mobile node needs to supply the appropriate 961 address for its home agent: Hb instead of the usual Hc. How this 962 happens is outside the scope of this document. Some possible 963 mechanisms are: 965 - This determination could be triggered in response to using 966 the foreign agent's Fb as the care-of address. 968 - The mobile node could always use Hb as its home agent 969 address, specially (1) if Hb is routable within address 970 space C, or (2) if MN is certain never to be at home (in 971 some configurations, the mobile nodes are always roaming). 973 - The mobile node could be configured with different home 974 agent addresses and their corresponding address space 975 (perhaps indicated via an NAI [11] or a variant of it). 977 Another major issue introduced by private addresses is that of 978 two or more mobile nodes with the same numeric IP address: 980 Figure A3: MOBILE NODES WITH CONFLICTING ADDRESSES 982 Mc=M H1b H1c 983 [MN1]-------+ +----[HA1]----+--------- 984 | | | Address 985 | | | space C 986 Address | | Address +---------- 987 Space Fa-[FA]-Fb Space 988 A | | B +--------- 989 | | | Address 990 | | | space D 991 [MN2]-------+ +----[HA2]----+--------- 992 Md=M H2b H2d 994 Suppose there are two address spaces A and B, and a foreign 995 agent (FA) with interfaces on both. There are two home agents 996 (HA1 and HA2) in address space B, with addresses H1b and H2b, 997 respectively. Each of the home agents has an interface in a 998 private address space in addition to address space B: HA1 has 999 H1c on C, and HA2 has H2d on D. MN1 and MN2 are two mobile 1000 nodes with home addresses Mc and Md, corresponding to address 1001 space C and D, respectively. 1003 If Mc and Md are private addresses as defined in RFC1918, they 1004 may be numerically equivalent (both equal to M). Because of 1005 this, the foreign agent can no longer rely on only the mobile 1006 node's home address to disambiguate amongst its different 1007 bindings. 1009 A.2. Terminating Forward Tunnels at the Foreign Agent 1011 In figure A1, suppose the correspondent node Y sends a packet to 1012 the mobile node at address Mc. The packet is intercepted by the 1013 home agent at Hc and tunneled towards the mobile node via 1014 address Fb. 1016 Once the packet reaches FA (via address Fb), the foreign agent 1017 must identify which of its registered mobile nodes is the 1018 ultimate destination for the internal packet. In order to do 1019 so, it needs to identify the proper binding via a tuple 1020 guaranteed to be unique among all of its mobile nodes. 1022 The unique tuple sufficient for demultiplexing IP in IP packets 1023 [IPIP] (protocol 4) is: 1025 - destination IP address of the encapsulated (internal) 1026 header 1028 This is mobile node MN's home address (Mc in the above 1029 example). At first glance, it seems like this is unique 1030 among all mobile nodes, but as mentioned above, with 1031 private addresses another mobile may have an address Md 1032 numerically equivalent to Mc. 1034 - source IP address of the external header 1036 This, the remote end of the tunnel, is Hb in the above 1037 example. 1039 - destination IP address of the external header 1041 This, the local end of the tunnel, is Fb in the above 1042 example. 1044 The three values above are learned from a successful 1045 registration and are the mobile node's home address, the home 1046 agent's address and the care-of address. Thus, it is possible to 1047 identify the right binding. Once FA identifies the ultimate 1048 destination of the packet, Mc, it delivers the internal packet 1049 using link layer mechanisms. 1051 GRE packets [10] (protocol 47) are only handled if their 1052 Protocol Type field has a value of 0x800 (other values are 1053 outside the scope of this document), and are demultiplexed based 1054 on the same tuple as IP in IP packets. In GRE terminology, the 1055 tuple is: 1057 - destination IP address of the payload (internal) packet 1059 - source IP address of the delivery (external) packet 1061 - destination IP address of the delivery (external) packet 1063 Notice that the Routing, Sequence Number, Strict Source Route 1064 and Key fields have been deprecated from GRE [10]. However, 1065 a separate document specifies their use [13]. 1067 The above tuples work for IP-in-IP or GRE encapsulation, and 1068 assume that the inner packet is in the clear. Encapsulations 1069 which encrypt the inner packet header are outside the scope 1070 of this document. 1072 A.3. Initiating Reverse Tunnels at the Foreign Agent 1074 In figure A3, suppose mobile node M1 sends a packet to a 1075 correspondent node in its home address space, C, and mobile node 1076 M2 sends a packet to a correspondent node in its home address 1077 space, D. 1079 At FA, the source addresses for both packets will be seen as M, 1080 thus this is not sufficient information. The unique tuple 1081 required to identify the proper binding is: 1083 - link-layer information related to the MN 1085 This may be in the form of a MAC address, a PPP session (or 1086 incoming interface) or channel coding for a digital 1087 cellular service. Device ID's can also be used in this 1088 context. 1090 - source IP address of the IP header. 1092 As was pointed out, this by itself is not guaranteed to be 1093 unique. 1095 This information must be established and recorded at 1096 registration time. The above items are sufficient for the 1097 foreign agent to select the proper binding to use. This, in 1098 turn, produces the address of the home agent, and the reverse 1099 tunneling options negotiated during the registration process. 1100 The foreign agent can now proceed with reverse tunneling. 1102 A.4. Limited Private Address Scenario 1104 The Limited Private Address Scenario (LPAS) has received much 1105 attention from the cellular wireless industry, so it is useful 1106 to define it and to clarify what its requirements are. 1108 LPAS is a subset of the disparate address space scenario 1109 discussed in this appendix. This section explains how LPAS could 1110 be deployed given the current state of the Mobile IP 1111 specifications. 1113 Figure A4: EXAMPLE PRIVATE ADDRESS SCENARIO 1115 10.10.1.2 1116 +----+ IF1=COA1+-------+ HAA2 +-----+ 1117 | MN1|------------------------| FA |---------| HA2 | 1118 +----+ +------------| | +-----+ 1119 | IF2=COA2+-------+ 1120 +---+ | 1121 | | 1122 +-----+ | 1123 | MN2 | | 1124 +-----+ | 1125 10.10.1.2 | 1126 | HAA1 1127 +------+ 1128 | HA1 | 1129 +------+ 1131 The above figure presents a very simple scenario in which 1132 private addresses are used. Here, "private addresses" are 1133 strictly those defined in RFC 1918 [12]. In this deployment 1134 scenario, the only entities that have private addresses are the 1135 mobile nodes. Foreign agent and home agent addresses are 1136 publicly routable on the general Internet. More specifically, 1137 the care-of addresses advertised by the foreign agents (COA1 and 1138 COA2 in Figure A4) and the home agent addresses used by mobile 1139 nodes in registration requests (HAA1 and HAA2 in Figure A4) are 1140 publicly routable on the general Internet. As a consequence, any 1141 Mobile IP tunnels can be established between any home agent home 1142 address and any foreign agent care-of address. 1144 Also, note that two different mobile nodes (MN1 and MN2) with 1145 the same private address (10.10.1.2) are visiting the same 1146 foreign agent FA. This is supported as long as MN1 and MN2 are 1147 serviced by different home agents. Hence, from any given home 1148 agent's perspective, each mobile node has a unique IP address, 1149 even if it happens to be a private address as per RFC 1918. 1151 Operation in the presence of route optimization [4] is outside 1152 the scope of this document. 1154 Requirements for the above private address scenario: 1156 Mobile node requirements: 1158 Mobile nodes intending to use private addresses with 1159 Mobile IP MUST set the 'T' bit and employ reverse 1160 tunneling. Mobile node's private addresses within a given 1161 address space MUST be unique. Thus two mobile nodes 1162 belonging to a single home agent cannot have the same 1163 private addresses. Thus, when receiving or sending 1164 tunneled traffic for a mobile node, the tunnel endpoints 1165 are used to disambiguate amongst conflicting mobile node 1166 addresses. 1168 If the mobile node happens to register with multiple home 1169 agents simultaneously through the same foreign agent, 1170 there must be some link-layer information that is distinct 1171 for each mobile node. If no such distinct link-layer 1172 information is available, the mobile nodes MUST use unique 1173 address. 1175 Foreign agent requirements: 1177 All advertising interfaces of the foreign agent MUST have 1178 publicly routable care-of address. Thus, a mobile node 1179 with a private address visits the foreign agent only in 1180 its publicly routable network. 1182 Foreign agents MUST support reverse tunneling in order to 1183 support private addressed mobile nodes. If a foreign 1184 agent receives a registration request from a mobile node 1185 with a private address, and the mobile node has not set 1186 the 'T' bit, the foreign agent SHOULD reject it. 1188 When delivering packets to or receiving packets from 1189 mobile nodes, foreign agents MUST disambiguate among 1190 mobile node with conflicting private addresses by using 1191 link-layer information as mentioned previously (Appendix 1192 section A.2 and A.3). A foreign agent in absence of route 1193 optimization, should make sure that two mobile nodes 1194 visiting the same foreign agent corresponds with each 1195 other through their respective home agents. 1197 If a foreign agent supports reverse tunneling, then it 1198 MUST support the simple scenario of private address 1199 support described in this section. 1201 Home agent requirements: 1203 Any home agent address used by mobile nodes in 1204 registration request MUST be a publicly routable address. 1205 Home agents will not support overlapping private home 1206 addresses, thus each private home address of a mobile node 1207 registered with a home agent is unique. When the 'T' bit 1208 is set in the registration request from the mobile node, 1209 the home agent MUST recognize and accept registration 1210 request from mobile nodes with private addresses. Also, 1211 the home agent SHOULD be able to assign private addresses 1212 out of its address pool to mobile nodes for use as home 1213 addresses. This does not contravene home agent processing 1214 in section 3.8 of RFC2002-bis. 1216 7. Acknowledgements 1218 The encapsulating style of delivery was proposed by Charlie 1219 Perkins. Jim Solomon has been instrumental in shaping this 1220 document into its present form. Thanks to Samita Chakrabarti for 1221 helpful comments on disparate address space support, and for 1222 most of the text in section A.4. 1224 Changes from Previous Version of the Draft 1226 This section lists the changes with respect to the previous version 1227 of this draft. 1229 - Changed some wording to reflect that home agents now MUST (as 1230 oppposed to SHOULD) support reverse tunneling. This was 1231 changed from RFC 2002 by 2002-bis. 1233 - 'V' bit not used anymore, reflecting rfc2002bis. 1235 - Made Encapsulating Delivery Support optional by demoting from 1236 a MUST to a should. This also required defining a new error 1237 code 79 (to be assigned by IANA). 1239 - Mentioned the possibility of an admissible authentication 1240 extension which may be different from the Mobile-Home 1241 authentication extension. 1243 - Added a section on LPAS (Limited Private Address Support) 1245 References 1247 [1] C. Perkins. "IP Mobility Support, revised," (work in 1248 progress), draft-ietf-mobileip-rfc2002-bis-02.txt, July 1249 2000. 1251 [2] C. Perkins. IP Encapsulation within IP. RFC 2003, October 1252 1996. 1254 [3] Computer Emergency Response Team (CERT), "IP Spoofing Attacks 1255 and Hijacked Terminal Connections", CA-95:01, January 1995. 1256 Available via anonymous ftp from info.cert.org in 1257 /pub/cert_advisories. 1259 [4] C. Perkins and D. Johnson. Route Optimization in Mobile IP 1260 (work in progress), draft-ietf-mobileip-optim-09.txt, 1261 February 2000. 1263 [5] Manuel Rodriguez, private communication, August 1995. 1265 [6] S. Kent, R. Atkinson, "IP Authentication Header," RFC 2402, 1266 November 1998 (obsoletes RFC 1826, August 1995). 1268 [7] S. Kent, R. Atkinson, "IP Encapsulating Payload," RFC 2406, 1269 November 1998 (obsoletes RFC 1827, August 1995). 1271 [8] P. Ferguson and D. Senie. Network Ingress Filtering: Defeating 1272 Denial of Service Attacks which employ IP Source Address 1273 Spoofing. RFC 2267, January 1998. 1275 [9] S. Bradner. Key words for use in RFCs to Indicate Requirement 1276 Levels. RFC 2119, March 1997. 1278 [10] Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina, P., 1279 "Generic Routing Encapsulation (GRE)," RFC 2784, March 1280 2000. 1282 [11] B. Aboba and M. Beadles. The Network Access Identifier. RFC 1283 2486, January 1999. 1285 [12] Y. Rekhter, B. Moskowitz, D. Karrenberg, G.J. de Groot, E. 1286 Lear, "Address Allocation for Private Internets," RFC 1918, 1287 February 1996. 1289 [13] G. Dommety, "Key and Sequence Number Extensions to GRE," 1290 (work in progress), draft-dommety-gre-ext-04.txt, 1291 June 2000. 1293 Editor and Chair Addresses 1295 Questions about this document may be directed at: 1297 Gabriel E. Montenegro 1298 Sun Microsystems, Inc. 1299 901 San Antonio Road 1300 Mailstop UMPK 15-214 1301 Mountain View, California 94303 1303 Voice: +1-650-786-6288 1304 Fax: +1-650-786-6445 1306 E-Mail: gab@sun.com 1308 The working group can be contacted via the current chairs: 1310 Basavaraj Patil Phil Roberts 1311 Nokia Networks Motorola 1312 6000 Connection Drive 1501 West Shure Drive 1313 Irving, TX 75039 Arlington Heights, IL 60004 1314 USA USA 1315 Phone: +1 972-894-6709 Phone: +1 847-632-3148 1316 Fax : +1 972-894-5349 EMail: QA3445@email.mot.com 1317 EMail: Raj.Patil@nokia.com 1319 Copyright (c) The Internet Society (2000). All Rights Reserved. 1321 This document and translations of it may be copied and furnished to 1322 others, and derivative works that comment on or otherwise explain it 1323 or assist in its implementation may be prepared, copied, published 1324 and distributed, in whole or in part, without restriction of any 1325 kind, provided that the above copyright notice and this paragraph are 1326 included on all such copies and derivative works. However, this 1327 document itself may not be modified in any way, such as by removing 1328 the copyright notice or references to the Internet Society or other 1329 Internet organizations, except as needed for the purpose of 1330 developing Internet standards in which case the procedures for 1331 copyrights defined in the Internet Standards process must be 1332 followed, or as required to translate it into languages other than 1333 English. 1335 The limited permissions granted above are perpetual and will not be 1336 revoked by the Internet Society or its successors or assigns. 1338 This document and the information contained herein is provided on an 1339 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1340 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1341 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1342 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1343 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.