idnits 2.17.1 draft-ietf-mobileip-ip4inip4-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (05 July 1995) is 10523 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Perkins 3 INTERNET DRAFT IBM 4 05 July 1995 6 IP Encapsulation within IP 7 draft-ietf-mobileip-ip4inip4-00.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 mobile-ip@tadpole.com mailing list. 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 not appropriate to use Internet Drafts as 25 reference material, or to cite them other than as a ``working draft'' 26 or ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check 29 the ``1id-abstracts.txt'' listing contained in the internet-drafts 30 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 31 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 32 Rim). 34 Abstract 36 This document specifies a method by which an IP datagram may 37 be encapsulated (carried as payload) within an IP datagram. 38 Encapsulation is suggested as a means to effect "re-addressing" 39 datagrams (i.e, delivering them to an intermediate destination other 40 than that specified in the IP destination field) for any of a variety 41 of reasons, but particularly those useful for adherence to the 42 mobile-IP specification. 44 1. Introduction 46 This document specifies a method by which an IP datagram may 47 be encapsulated (carried as payload) within an IP datagram. 48 Encapsulation is suggested as a means to effect "re-addressing" 49 datagrams -- that is, delivering them to an intermediate destination 50 other than that specified in the IP destination field. The process 51 of encapsulation and decapsulation a datagram is frequently referred 52 to as "tunneling" the datagram, and the encapsulator and decapsulator 53 are then considered to be the the "endpoints" of the tunnel. 55 2. Motivation 57 The mobile-IP working group has specified the use of encapsulation as 58 a way to deliver packets from a mobile host's "home network" to an 59 agent which can deliver packets to the mobile host by conventional 60 means [1]. The use of encapsulation may also be desirable whenever 61 the source (or an intermediate router) of an IP datagram must 62 influence the route by which a datagram is to be delivered to 63 its ultimate destination. Other possible applications include 64 preferential billing, choice of routes with selected security 65 attributes, and general policy routing. 67 It is generally true that encapsulation and source routing techniques 68 can both be used to re-address datagrams whenever that is necessary, 69 but there are several technical reasons to prefer encapsulation: 71 - There are unsolved security problems associated with the use of 72 source routing. 74 - Current internet routers exhibit performance problems when 75 forwarding packets which use the IP source routing option. 77 - Too many internet hosts process source routing options 78 incorrectly. 80 - Firewalls may exclude source-routed packets. 82 - Insertion of an IP source route option may complicate the 83 processing of authentication information by the source and/or 84 destination of a datagram, depending on how the authentication is 85 specified to be performed. 87 - It is considered impolite for intermediate routers to make 88 modifications to the packets which they did not originate. 90 These technical advantages must be weighed against the disadvantages 91 posed by the use of encapsulation: 93 - Encapsulated packets typically are longer than source routed 94 packets. 96 - Encapsulation cannot be used unless it is known in advance that 97 the tunnel endpoint for the encapsulated datagram can decapsulate 98 the packet. 100 Since the majority of internet hosts today do not perform well 101 when IP loose source route options are used, the second technical 102 disadvantage of encapsulation is not as serious as it might seem at 103 first. 105 3. IP in IP Encapsulation 107 An outer IP header is inserted before the datagram's IP header: 109 +---------------------------+ 110 | Outer IP Header | 111 +---------------------------+ +---------------------------+ 112 | IP Header | | IP Header | 113 +---------------------------+ ====> +---------------------------+ 114 | | | | 115 | IP Payload | | IP Payload | 116 | | | | 117 +---------------------------+ +---------------------------+ 119 The format of the IP header is described in RFC 791[4]. The outer 120 IP header source and destination addresses identify the "endpoints" 121 of the tunnel. The inner IP header source and destination addresses 122 identify the sender and recipient of the datagram. The inner IP 123 header is not changed by the node which encapsulates it inside the 124 outer IP header, and the inner header remains unchanged during its 125 delivery to the tunnel endpoint. No change to IP options in the 126 inner header occurs during delivery of the encapsulated packet 127 through the tunnel. 129 Version 131 4 133 IHL 135 The Internet Header Length measures the length (in bytes) of 136 the outer IP header exclusive of its payload, but including any 137 options which the encapsulating agent may insert. 139 TOS 141 The type of service is copied from the inner IP header. 143 Total Length 145 The length measures the length of the outer IP header along 146 with its payload, that is to say the inner IP header and the 147 original datagram. 149 Identification 151 Flags 153 Fragment Offset 155 These three fields are set in accordance with the procedures 156 specified in [4]. The "Don't Fragment" bit in the outer IP 157 header is copied from the corresponding flag in the inner IP 158 header. 160 Time to Live 162 The Time To Live (TTL) field in the outer IP header is set to 163 be the same as the original datagram. 165 Protocol 167 The protocol field in the outer IP header is set to protocol 168 number 4 for the encapsulation protocol. 170 Header Checksum 172 The Header Checksum is computed over the length (in bytes) of 173 the outer IP header exclusive of its payload, but including any 174 options which the encapsulating endpoint may insert. 176 Source Address 178 The IP address of the encapsulating agent, that is, the tunnel 179 starting point. 181 Destination Address 183 The IP address of the decapsulating agent, that is, the tunnel 184 completion point. 186 When decapsulating, the outer TTL minus one is inserted into the 187 inner IP TTL. Thus, hops are counted, but the actual routers interior 188 to the tunnel are not identified. This provides loop protection. 190 The encapsulating agent is free to use any existing IP mechanisms 191 appropriate for delivery of the encapsulated payload to the tunnel 192 endpoint. In particular, this means that use of IP options and 193 fragmentation are allowed, unless the "Don't Fragment" bit is set in 194 the inner IP header. This is required so that hosts employing Path 195 MTU discovery [2] can obtain the information they seek. 197 4. ICMP messages from within the tunnel 199 After an encapsulated datagram has been sent, the encapsulating 200 agent may receive an ICMP message from any intermediate router 201 within the tunnel, except for the tunnel endpoint. The action taken 202 by the encapsulating agent depends on the type of ICMP message 203 received. In many cases, the encapsulating agent will use the 204 incoming message to create a similar ICMP message, which then is 205 sent to the originator of the inner IP datagram. This process will 206 be referred to as "relaying" the ICMP message to the source of the 207 original uncapsulated datagram. 209 4.1. Destination Unreachable 211 Destination Unreachable messages are handled depending upon their 212 type. The model suggested here allows the tunnel to "extend" a 213 network to include non-local (e.g, mobile) hosts. Thus, if the 214 original destination in the unencapsulated datagram is on the same 215 network as the encapsulating agent, certain Destination Unreachable 216 codes may be modified to conform to the suggested model. 218 Code 0 220 A Destination Unreachable message may be returned to 221 the original sender. If the original destination in 222 the unencapsulated datagram is on the same network as 223 the encapsulating agent, the newly generated Destination 224 Unreachable message sent by the encapsulating agent can have 225 type 1, since presumably the packet arrived to the correct 226 network and the encapsulating agent is trying to create the 227 appearance that the original destination is local even if 228 it's not. Otherwise, the encapsulating agent must return a 229 Destination Unreachable with code 0 message to the original 230 sender. 232 Code 1 234 The encapsulating agent must relay Destination Unreachable 235 messages of code 1 (host unreachable) to the source of the 236 original unencapsulated datagram. 238 Code 2 240 When the encapsulating agent receives a Destination Unreachable 241 ICMP message with code 2 (protocol unreachable) it should 242 send a Destination Unreachable message with code 0 or 1 (see 243 the discussion for code 0) to the sender of the original 244 unencapsulated datagram. Since the original sender did not 245 necessarily use protocol 4, it would be meaningless to return 246 code 2 to that sender. 248 Code 3 250 This code (port unreachable) should never be received by the 251 encapsulating agent, since the outer IP header does not refer 252 to any port number. It must not be relayed to the source of 253 the original unencapsulated datagram. 255 Code 4 257 The encapsulating agent must relay Destination Unreachable 258 messages of code 4 (fragmentation needed and DF set) to the 259 source of the original unencapsulated datagram. 261 Code 5 263 This code (source route failed) should be treated by the 264 encapsulating agent itself. It must not be relayed to the 265 source of the original unencapsulated datagram. 267 4.2. Time Exceeded 269 The encapsulating agent may relay Time Exceeded messages to the 270 source of the original unencapsulated datagram. 272 4.3. Parameter Problem 274 If the parameter problem points to a field copied from the original 275 unencapsulated datagram, the encapsulating agent may relay the ICMP 276 message to the source; otherwise, if the problem occurs with an IP 277 option inserted by the encapsulating agent, then the encapsulating 278 agent must not relay the ICMP message to the source. Note that an 279 encapsulating agent following prevalent current practice will never 280 insert any IP options into the encapsulated datagram. 282 4.4. Redirect 284 The encapsulating agent may act on the Redirect message if it is 285 possible, but it should not relay the Redirect back to the source 286 of the datagram which was encapsulated. Acting upon the Redirect 287 message would require that the encapsulating agent maintain storage 288 for encapsulated packets, and this may be an unpopular design choice 289 for many purposes. 291 4.5. Source Quench 293 The encapsulating agent may relay Source Quench messages to the 294 source of the original unencapsulated datagram. 296 4.6. Other messages 298 Other ICMP messages are not related to the encapsulation operations 299 described within this protocol specification, and should be acted on 300 as specified in [3]. 302 5. Security Considerations 304 Security considerations are not addressed in this document. 306 6. Acknowledgements 308 The text for parts of section 3 was taken from the mobile-IP 309 draft([1]). 311 References 313 [1] IETF Mobile-IP Working Group. IPv4 Mobility Support. 314 ietf-draft-mobileip-protocol-10.txt -- work in progress, May 315 1995. 317 [2] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191, November 318 1990. 320 [3] J. Postel. Internet Control Message Protocol. RFC 792, 321 September 1981. 323 [4] J. Postel. Internet Protocol. RFC 791, September 1981. 325 Author's Address 327 Questions about this memo can also be directed to: 329 Charles Perkins 330 Room J1-A25 331 T. J. Watson Research Center 332 IBM Corporation 333 30 Saw Mill River Rd. 334 Hawthorne, NY 10532 336 Work: +1-914-784-7350 337 Fax: +1-914-784-7007 338 E-mail: perk@watson.ibm.com 340 The working group can be contacted via the current chairs: 342 Jim Solomon Tony Li 343 Motorola, Inc. cisco systems 344 1301 E. Algonquin Rd. 170 W. Tasman Dr. 345 Schaumburg, IL 60196 San Jose, CA 95134 347 Work: +1-708-576-2753 Work: +1-408-526-8186 348 E-mail: solomon@comm.mot.com E-mail: tli@cisco.com