idnits 2.17.1 draft-ietf-mobileip-minenc-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-03-28) 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 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 87: '...al encapsulation MUST NOT be used when...' 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 10163 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' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- No information found for draft-ietf-ip4inip4 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 7 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 Minimal Encapsulation within IP 6 draft-ietf-mobileip-minenc-02.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 be 35 encapsulated (carried as payload) within an IP datagram, with less 36 overhead than "conventional" IP encapsulation that adds a second IP 37 header to each encapsulated datagram. Encapsulation is suggested as 38 a means to alter the normal IP routing for datagrams, by delivering 39 them to an intermediate destination that would otherwise not be 40 selected by the (network part of the) IP Destination Address field 41 in the original IP header. Encapsulation may be serve a variety 42 of purposes, such as delivery of a datagram to a mobile node using 43 Mobile IP. 45 1. Introduction 47 This document specifies a method by which an IP datagram may be 48 encapsulated (carried as payload) within an IP datagram, with 49 less overhead than "conventional" IP encapsulation [4] that adds a 50 second IP header to each encapsulated datagram. Encapsulation is 51 suggested as a means to alter the normal IP routing for datagrams, by 52 delivering them to an intermediate destination that would otherwise 53 not be selected by the (network part of the) IP Destination Address 54 field in the original IP header. The process of encapsulation and 55 decapsulation of a datagram is frequently referred to as "tunneling" 56 the datagram, and the encapsulator and decapsulator are then 57 considered to be the the "endpoints" of the tunnel; the encapsulator 58 node is refered to as the "entry point" of the tunnel, and the 59 decapsulator node is refered to as the "exit point" of the tunnel. 61 2. Motivation 63 The Mobile IP working group has specified the use of encapsulation 64 as a way to deliver packets from a mobile node's "home network" to 65 an agent that can deliver datagrams locally by conventional means 66 to the mobile node at its current location away from home [5]. The 67 use of encapsulation may also be indicated whenever the source (or 68 an intermediate router) of an IP datagram must influence the route 69 by which a datagram is to be delivered to its ultimate destination. 70 Other possible applications of encapsulation include multicasting, 71 preferential billing, choice of routes with selected security 72 attributes, and general policy routing. 74 See [4] for a discussion concerning the advantages of encapsulation 75 versus use of the IP loose source routing option. Using IP headers 76 to encapsulate IP datagrams requires the unnecessary duplication of 77 several fields within the inner IP header; it is possible to save 78 some additional space by specifying a new encapsulation mechanism 79 that eliminates the duplication. The scheme outlined here comes from 80 the Mobile IP Working Group (in earlier Internet Drafts), and is 81 similar to that which had been defined in [2]. 83 3. Minimal Encapsulation 85 A minimal forwarding header is defined for datagrams which are not 86 fragmented prior to encapsulation. Use of this encapsulating method 87 is optional. Minimal encapsulation MUST NOT be used when an original 88 datagram is already fragmented, since there is no room in the minimal 89 forwarding header to store fragmentation information. 91 To encapsulate an IP datagram using minimal encapsulation, the 92 minimal forwarding header is inserted into the datagram, as follows: 94 +---------------------------+ +---------------------------+ 95 | | | | 96 | IP Header | | Modified IP Header | 97 | | | | 98 +---------------------------+ ====> +---------------------------+ 99 | | | Minimal Forwarding Header | 100 | | +---------------------------+ 101 | IP Payload | | | 102 | | | | 103 | | | IP Payload | 104 +---------------------------+ | | 105 | | 106 +---------------------------+ 108 The IP header of the original datagram is modified, and the minimal 109 forwarding header is inserted into the datagram after the IP header, 110 followed by the unmodified IP payload of the original datagram (e.g., 111 transport header and transport data). No additional IP header is 112 added to the datagram. 114 In encapsulating the datagram, the original IP header [6] is modified 115 as follows: 117 - The Protocol field in the IP header is replaced by protocol 118 number 55 for the minimal encapsulation protocol. 120 - The Destination Address field in the IP header is replaced by the 121 IP address of the exit point of the tunnel. 123 - If the encapsulator is not the original source of the datagram, 124 the Source Address field in the IP header is replaced by the IP 125 address of the encapsulator. 127 - The Total Length field in the IP header is incremented by the 128 size of the minimal forwarding header added to the datagram. 129 This incremental size is either 12 or 8 octets, depending on 130 whether or not the Original Source Address Present (S) bit is set 131 in the forwarding header. 133 - The Header Checksum field in the IP header is recomputed [6] or 134 updated to account for the changes in the IP header described 135 here for encapsulation. 137 The format of the minimal forwarding header is as follows: 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Protocol |S| reserved | Header Checksum | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Original Destination Address | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 : (if present) Original Source Address : 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Protocol 151 Copied from the Protocol field in the original IP header. 153 Original Source Address Present (S) 155 0 The Original Source Address field is not present. The 156 length of the minimal tunneling header in this case is 157 8 octets. 159 1 The Original Source Address field is present. The 160 length of the minimal tunneling header in this case is 161 12 octets. 163 reserved 165 Sent as zero; ignored on reception. 167 Header Checksum 169 The 16-bit one's complement of the one's complement sum of all 170 16-bit words in the minimal forwarding header. For purposes of 171 computing the checksum, the value of the checksum field is 0. 172 The IP header and IP payload (after the minimal forwarding 173 header) are not included in this checksum computation. 175 Original Destination Address 177 Copied from the Destination Address field in the original IP 178 header. 180 Original Source Address 182 Copied from the Source Address field in the original IP header. 183 This field is present only if the Original Source Address 184 Present (S) bit is set. 186 When decapsulating a datagram, the fields in the minimal forwarding 187 header are restored to the IP header, and the forwarding header is 188 removed from the datagram. In addition, the Total Length field in 189 the IP header is decremented by the size of the minimal forwarding 190 header removed from the datagram, and the Header Checksum field in 191 the IP header is recomputed [6] or updated to account for the changes 192 to the IP header described here for decapsulation. 194 The encapsulator may use existing IP mechanisms appropriate for 195 delivery of the encapsulated payload to the tunnel exit point. In 196 particular, use of IP options are allowed, and use of fragmentation 197 is allowed unless the "Don't Fragment" bit is set in the IP header. 198 This restriction on fragmentation is required so that nodes employing 199 Path MTU Discovery [3] can obtain the information they seek. 201 4. Routing Failures 203 The use of any encapsulation method for routing purposes brings 204 with it increased susceptibility to routing loops. To cut down the 205 danger, a router should follow the same procedures outlined in [4]. 207 5. ICMP Messages from within the Tunnel 209 ICMP messages are to be handled as specified in [4], including the 210 maintenance of tunnel "soft state". 212 6. Security Considerations 214 Security considerations are not addressed in this document, but are 215 generally similar to those outlined in [4]. 217 7. Acknowledgements 219 The original text for much of Section 3 was taken from the Mobile IP 220 draft [1]. Thanks to David Johnson for improving consistency and 221 making many other improvements to the draft. 223 References 225 [1] IPv4 Mobility Support. ietf-draft-mobileip-protocol-10.txt -- 226 outdated draft, May 1995. 228 [2] David B. Johnson. Scalable and Robust Internetwork Routing 229 for Mobile Hosts. In Proceedings of the 14th International 230 Conference on Distributed Computing Systems, pages 2--11, June 231 1994. 233 [3] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191, November 234 1990. 236 [4] Charles Perkins. IP Encapsulation within IP. 237 draft-ietf-ip4inip4-01.txt (work in progress), May 1996. 239 [5] C. Perkins, Editor. IPv4 Mobility Support. 240 ietf-draft-mobileip-protocol-17.txt (work in progress), May 1996. 242 [6] J. B. Postel, Editor. Internet Protocol. RFC 791, September 243 1981. 245 Author's Address 247 Questions about this memo can be directed to: 249 Charles Perkins 250 Room H3-D34 251 T. J. Watson Research Center 252 IBM Corporation 253 30 Saw Mill River Rd. 254 Hawthorne, NY 10532 256 Work: +1-914-784-7350 257 Fax: +1-914-784-6205 258 E-mail: perk@watson.ibm.com 260 The working group can be contacted via the current chair: 262 Jim Solomon 263 Motorola, Inc. 264 1301 E. Algonquin Rd. 265 Schaumburg, IL 60196 267 Work: +1-847-576-2753 268 E-mail: solomon@comm.mot.com