idnits 2.17.1 draft-ietf-mobileip-ip4inip4-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 154: '... of the inner IP header MAY affect the...' RFC 2119 keyword, line 184: '...is set in the inner IP header, it MUST...' RFC 2119 keyword, line 186: '...er IP header, it MAY be set in the out...' RFC 2119 keyword, line 217: '... the tunnel path MAY be added. In par...' RFC 2119 keyword, line 218: '... of the inner IP header MAY affect the...' (33 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (31 May 1996) is 10182 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 1826 (ref. '1') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. '2') (Obsoleted by RFC 2406) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 1435 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 1254 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '11') Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force C. Perkins 2 INTERNET DRAFT IBM 3 31 May 1996 5 IP Encapsulation within IP 6 draft-ietf-mobileip-ip4inip4-03.txt 8 Status of This Memo 10 This document is a submission by the Mobile IP Working Group of the 11 Internet Engineering Task Force (IETF). Comments should be submitted 12 to the mobile-ip@SmallWorks.COM mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check 27 the "1id-abstracts.txt" listing contained in the Internet-Drafts 28 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 This document specifies a method by which an IP datagram may 35 be encapsulated (carried as payload) within an IP datagram. 36 Encapsulation is suggested as a means to alter the normal IP routing 37 for datagrams, by delivering them to an intermediate destination 38 that would otherwise not be selected by the (network part of the) IP 39 Destination Address field in the original IP header. Encapsulation 40 may serve a variety of purposes, such as delivery of a datagram to a 41 mobile node using Mobile IP. 43 1. Introduction 45 This document specifies a method by which an IP datagram may 46 be encapsulated (carried as payload) within an IP datagram. 47 Encapsulation is suggested as a means to alter the normal IP routing 48 for datagrams, by delivering them to an intermediate destination that 49 would otherwise not be selected based on the (network part of the) 50 IP Destination Address field in the original IP header. Once the 51 encapsulated datagram arrives at this intermediate destination node, 52 it is decapsulated, yielding the original IP datagram, which is then 53 delivered to the destination indicated by the original Destination 54 Address field. This use of encapsulation and decapsulation of a 55 datagram is frequently referred to as "tunneling" the datagram, and 56 the encapsulator and decapsulator are then considered to be the 57 "endpoints" of the tunnel. 59 In the most general tunneling case we have 61 source ---> encapsulator --------> decapsulator ---> destination 63 with the source, encapsulator, decapsulator, and destination being 64 separate nodes. The encapsulator node is considered the "entry 65 point" of the tunnel, and the decapsulator node is considered 66 the "exit point" of the tunnel. There in general may be multiple 67 source-destination pairs using the same tunnel between the 68 encapsulator and decapsulator. 70 2. Motivation 72 The Mobile IP working group has specified the use of encapsulation 73 as a way to deliver datagrams from a mobile node's "home network" to 74 an agent that can deliver datagrams locally by conventional means 75 to the mobile node at its current location away from home [8]. The 76 use of encapsulation may also be desirable whenever the source (or 77 an intermediate router) of an IP datagram must influence the route 78 by which a datagram is to be delivered to its ultimate destination. 79 Other possible applications of encapsulation include multicasting, 80 preferential billing, choice of routes with selected security 81 attributes, and general policy routing. 83 It is generally true that encapsulation and the IP loose source 84 routing option [10] can be used in similar ways to affect the routing 85 of a datagram, but there are several technical reasons to prefer 86 encapsulation: 88 - There are unsolved security problems associated with the use of 89 the IP source routing options. 91 - Current Internet routers exhibit performance problems when 92 forwarding datagrams that contain IP options, including the IP 93 source routing options. 95 - Many current Internet nodes process IP source routing options 96 incorrectly. 98 - Firewalls may exclude IP source-routed datagrams. 100 - Insertion of an IP source route option may complicate the 101 processing of authentication information by the source and/or 102 destination of a datagram, depending on how the authentication is 103 specified to be performed. 105 - It is considered impolite for intermediate routers to make 106 modifications to datagrams which they did not originate. 108 These technical advantages must be weighed against the disadvantages 109 posed by the use of encapsulation: 111 - Encapsulated datagrams typically are larger than source routed 112 datagrams. 114 - Encapsulation cannot be used unless it is known in advance that 115 the node at the tunnel exit point can decapsulate the datagram. 117 Since the majority of Internet nodes today do not perform well 118 when IP loose source route options are used, the second technical 119 disadvantage of encapsulation is not as serious as it might seem at 120 first. 122 3. IP in IP Encapsulation 124 To encapsulate an IP datagram using IP in IP encapsulation, an outer 125 IP header [10] is inserted before the datagram's existing IP header, 126 as follows: 128 +---------------------------+ 129 | | 130 | Outer IP Header | 131 | | 132 +---------------------------+ +---------------------------+ 133 | | | | 134 | IP Header | | IP Header | 135 | | | | 136 +---------------------------+ ====> +---------------------------+ 137 | | | | 138 | | | | 139 | IP Payload | | IP Payload | 140 | | | | 141 | | | | 142 +---------------------------+ +---------------------------+ 144 The outer IP header Source Address and Destination Address identify 145 the "endpoints" of the tunnel. The inner IP header Source Address 146 and Destination Addresses identify the original sender and recipient 147 of the datagram, respectively. The inner IP header is not changed 148 by the encapsulator, except to decrement the TTL as noted below, and 149 remains unchanged during its delivery to the tunnel exit point. No 150 change to IP options in the inner header occurs during delivery of 151 the encapsulated datagram through the tunnel. If need be, other 152 protocol headers such as the IP Authentication header [1] may be 153 inserted between the outer IP header and the inner IP header. Note 154 that the security options of the inner IP header MAY affect the 155 choice of security options for the encapsulating (outer) IP header. 157 3.1. IP Header Fields and Handling 159 The fields in the outer IP header are set by the encapsulator as 160 follows: 162 Version 164 4 166 IHL 168 The Internet Header Length (IHL) is the length of the outer IP 169 header measured in 32-bit words [10]. 171 TOS 173 The Type of Service (TOS) is copied from the inner IP header. 175 Total Length 177 The Total Length measures the length of the entire encapsulated 178 IP datagram, including the outer IP header, the inner IP 179 header, and its payload. 181 Identification, Flags, Fragment Offset 183 These three fields are set as specified in [10]. However, if 184 the "Don't Fragment" bit is set in the inner IP header, it MUST 185 be set in the outer IP header; if the "Don't Fragment" bit is 186 not set in the inner IP header, it MAY be set in the outer IP 187 header, as described in Section 5.1. 189 Time to Live 191 The Time To Live (TTL) field in the outer IP header is set to a 192 value appropriate for delivery of the encapsulated datagram to 193 the tunnel exit point. 195 Protocol 197 4 199 Header Checksum 201 The Internet Header checksum [10] of the outer IP header. 203 Source Address 205 The IP address of the encapsulator, that is, the tunnel entry 206 point. 208 Destination Address 210 The IP address of the decapsulator, that is, the tunnel exit 211 point. 213 Options 215 Any options present in the inner IP header are in general NOT 216 copied to the outer IP header. However, new options specific 217 to the tunnel path MAY be added. In particular, any supported 218 types of security options of the inner IP header MAY affect the 219 choice of security options for the outer header. It is not 220 expected that there be a one-to-one mapping of such options to 221 the options or security headers selected for the tunnel. 223 When encapsulating a datagram, the TTL in the inner IP header 224 is decremented by one if the tunneling is being done as part of 225 forwarding the datagram; otherwise, the inner header TTL is not 226 changed during encapsulation. If the resulting TTL in the inner IP 227 header is 0, the datagram is discarded and an ICMP Time Exceeded 228 message SHOULD be returned to the sender. An encapsulator MUST NOT 229 encapsulate a datagram with TTL = 0. 231 The TTL in the inner IP header is not changed when decapsulating. 232 If, after decapsulation, the inner datagram has TTL = 0, the 233 decapsulator MUST discard the datagram. If, after decapsulation, the 234 decapsulator forwards the datagram to one of its network interfaces, 235 it will decrement the TTL as a result of doing normal IP forwarding. 236 See also Section 4.4. 238 The encapsulator may use any existing IP mechanisms appropriate for 239 delivery of the encapsulated payload to the tunnel exit point. In 240 particular, use of IP options is allowed, and use of fragmentation 241 is allowed unless the "Don't Fragment" bit is set in the inner IP 242 header. This restriction on fragmentation is required so that nodes 243 employing Path MTU Discovery [7] can obtain the information they 244 seek. 246 3.2. Routing Failures 248 Routing loops within a tunnel are particularly dangerous when 249 they cause datagrams to arrive again at the encapsulator. Suppose 250 a datagram arrives at a router for forwarding, and the router 251 determines that the datagram has to be encapsulated before further 252 delivery. Then: 254 - If the IP Source Address of the datagram matches the router's own 255 IP address on any of its network interfaces, the router MUST NOT 256 tunnel the datagram; instead, the datagram SHOULD be discarded. 258 - If the IP Source Address of the datagram matches the IP address 259 of the tunnel destination (the tunnel exit point is typically 260 chosen by the router based on the Destination Address in the 261 datagram's IP header), the router MUST NOT tunnel the datagram; 262 instead, the datagram SHOULD be discarded. 264 See also Section 4.4. 266 4. ICMP Messages from within the Tunnel 268 After an encapsulated datagram has been sent, the encapsulator may 269 receive an ICMP [9] message from any intermediate router within the 270 tunnel other than the tunnel exit point. The action taken by the 271 encapsulator depends on the type of ICMP message received. When the 272 received message contains enough information, the encapsulator MAY 273 use the incoming message to create a similar ICMP message, to be sent 274 to the originator of the original unencapsulated IP datagram (the 275 original sender). This process will be referred to as "relaying" the 276 ICMP message from the tunnel. 278 ICMP messages indicating an error in processing a datagram include a 279 copy of (a portion of) the datagram causing the error. Relaying an 280 ICMP message requires that the encapsulator strip off the outer IP 281 header from this returned copy of the original datagram. For cases 282 in which the received ICMP message does not contain enough data to 283 relay the message, see Section 5. 285 4.1. Destination Unreachable (Type 3) 287 ICMP Destination Unreachable messages are handled by the encapsulator 288 depending upon their Code field. The model suggested here allows 289 the tunnel to "extend" a network to include non-local (e.g., mobile) 290 nodes. Thus, if the original destination in the unencapsulated 291 datagram is on the same network as the encapsulator, certain 292 Destination Unreachable Code values may be modified to conform to the 293 suggested model. 295 Network Unreachable (Code 0) 297 An ICMP Destination Unreachable message SHOULD be returned 298 to the original sender. If the original destination in 299 the unencapsulated datagram is on the same network as the 300 encapsulator, the newly generated Destination Unreachable 301 message sent by the encapsulator MAY have Code 1 (Host 302 Unreachable), since presumably the datagram arrived at the 303 correct network and the encapsulator is trying to create the 304 appearance that the original destination is local to that 305 network even if it is not. Otherwise, if the encapsulator 306 returns a Destination Unreachable message, the Code field MUST 307 be set to 0 (Network Unreachable). 309 Host Unreachable (Code 1) 311 The encapsulator SHOULD relay Host Unreachable messages to the 312 sender of the original unencapsulated datagram, if possible. 314 Protocol Unreachable (Code 2) 316 When the encapsulator receives an ICMP Protocol Unreachable 317 message, it SHOULD send a Destination Unreachable message with 318 Code 0 or 1 (see the discussion for Code 0) to the sender of 319 the original unencapsulated datagram. Since the original 320 sender did not use protocol 4 in sending the datagram, it would 321 be meaningless to return Code 2 to that sender. 323 Port Unreachable (Code 3) 325 This Code should never be received by the encapsulator, since 326 the outer IP header does not refer to any port number. It MUST 327 NOT be relayed to the sender of the original unencapsulated 328 datagram. 330 Datagram Too Big (Code 4) 332 The encapsulator MUST relay ICMP Datagram Too Big messages to 333 the sender of the original unencapsulated datagram. 335 Source Route Failed (Code 5) 337 This Code SHOULD be handled by the encapsulator itself. 338 It MUST NOT be relayed to the sender of the original 339 unencapsulated datagram. 341 4.2. Source Quench (Type 4) 343 The encapsulator SHOULD NOT relay ICMP Source Quench messages to the 344 sender of the original unencapsulated datagram, but instead SHOULD 345 activate whatever congestion control mechanisms it implements to help 346 alleviate the congestion detected within the tunnel. 348 4.3. Redirect (Type 5) 350 The encapsulator MAY handle the ICMP Redirect messages itself. 351 It MUST NOT not relay the Redirect to the sender of the original 352 unencapsulated datagram. 354 4.4. Time Exceeded (Type 11) 356 ICMP Time Exceeded messages report (presumed) routing loops 357 within the tunnel itself. Reception of Time Exceeded messages by 358 the encapsulator MUST be reported to the sender of the original 359 unencapsulated datagram as Host Unreachable (Type 3, Code 1). Host 360 Unreachable is preferable to Network Unreachable; since the datagram 361 was handled by the encapsulator, and the encapsulator is often 362 considered to be on the same network as the destination address in 363 the original unencapsulated datagram, then the datagram is considered 364 to have reached the correct network, but not the correct destination 365 node within that network. 367 4.5. Parameter Problem (Type 12) 369 If the Parameter Problem message points to a field copied from the 370 original unencapsulated datagram, the encapsulator MAY relay the 371 ICMP message to the sender of the original unencapsulated datagram; 372 otherwise, if the problem occurs with an IP option inserted by 373 the encapsulator, then the encapsulator MUST NOT relay the ICMP 374 message to the original sender. Note that an encapsulator following 375 prevalent current practice will never insert any IP options into the 376 encapsulated datagram, except possibly for security reasons. 378 4.6. Other ICMP Messages 380 Other ICMP messages are not related to the encapsulation operations 381 described within this protocol specification, and should be acted on 382 by the encapsulator as specified in [9]. 384 5. Tunnel Management 386 Unfortunately, ICMP only requires IP routers to return 8 octets 387 (64 bits) of the datagram beyond the IP header. This is not enough 388 to include a copy of the encapsulated (inner) IP header, so it is not 389 always possible for the encapsulator to relay the ICMP message from 390 the interior of a tunnel back to the original sender. 392 However, by carefully maintaining "soft state" about tunnels into 393 which it sends, the encapsulator can return accurate ICMP messages to 394 the original sender in most cases. The encapsulator SHOULD maintain 395 at least the following soft state information about each tunnel: 397 - MTU of the tunnel (Section 5.1) 398 - TTL (path length) of the tunnel 399 - Reachability of the end of the tunnel 401 The encapsulator uses the ICMP messages it receives from the interior 402 of a tunnel to update the soft state information for that tunnel. 403 ICMP errors that could be received from one of the routers along the 404 tunnel interior include: 406 - Datagram Too Big 407 - Time Exceeded 408 - Destination Unreachable 409 - Source Quench 411 When subsequent datagrams arrive that would transit the tunnel, 412 the encapsulator checks the soft state for the tunnel. If the 413 datagram would violate the state of the tunnel (for example, the TTL 414 of the new datagram is less than the tunnel "soft state" TTL) the 415 encapsulator sends an ICMP error message back to the sender of the 416 original datagram, but also encapsulates the datagram and forwards it 417 into the tunnel. 419 Using this technique, the ICMP error messages sent by the 420 encapsulator will not always match up one-to-one with errors 421 encountered within the tunnel, but they will accurately reflect the 422 state of the network. 424 Tunnel soft state was originally developed for the IP Address 425 Encapsulation (IPAE) specification [4]. 427 5.1. Tunnel MTU Discovery 429 When the Don't Fragment bit is set by the originator and copied into 430 the outer IP header, the proper MTU of the tunnel will be learned 431 from ICMP Datagram Too Big (Type 3, Code 4) messages reported to 432 the encapsulator. To support sending nodes which use Path MTU 433 Discovery, all encapsulator implementations MUST support Path MTU 434 Discovery [5, 7] soft state within their tunnels. In this particular 435 application, there are several advantages: 437 - As a benefit of Path MTU Discovery within the tunnel, any 438 fragmentation which occurs because of the size of the 439 encapsulation header is performed only once after encapsulation. 440 This prevents multiple fragmentation of a single datagram, which 441 improves processing efficiency of the decapsulator and the 442 routers within the tunnel. 444 - If the source of the unencapsulated datagram is doing Path MTU 445 Discovery, then it is desirable for the encapsulator to know 446 the MTU of the tunnel. Any ICMP Datagram Too Big messages from 447 within the tunnel are returned to the encapsulator, and as noted 448 in Section 5, it is not always possible for the encapsulator to 449 relay ICMP messages to the source of the original unencapsulated 450 datagram. By maintaining "soft state" about the MTU of the 451 tunnel, the encapsulator can return correct ICMP Datagram Too Big 452 messages to the original sender of the unencapsulated datagram to 453 support its own Path MTU Discovery. In this case, the MTU that 454 is conveyed to the original sender by the encapsulator SHOULD 455 be the MTU of the tunnel minus the size of the encapsulating 456 IP header. This will avoid fragmentation of the original IP 457 datagram by the encapsulator. 459 - If the source of the original unencapsulated datagram is 460 not doing Path MTU Discovery, it is still desirable for the 461 encapsulator to know the MTU of the tunnel. In particular, it is 462 much better to fragment the original datagram when encapsulating, 463 than to allow the encapsulated datagram to be fragmented. 464 Fragmenting the original datagram can be done by the encapsulator 465 without special buffer requirements and without the need to 466 keep reassembly state in the decapsulator. By contrast, if 467 the encapsulated datagram is fragmented, then the decapsulator 468 must reassemble the fragmented (encapsulated) datagram before 469 decapsulating it, requiring reassembly state and buffer space 470 within the decapsulator. 472 Thus, the encapsulator SHOULD normally do Path MTU Discovery, 473 requiring it to send all datagrams into the tunnel with the "Don't 474 Fragment" bit set in the outer IP header. However there are 475 problems with this approach. When the original sender sets the 476 "Don't Fragment" bit, the sender can react quickly to any returned 477 ICMP Datagram Too Big error message by retransmitting the original 478 datagram. On the other hand, suppose that the encapsulator receives 479 an ICMP Datagram Too Big message from within the tunnel. In that 480 case, if the original sender of the unencapsulated datagram had 481 not set the "Don't Fragment" bit, there is nothing sensible that 482 the encapsulator can do to let the original sender know of the 483 error. The encapsulator MAY keep a copy of the sent datagram 484 whenever it tries increasing the tunnel MTU, in order to allow it 485 to fragment and resend the datagram if it gets a Datagram Too Big 486 response. Alternatively the encapsulator MAY be configured for 487 certain types of datagrams not to set the "Don't Fragment" bit when 488 the original sender of the unencapsulated datagram has not set the 489 "Don't Fragment" bit. 491 5.2. Congestion 493 An encapsulator might receive indications of congestion from the 494 tunnel, for example, by receiving ICMP Source Quench messages from 495 nodes within the tunnel. In addition, certain link layers and 496 various protocols not related to the Internet suite of protocols 497 might provide such indications in the form of a Congestion 498 Experienced [6] flag. The encapsulator SHOULD reflect conditions of 499 congestion in its "soft state" for the tunnel, and when subsequently 500 forwarding datagrams into the tunnel, the encapsulator SHOULD use 501 appropriate means for controlling congestion [3]; However, the 502 encapsulator SHOULD NOT send ICMP Source Quench messages to the 503 original sender of the unencapsulated datagram. 505 6. Security Considerations 507 IP encapsulation potentially reduces the security of the Internet, 508 and care needs to be taken in the implementation and deployment of 509 IP encapsulation. For example, IP encapsulation makes it difficult 510 for border routers to filter datagrams based on header fields. In 511 particular, the original values of the Source Address, Destination 512 Address, and Protocol fields in the IP header, and the port numbers 513 used in any transport header within the datagram, are not located 514 in their normal positions within the datagram after encapsulation. 515 Since any IP datagram can be encapsulated and passed through a 516 tunnel, such filtering border routers need to carefully examine all 517 datagrams. 519 6.1. Router Considerations 521 Routers need to be aware of IP encapsulation protocols in order 522 to correctly filter incoming datagrams. It is desirable that 523 such filtering be integrated with IP authentication [1]. Where IP 524 authentication is used, encapsulated packets might be allowed to 525 enter an organization when the encapsulating (outer) packet or the 526 encapsulated (inner) packet is sent by an authenticated, trusted 527 source. Encapuslated packets containing no such authentication 528 represent a potentially large security risk. 530 IP datagrams which are encapsulated and encrypted [2] might also 531 pose a problem for filtering routers. In this case, the router can 532 filter the datagram only if it shares the security association used 533 for the encryption. To allow this sort of encryption in environments 534 in which all packets need to be filtered (or at least accounted for), 535 a mechanism must be in place for the receiving node to securely 536 communicate the security association to the border router. This 537 might, more rarely, also apply to the security association used for 538 outgoing datagrams. 540 6.2. Host Considerations 542 Host implementations that are capable of receiving encapsulated IP 543 datagrams SHOULD admit only those datagrams fitting into one or more 544 of the following categories: 546 - The protocol is harmless: source address-based authentication is 547 not needed. 549 - The encapsulating (outer) datagram comes from an authentically 550 identified, trusted source. The authenticity of the source could 551 be established by relying on physical security in addition to 552 border router configuration, but is more likely to come from use 553 of the IP Authentication header [1]. 555 - The encapuslated (inner) datagram includes an IP Authentication 556 header. 558 - The encapsulated (inner) datagram is addressed to a network 559 interface belonging to the decapsulator, or to a node with which 560 the decapsulator has entered into a special relationship for 561 delivering such encapsulated datagrams. 563 Some or all of this checking could be done in border routers rather 564 than the receiving node, but it is better if border router checks are 565 used as backup, rather than being the only check. 567 7. Acknowledgements 569 Parts of Sections 3 and 5 of this document were taken from portions 570 (authored by Bill Simpson) of earlier versions of the Mobile IP 571 Internet Draft [8]. The original text for section 6 (Security 572 Considerations) was contributed by Bob Smart. Good ideas have also 573 been included from RFC 1853 [11], also authored by Bill Simpson. 574 Thanks also to Anders Klemets for finding mistakes and suggesting 575 improvements to the draft. Finally, thanks to David Johnson for 576 going over the draft with a fine-toothed comb, finding mistakes, 577 improving consistency, and making many other improvements to the 578 draft. 580 References 582 [1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. 584 [2] R. Atkinson. IP Encapsulating Security Payload. RFC 1827, 585 August 1995. 587 [3] F. Baker, Editor. Requirements for IP Version 4 Routers. RFC 588 1812, June 1995. 590 [4] R. Gilligan, E. Nordmark, and B. Hinden. IPAE: The SIPP 591 Interoperability and Transition Mechanism. Internet Draft -- 592 work in progress, March 1994. 594 [5] S. Knowles. IESG Advice from Experience with Path MTU 595 Discovery. RFC 1435, March 1993. 597 [6] A. Mankin and K. Ramakrishnan. Gateway Congestion Control 598 Survey. RFC 1254, August 1991. 600 [7] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191, 601 November 1990. 603 [8] C. Perkins, Editor. IPv4 Mobility Support. 604 ietf-draft-mobileip-protocol-17.txt (work in progress), May 1996. 606 [9] J. B. Postel, Editor. Internet Control Message Protocol. RFC 607 792, September 1981. 609 [10] J. B. Postel, Editor. Internet Protocol. RFC 791, September 610 1981. 612 [11] W. Simpson. IP in IP Tunneling. RFC 1853, October 1995. 614 Author's Address 616 Questions about this memo can be directed to: 618 Charles Perkins 619 Room H3-D34 620 T. J. Watson Research Center 621 IBM Corporation 622 30 Saw Mill River Rd. 623 Hawthorne, NY 10532 625 Work: +1-914-784-7350 626 Fax: +1-914-784-6205 627 E-mail: perk@watson.ibm.com 629 The working group can be contacted via the current chair: 631 Jim Solomon 632 Motorola, Inc. 633 1301 E. Algonquin Rd. 634 Schaumburg, IL 60196 636 Work: +1-847-576-2753 637 E-mail: solomon@comm.mot.com