idnits 2.17.1 draft-ietf-mobileip-tunnel-reverse-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 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. ** 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 220: '...sets the 'T' bit MUST support the two ...' RFC 2119 keyword, line 274: '... Style Extension MAY be included by th...' RFC 2119 keyword, line 277: '...he foreign agent MUST consume this ext...' RFC 2119 keyword, line 280: '... mobile node MUST include the Revers...' RFC 2119 keyword, line 286: '... Extension MUST NOT be included if t...' (40 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 243 has weird spacing: '... agents proba...' == Line 358 has weird spacing: '...her the home ...' -- 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 (March 26, 1997) is 9886 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-05 -- 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) Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 5 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 March 26, 1997 6 Reverse Tunneling for Mobile IP 7 draft-ietf-mobileip-tunnel-reverse-02.txt 9 Status of This Memo 11 This document is a submission by the Mobile IP Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the Working Group mailing list at "mobile-ip@SmallWorks.COM". 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet- Drafts as 25 reference material or to cite them other than as ``work in 26 progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 30 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 Mobile IP uses tunneling from the home agent to the mobile node's 37 care-of address, but rarely in the reverse direction. Usually, a 38 mobile node sends its packets through a router on the foreign 39 network, and assumes that routing is independent of source address. 40 When this assumption is not true, it is convenient to establish a 41 topologically correct reverse tunnel from the care-of address to the 42 home agent. 44 This document proposes backwards-compatible extensions to Mobile IP 45 in order to support topologically correct reverse tunnels. This 46 document does not attempt to solve the problems posed by firewalls 47 located between the home agent and the mobile node's care-of 48 address. 50 Table of Contents 52 1. Introduction ................................................... 3 53 1.1. Terminology .................................................. 4 54 1.2. Assumptions .................................................. 4 55 1.3. Justification ................................................ 4 56 2. Overview ....................................................... 5 57 3. New Packet Formats ............................................. 5 58 3.1. Mobility Agent Advertisement Extension ....................... 5 59 3.2. Registration Request ......................................... 6 60 3.3. Reverse Tunnel Delivery Style Extension ...................... 7 61 3.4. New Registration Reply Codes ................................. 8 62 4. Changes in Protocol Behavior ................................... 9 63 4.1. Mobile Node Considerations ................................... 9 64 4.2. Foreign Agent Considerations ................................. 10 65 4.3. Home Agent Considerations .................................... 10 66 5. Mobile Node to Foreign Agent Delivery Styles ................... 11 67 5.1. Direct Delivery Style ........................................ 11 68 5.1.1. Packet Processing .......................................... 12 69 5.1.2. Packet Header Format and Fields ............................ 12 70 5.2. Encapsulating Delivery Style ................................. 13 71 5.2.1 Packet Processing ........................................... 13 72 5.2.2. Packet Header Format and Fields ............................ 13 73 5.3. Support for Broadcast and Multicast Datagrams ................ 15 74 5.4. Selective Reverse Tunneling .................................. 15 75 6. Security Considerations ........................................ 16 76 7. Acknowledgements ............................................... 16 77 References ........................................................ 16 78 Editor and Chair Addresses ........................................ 17 79 1. Introduction 81 Section 1.3 of the Mobile IP specification [1] lists the following 82 assumption: 84 It is assumed that IP unicast datagrams are routed based on the 85 destination address in the datagram header (i.e., not by source 86 address). 88 Because of security concerns (e.g. IP spoofing attacks), and in 89 accordance with the IAB [8] and CERT [3] advisories to this effect, 90 routers that break this assumption are increasingly more common. 92 In the presence of such routers, the source and destination IP 93 address in a packet must be topologically correct. The forward 94 tunnel complies with this, as its endpoints (home agent address and 95 care-of address) are properly assigned addresses for their 96 respective locations. On the other hand, the source IP address of a 97 packet transmitted by the mobile node does not correspond to the 98 location from where it emanates. 100 This document discusses topologically correct reverse tunnels. 102 Mobile IP does dictate the use of reverse tunnels in the context of 103 multicast datagram routing and mobile routers. However, the source 104 IP address is set to the mobile node's home address, so these 105 tunnels are not topologically correct. 107 Notice that there are several uses for reverse tunnels regardless of 108 their topological correctness: 110 - Mobile routers: reverse tunnels obviate the need for recursive 111 tunneling [1]. 113 - Multicast: reverse tunnels enable a mobile node away from home 114 to (1) join multicast groups in its home network, and (2) 115 transmit multicast packets such that they emanate from its home 116 network [1]. 118 - The TTL of packets sent by the mobile node (particularly when 119 sends packets to other hosts in its home network) may be so low 120 that they might expire before reaching their destination. A 121 reverse tunnel solves the problem as it represents a TTL 122 decrement of one [5]. 124 1.1. Terminology 126 The discussion below uses terms defined in the Mobile IP 127 specification. Additionally, it uses the following terms: 129 Forward Tunnel 131 A tunnel that shuttles packets towards the mobile node. It 132 starts at the home agent, and ends at the mobile node's 133 care-of address. 135 Reverse Tunnel 137 A tunnel that starts at the mobile node's care-of address and 138 terminates at the home agent. 140 1.2. Assumptions 142 Mobility is constrained to a common IP address space (e.g. the 143 routing fabric between, say, the mobile node and the home agent is 144 not partitioned into a "private" and a "public" network). 146 This document does not attempt to solve the firewall traversal 147 problem. Rather, it assumes one of the following is true: 149 - There are no intervening firewalls along the path of the 150 tunneled packets. 152 - Any intervening firewalls share the security association 153 necessary to process any authentication [6] or encryption [7] 154 headers which may have been added to the tunneled packets. 156 The reverse tunnels considered here are symmetric, that is, they use 157 the same configuration (encapsulation method, IP address endpoints) 158 as the forward tunnel. IP in IP encapsulation [2] is assumed unless 159 stated otherwise. 161 Route optimization [4] introduces forward tunnels initiated at a 162 correspondent host. Since a mobile node may not know if the 163 correspondent host can decapsulate packets, reverse tunnels in that 164 context are not discussed here. 166 1.3. Justification 168 Why not let the mobile node itself initiate the tunnel to the home 169 agent? This is indeed what it should do if it is already operating 170 with a topologically correct co-located care-of address. 172 However, one of the primary objectives of the Mobile IP 173 specification is not to require this mode of operation. 175 The mechanisms outlined in this document are primarily intended for 176 use by mobile nodes that rely on the foreign agent for forward 177 tunnel support. It is desirable to continue supporting these mobile 178 nodes, even in the presence of filtering routers. 180 2. Overview 182 A mobile node arrives at a foreign network, listens for agent 183 advertisements and selects a foreign agent that supports reverse 184 tunnels. It requests this service when it registers through the 185 selected foreign agent. At this time, and depending on how the 186 mobile node wishes to deliver packets to the foreign agent, it also 187 requests either the Direct or the Encapsulating Delivery Style 188 (section 5). 190 In the Direct Delivery Style, the mobile node designates the foreign 191 agent as its default router and proceeds to send packets directly to 192 the foreign agent, i.e., without encapsulation. The foreign agent 193 intercepts them, and tunnels them to the home agent. 195 In the Encapsulating Delivery Style, the mobile node encapsulates 196 all its outgoing packets to the foreign agent. The foreign agent 197 decapsulates and re-tunnels them to the home agent, using the 198 foreign agent's care-of address as the entry-point of this new 199 tunnel. 201 3. New Packet Formats 203 3.1. Mobility Agent Advertisement Extension 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Type | Length | Sequence Number | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Lifetime |R|B|H|F|M|G|V|T| reserved | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | zero or more Care-of Addresses | 213 | ... | 215 The only change to the Mobility Agent Advertisement Extension [1] is 216 the additional 'T' bit: 218 T Agent offers reverse tunneling service. 220 A foreign agent that sets the 'T' bit MUST support the two delivery 221 styles currently supported: Direct and Encapsulating Delivery Style 222 (section 5). 224 Using this information, a mobile node is able to choose a foreign 225 agent that supports reverse tunnels. Notice that if a mobile node 226 does not understand this bit, it simply ignores it as per [1]. 228 3.2. Registration Request 230 Reverse tunneling support is added directly into the Registration 231 Request by using one of the "rsvd" bits. If a foreign or home agent 232 that does not support reverse tunnels receives a request with the 233 'T' bit set, the Registration Request fails. This results in a 234 registration denial (failure codes are specified in section 3.4). 236 Most home agents would not object to providing reverse tunnel 237 support, because they "SHOULD be able to decapsulate and further 238 deliver packets addressed to themselves, sent by a mobile node" 239 [1]. In the case of topologically correct reverse tunnels, the 240 packets are not sent by the mobile node as distinguished by its home 241 address. Rather, the outermost (encapsulating) IP source address on 242 such datagrams is the care-of address of the mobile node. 243 Nevertheless, home agents probably already support the required 244 decapsulation and further forwarding. 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Type |S|B|D|M|G|V|T|-| Lifetime | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Home Address | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Home Agent | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Care-of Address | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Identification | 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Extensions ... 261 +-+-+-+-+-+-+-+- 263 The only change to the Registration Request packet is the additional 264 'T' bit: 266 T If the 'T' bit is set, the mobile node asks its home 267 agent to accept a reverse tunnel from the care-of 268 address. Mobile nodes using a foreign agent care-of 269 address ask the foreign agent to reverse-tunnel its 270 packets. 272 3.3. Reverse Tunnel Delivery Style Extension 274 The Reverse Tunnel Delivery Style Extension MAY be included by the 275 mobile node in registration requests to further specify reverse 276 tunneling behavior. It is expected to be used only by the foreign 277 agent. Accordingly, the foreign agent MUST consume this extension 278 (i.e. it must not relay it to the home agent or include it in 279 replies to the mobile node). As per Section 3.6.1.3 of [1], the 280 mobile node MUST include the Reverse Tunnel Delivery Style Extension 281 after the Mobile-Home Authentication Extension, and before the 282 Mobile-Foreign Authentication Extension, if present. 284 Currently, it is only possible to request the encapsulating style of 285 delivery, but future behavior may be defined. The Reverse Tunnel 286 Extension MUST NOT be included if the 'T' bit is not set in the 287 Registration Request. 289 If this extension is absent, or if no style is explicitly requested, 290 Direct Delivery is assumed. Besides the latter, currently only the 291 Encapsulating style is defined (section 5). 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Type | Length |E| reserved | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 Type 128 301 Length 2 303 E Encapsulating style of delivery. Encapsulation is done 304 according to what was negotiated for the forward tunnel 305 (i.e., IP in IP is assumed unless specified otherwise). 307 reserved Ignored upon reception. Must be set to zero when 308 transmitting. 310 3.4. New Registration Reply Codes 312 Foreign and home agent registration replies MUST convey if the 313 reverse tunnel request failed. Four new reply codes are defined: 315 Service denied by the foreign agent: 317 74 requested reverse tunnel unavailable 318 75 reverse tunnel is mandatory and 'T' bit not set 320 and 322 Service denied by the home agent: 324 137 requested reverse tunnel unavailable 325 138 reverse tunnel is mandatory and 'T' bit not set 327 In response to a registration request with the 'T' bit set, mobile 328 nodes may receive (and MUST accept) code 70 (poorly formed request) 329 from foreign agents and code 134 (poorly formed request) from home 330 agents. However, foreign and home agents that support reverse 331 tunneling MUST use codes 74 and 137, respectively. 333 Forward and reverse tunnels are symmetric, i.e. both are able to use 334 the same tunneling options negotiated at registration. This implies 335 that the home agent MUST deny registrations if an unsupported 336 form of tunneling is requested: 338 139 requested encapsulation unavailable 340 Notice that Mobile IP [1] already defines the analogous failure code 341 72 for use by the foreign agent. 343 4. Changes in Protocol Behavior 345 Reverse tunnels must be handled appropriately by the different 346 mobility entities. Differences in protocol behavior with respect to 347 the Mobile IP specification are specified in the subsequent 348 sections. 350 4.1. Mobile Node Considerations 352 In addition to the considerations in [1], a mobile node sets the 'T' 353 bit in its Registration Request to petition a reverse tunnel. It may 354 optionally include a Reverse Tunnel Delivery Style Extension. 356 Possible outcomes are: 358 - Either the home agent or the foreign agent returns a 359 registration denial: 361 a. The mobile node follows the error checking guidelines in 362 [1], and depending on the reply code, MAY try modifying the 363 registration request (for example by eliminating the 364 request for alternate forms of encapsulation), and issuing 365 a new registration. 367 b. Depending on the reply code, the mobile node MAY try 368 zeroing the 'T' bit, eliminating the Reverse Tunnel 369 Delivery Style Extension (if one was present), and issuing 370 a new registration. 372 - The home agent returns a Registration Reply indicating that the 373 service will be provided. 375 In this last case, the mobile node has succeeded in establishing a 376 reverse tunnel between its care-of address and its home agent. If 377 the mobile node is operating with a co-located care-of address, it 378 MAY encapsulate outgoing data such that the destination address of 379 the outer header is the home agent. This ability to selectively 380 reverse-tunnel packets is discussed further in section 5.4. 382 If the care-of address belongs to a separate foreign agent, the 383 mobile node MUST employ whatever delivery style was requested 384 (Direct or Encapsulating) and proceed as specified in section 385 5. 387 A successful registration reply is an assurance that both the 388 foreign agent and the home agent support whatever alternate forms of 389 encapsulation (other than IP in IP) were requested. Accordingly, the 390 mobile node MAY use them at its discretion. 392 4.2. Foreign Agent Considerations 394 A foreign agent that receives a Registration Request with the 'T' 395 bit set processes the packet as specified in the Mobile IP 396 specification [1], and determines whether it can accomodate the 397 forward tunnel request. If it cannot, it returns an appropriate 398 code. In particular, if the foreign agent is unable to support the 399 requested form of encapsulation it MUST return code 72. 401 The foreign agent MAY reject registration requests without the 'T' 402 bit set by denying them with code 75 (reverse tunnel is mandatory 403 and 'T' bit not set). 405 As a last check, the foreign agent verifies that it can support a 406 reverse tunnel with the same configuration. If it cannot, it MUST 407 return a Registration Reply denying the request with code 74 408 (requested reverse tunnel unavailable). 410 Otherwise, the foreign agent MUST relay the Registration Request to 411 the home agent. 413 Upon receipt of a Registration Reply that satisfies validity checks, 414 the foreign agent MUST update its visitor list, including indication 415 that this mobile node has been granted a reverse tunnel and the 416 delivery style expected (section 5). 418 While this visitor list entry is in effect, the foreign agent MUST 419 process incoming traffic according to the delivery style, 420 encapsulate it and tunnel it from the care-of address to the home 421 agent's address. 423 4.3. Home Agent Considerations 425 A home agent that receives a Registration Request with the 'T' bit 426 set processes the packet as specified in the Mobile IP specification 427 [1] and determines whether it can accomodate the forward tunnel 428 request. If it cannot, it returns an appropriate code. In 429 particular, if the home agent is unable to support the requested 430 form of encapsulation it MUST return code 139. 432 The home agent MAY reject registration requests without the 'T' bit 433 set by denying them with code 138 (reverse tunnel is mandatory and 434 'T' bit not set). 436 As a last check, the home agent determines whether it can support a 437 reverse tunnel with the same configuration as the forward tunnel. If 438 it cannot, it MUST send back a registration denial with code 137. 440 Upon receipt of a Registration Reply that satisfies validity checks, 441 the home agent MUST update its mobility bindings list indication 442 that this mobile node has been granted a reverse tunnel and the type 443 of encapsulation expected. 445 After a successful registration, the home agent may receive 446 encapsulated packets addressed to it. For each such packet it MAY 447 search for a mobility binding whose care-of address is the source of 448 the outer header, and whose mobile node address is the source of the 449 inner header. If no such binding is found, or if the packet uses an 450 encapsulation mechanism that was not negotiated at registration the 451 home agent MUST silently discard the packet and SHOULD log the event 452 as a security exception. 454 While the registration is in effect, a home agent MUST process each 455 valid reverse tunneled packets (as determined by checks like the 456 above) by decapsulating it, recovering the original packet, and then 457 forwarding it on behalf of its sender (the mobile node) to the 458 destination address (the correspondent host). 460 5. Mobile Node to Foreign Agent Delivery Styles 462 This section specifies how the mobile node sends its data traffic 463 via the foreign agent. In all cases, the mobile node learns the 464 foreign agent's link-layer address from the link-layer header in the 465 agent advertisement. 467 5.1. Direct Delivery Style 469 This delivery mechanism is very simple to implement, and uses small 470 (non-encapsulated) packets on the link between the mobile node and 471 the foreign agent (potentially a very slow link). However, it only 472 supports reverse-tunneling of unicast packets, and does not allow 473 selective reverse tunneling (section 5.4). 475 5.1.1. Packet Processing 477 The mobile node MUST designate the foreign agent as its default 478 router. Not doing so will not guarantee encapsulation of all the 479 mobile node's outgoing traffic, and defeats the purpose of the 480 reverse tunnel. The foreign agent MUST: 482 - detect packets sent by the mobile node, and 484 - modify its forwarding function to re-encapsulate them before 485 forwarding. 487 5.1.2. Packet Header Format and Fields 489 This section shows the format of the packet headers used by the 490 Direct Delivery style. The formats shown assume IP in IP 491 encapsulation [2]. 493 Packet format received by the foreign agent (Direct Delivery 494 Style): 496 Data Link fields: 497 Source Address = mobile node's link-layer address 498 Destination Address = foreign agent's link-layer address 499 IP fields: 500 Source Address = mobile node's home address 501 Destination Address = correspondent host's address 502 Upper Layer Protocol 504 Packet format forwarded by the foreign agent (Direct Delivery 505 Style): 507 Data Link fields: 508 Source Address = foreign agent's link-layer address 509 Destination Address = next hop router's link-layer address 510 IP fields (encapsulating header): 511 Source Address = foreign agent's care-of address 512 Destination Address = home agent's address 513 Protocol field: 4 (IP in IP) 514 IP fields (original header): 515 Source Address = mobile node's home address 516 Destination Address = correspondent host's address 517 Upper Layer Protocol 519 These fields of the encapsulating header MUST be chosen as follows: 521 IP Source Address 523 Copied from the Care-of Address field within the Registration 524 Request. 526 IP Destination Address 528 Copied from the Home Agent field within the Registration 529 Request. 531 IP Protocol Field 533 Default is 4 (IP in IP [2]), but other methods of 534 encapsulation MAY be used as negotiated at registration time. 536 5.2. Encapsulating Delivery Style 538 This mechanism requires that the mobile node implement 539 encapsulation, and explicitly directs packets at the foreign agent 540 by designating it as the destination address in a new outermost 541 header. Mobile nodes that wish to send either broadcast or 542 multicast packets MUST use the Encapsulating Delivery Style. 544 5.2.1 Packet Processing 546 The foreign agent does not modify its forwarding function. 547 Rather, it receives an encapsulated packet and after verifying that 548 it was sent by the mobile node, it: 550 - decapsulates to recover the inner packet, 552 - re-encapsulates, and sends it to the home agent. 554 If a foreign agent receives an un-encapsulated packet from a mobile 555 node which had explicitly requested the Encapsulated Delivery Style, 556 then the foreign agent MUST NOT reverse tunnel such a packet and 557 rather MUST forward it using standard, IP routing mechanisms. 559 5.2.2. Packet Header Format and Fields 561 This section shows the format of the packet headers used by the 562 Encapsulating Delivery style. The formats shown assume IP in IP 563 encapsulation [2]. 565 Packet format received by the foreign agent (Encapsulating Delivery 566 Style): 568 Data Link fields: 569 Source Address = mobile node's link-layer address 570 Destination Address = foreign agent's link-layer address 571 IP fields (encapsulating header): 572 Source Address = mobile node's home address 573 Destination Address = foreign agent's address 574 Protocol field: 4 (IP in IP) 575 IP fields (original header): 576 Source Address = mobile node's home address 577 Destination Address = correspondent host's address 578 Upper Layer Protocol 580 The fields of the encapsulating IP header MUST be chosen as 581 follows: 583 IP Source Address 585 The mobile node's home address. 587 IP Destination Address 589 The address of the agent as learned from the IP source address 590 of the agent's most recent registration reply. 592 IP Protocol Field 594 Default is 4 (IP in IP [2]), but other methods of 595 encapsulation MAY be used as negotiated at registration time. 597 Packet format forwarded by the foreign agent (Encapsulating Delivery 598 Style): 600 Data Link fields: 601 Source Address = foreign agent's link-layer address 602 Destination Address = next hop router's link-layer address 603 IP fields (encapsulating header): 604 Source Address = foreign agent's care-of address 605 Destination Address = home agent's address 606 Protocol field: 4 (IP in IP) 607 IP fields (original header): 608 Source Address = mobile node's home address 609 Destination Address = correspondent host's address 610 Upper Layer Protocol 612 These fields of the encapsulating IP header MUST be chosen as 613 follows: 615 IP Source Address 617 Copied from the Care-of Address field within the Registration 618 Request. 620 IP Destination Address 622 Copied from the Home Agent field within the Registration 623 Request. 625 IP Protocol Field 627 Default is 4 (IP in IP [2]), but other methods of 628 encapsulation MAY be used as negotiated at registration time. 630 5.3. Support for Broadcast and Multicast Datagrams 632 If a mobile node is operating with a co-located care-of address, 633 broadcast and multicast datagrams are handled according to Sections 634 4.3 and 4.4 of the Mobile IP specification [1]. Mobile nodes using a 635 foreign agent care-of address MAY have their broadcast and multicast 636 datagrams reverse-tunneled by the foreign agent. However, any 637 mobile nodes doing so MUST use of the encapsulating delivery style. 639 This delivers the datagram only to the foreign agent. The latter 640 decapsulates it and then processes it as any other packet from the 641 mobile node, namely, by reverse tunneling it to the home agent. 643 5.4. Selective Reverse Tunneling 645 Packets destined to local resources (e.g. a nearby printer) might be 646 unaffected by ingress filtering. A mobile node with a co-located 647 care-of address MAY optimize delivery of these packets by not 648 reverse tunneling them. On the other hand, a mobile node using a 649 foreign agent care-of addres MAY use this selective reverse 650 tunneling capability by requesting the Encapsulating Delivery Style, 651 and following these guidelines: 653 Packets meant to be reversed tunneled: 655 Sent using the Direct Delivery style. The foreign agent 656 MUST process these packets as regular traffic: they MAY be 657 forwarded but MUST NOT be reverse tunneled to the home agent. 659 Packets NOT meant to be reverse tunneled: 661 Sent using the Encapsulating Delivery style. The foreign agent 662 MUST process these packets as specified in section 5.2: they 663 MUST be reverse tunneled to the home agent. 665 6. Security Considerations 667 The extensions outlined in this document are subject to the security 668 considerations outlined in the Mobile IP specification [1]. 669 Essentialy, creation of both forward and reverse tunnels involves an 670 authentication procedure, which reduces the risk for attack. 672 However, once the tunnel is set up, a malicious user could hijack it 673 to inject packets into the network. Reverse tunnels might exacerbate 674 this problem, because upon reaching the tunnel exit point packets 675 are forwarded beyond the local network. This concern is also present 676 in the Mobile IP specification, as it already dictates the use of 677 reverse tunnels for certain applications. 679 There has been some concern regarding the long-term effectiveness of 680 reverse-tunneling in the presence of ingress filtering. The 681 conjecture is that network administrators will target 682 reverse-tunneled packets (IP in IP encapsulated packets) for 683 filtering. The ingress filtering recommendation spells out why this 684 is not the case [8]: 686 Tracking the source of an attack is simplified when the source is 687 more likely to be "valid." 689 7. Acknowledgements 691 The encapsulating style of delivery was proposed by Charlie 692 Perkins. Jim Solomon has been instrumental in shaping this document 693 into its present form. 695 References 697 [1] C. Perkins. IP Mobility Support. RFC 2002, October 1996. 699 [2] C. Perkins. IP Encapsulation within IP. RFC 2003, October 700 1996. 702 [3] Computer Emergency Response Team (CERT), "IP Spoofing Attacks 703 and Hijacked Terminal Connections", CA-95:01, January 1995. 705 Available via anonymous ftp from info.cert.org in 706 /pub/cert_advisories. 708 [4] D. Johnson and C. Perkins. Route Optimization in Mobile IP -- 709 work in progress, draft-ietf-mobileip-optim-05.txt, November 710 1996. 712 [5] Manuel Rodriguez, private communication, August 1995. 714 [6] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. 716 [7] R. Atkinson. IP Encapsulating Security Payload. RFC 1827, 717 August 1995. 719 [8] P. Ferguson and D. Senie. Network Ingress Filtering: Defending 720 Against IP Source Address Spoofing -- work in progress, 721 draft-ferguson-ingress-filtering-02.txt, March 1997. 723 Editor and Chair Addresses 725 Questions about this document may be directed at: 727 Gabriel E. Montenegro 728 Sun Microsystems, Inc. 729 2550 Garcia Avenue 730 Mailstop UMPK 15-214 731 Mountain View, California 94043-1100 733 Voice: +1-415-786-6288 734 Fax: +1-415-786-6445 735 E-Mail: gab@eng.sun.com 737 The working group can be contacted via the current chairs: 739 Jim Solomon 740 Motorola, Inc. 741 1301 E. Algonquin Rd. - Rm 2240 742 Schaumburg, IL 60196 744 Voice: +1-847-576-2753 745 Fax: +1-847-576-3240 746 E-Mail: solomon@comm.mot.com 748 Erik Nordmark 749 Sun Microsystems, Inc. 750 2550 Garcia Avenue 751 Mailstop UMPK17-202 752 Mountain View, California 94043-1100 754 Voice: +1-415-786-5166 755 E-Mail: nordmark@eng.sun.com