idnits 2.17.1 draft-ietf-mobileip-spectun-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-25) 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 a Security Considerations section. ** 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 149: '...n the home agent SHOULD discard the da...' RFC 2119 keyword, line 179: '... address MAY be used....' 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-06 -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2002 (ref. '3') (Obsoleted by RFC 3220) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Charles Perkins 2 INTERNET DRAFT Sun Microsystems 3 20 November 1997 David B. Johnson 4 Carnegie Mellon University 6 Special Tunnels for Mobile IP 8 draft-ietf-mobileip-spectun-00.txt 10 Status of This Memo 12 This document is a submission by the Mobile IP Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to the mobile-ip@SmallWorks.COM mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as ``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 ftp.is.co.za (Africa), nic.nordu.net (North 31 Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 32 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 34 Abstract 36 This document defines actions taken by Mobile IP home agents and 37 foreign agents to try to avoid loss of datagrams sent to an incorrect 38 care-of address, even if a foreign agent has no binding for the 39 mobile node. 41 1. Introduction 43 The base Mobile IP protocol [3], allows any mobile node to move 44 about, changing its point of attachment to the Internet, while 45 continuing to be identified by its home IP address. An important 46 part of Mobile IP's operation is the maintenance of bindings (care-of 47 address information) associated with the mobile node by the home 48 agent. Route optimization [2] enables other IP nodes (correspondent 49 nodes) to maintain bindings. When bindings indicate care-of 50 addresses that are no longer valid, because of either transient or 51 longer term effects, a foreign agent at a care-of address can receive 52 packets tunneled to a mobile node that is no longer registered 53 with that foreign agent, and for which no additional forwarding 54 information is available. 56 In these circumstances, the base Mobile IP protocol indicates 57 that the tunneled datagrams should be dropped. However, dropping 58 such packets often necessitates retransmissions by higher level 59 protocols, and such retransmissions cause significant performance 60 degradation [1]. With care, it is possible to allow foreign agents 61 to return such decapsulated datagrams to the home agent in an attempt 62 to retry delivery to a more recent care-of address. The means for 63 doing so are specified in this document. 65 Suppose a foreign agent receives a tunneled datagram, but it doesn't 66 have a visitor list entry for the mobile node. Moreover, suppose 67 the foreign agent has no binding cache entry for the destination 68 mobile node. To attempt delivery of the datagram in this case, the 69 node must encapsulate the datagram as a special tunnel datagram (see 70 Section 3), destined to the mobile node. Using a special tunnel 71 allows the home agent to avoid a possible routing loop when a foreign 72 agent has forgotten that it is serving the mobile node, perhaps 73 because the foreign agent has crashed and lost its visitor list 74 state. The special tunnel allows the home agent to see the address 75 of the node that tunneled the datagram, and to avoid tunneling the 76 datagram back to the same node. 78 2. Terminology 80 This document uses the following terminology, in addition to that 81 used to describe the base Mobile IP protocol: 83 Binding cache 85 A cache of mobility bindings of mobile nodes, maintained by a 86 node for use in tunneling datagrams to those mobile nodes. 88 Registration Lifetime 90 The registration lifetime is the time duration for which a 91 binding is valid. The remaining registration lifetime means 92 the amount of time remaining for which a registration lifetime 93 is still valid, at some time after the registration was 94 approved by the home agent. 96 Remaining Registration Lifetime 98 The remaining registration lifetime is the amount of time 99 remaining for which a registration lifetime is still valid, 100 at some time after the registration was approved by the home 101 agent. 103 Special tunnel 105 A method of tunneling a datagram in which the outer destination 106 address when encapsulating the datagram is set equal to the 107 inner destination address (the original destination address of 108 the datagram). A special tunnel is used in Route Optimization 109 for returning a datagram, addressed to a mobile node, to the 110 mobile node's home agent without knowing the home agent's 111 address. 113 3. Using Special Tunnels 115 Whenever any node receives a tunneled datagram for which it has no 116 visitor list entry for the datagram's destination, the node is not 117 serving the mobile node as a foreign agent, and thus the care-of 118 address used by the tunnel originator is surely incorrect. Thus, 119 the tunneling node has an out-of-date binding cache entry for the 120 destination mobile node. If the node receiving the tunneled datagram 121 has a binding cache entry for the destination, it should re-tunnel 122 the datagram to the care-of address indicated in its binding cache 123 entry. 125 If a foreign agent receiving the tunneled datagram has no binding 126 cache entry for the destination, it cannot re-tunnel the node to its 127 destination. Instead, the foreign agent should forward the datagram 128 to the destination mobile node's home agent, using the special form 129 of tunneling, specified here, called a special tunnel. To tunnel the 130 datagram using a special tunnel, the tunneled datagram's destination 131 address is set equal to the destination address in the tunneled 132 datagram. Thus, both the inner and outer destination addresses 133 are set to the home address of the mobile node. The tunneled 134 datagram will be routed to the mobile node's home network, and then 135 intercepted by the mobile node's home agent in the same way as other 136 datagrams addressed to the mobile node. 138 3.1. Home Agent Handling of Special Tunnels 140 The home agent should then tunnel the datagram to the current care-of 141 address for the mobile node. However, the home agent may not tunnel 142 the datagram to the current care-of address if the special tunnel 143 of the datagram originated at that care-of address, as indicated 144 by the outer source address of the special tunnel. The use of the 145 special tunnel format allows the home agent to identify the node 146 that tunneled the datagram to it (as well as the original sender of 147 the datagram). If the home agent believes that the current care-of 148 address for the mobile node is the same as the source of the special 149 tunnel, then the home agent SHOULD discard the datagram. When that 150 happens, the foreign agent serving the mobile node appears to have 151 lost its entry for the mobile node in its visitor list. For example, 152 the foreign agent may have crashed and rebooted. 154 Otherwise, after tunneling the datagram to the current care-of 155 address for the mobile node, the home agent should notify the source 156 of the special tunnel of the mobile node's current binding, by 157 sending it a Binding Update message. The home agent should also send 158 a Binding Update message [2] to the sender of the original datagram 159 (the inner source address of the tunneled datagram), if it shares a 160 mobility security association with this node. 162 3.2. Foreign Agents and Special Tunnels 164 When a foreign agent is the endpoint of a tunneled datagram, it 165 examines its visitor list for an entry for the destination mobile 166 node, as in the base Mobile IP protocol. If no visitor list entry 167 is found, the foreign agent examines its binding cache for a cache 168 entry for the destination mobile node. If one is found, the foreign 169 agent re-tunnels the new care-of address indicated in the binding 170 cache entry. In this case, the foreign agent also may infer that the 171 sender of the datagram has an out-of-date binding cache entry for 172 this mobile node, since it otherwise would have tunneled the datagram 173 directly to the correct new care-of address itself. The foreign 174 agent should then send a Binding Warning message to the mobile node's 175 home agent. The foreign agent probably learned the address of the 176 home agent in the Registration Reply message for the mobile node, or 177 a later Binding Update message from which the binding cache entry 178 was created. If the home agent is not known, the mobile node's home 179 address MAY be used. 181 If a foreign agent receives a tunneled datagram for a mobile node 182 for which it has no visitor list entry or binding cache entry, the 183 foreign agent should forward the datagram to the mobile node's 184 home agent by sending it as a special tunnel. The home agent will 185 intercept the special tunnel datagram addressed to the mobile node 186 in the same way as any datagram for the mobile node while it is away 187 from home. 189 References 191 [1] Ramon Caceres and Liviu Iftode. Improving the Performance of 192 Reliable Transport Protocols in Mobile Computing Environments. 193 IEEE Journal on Selected Areas in Communications, 13(5):850--857, 194 June 1995. 196 [2] Charles E. Perkins and David B. Johnson. Route Optimization in 197 Mobile-IP. draft-ietf-mobileip-optim-06.txt, July 1997. (work 198 in progress). 200 [3] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 201 1996. 203 Chairs' Addresses 205 The working group can be contacted via the current chairs: 207 Jim Solomon Erik Nordmark 208 Motorola, Inc. Sun Microsystems, Inc. 209 1301 E. Algonquin Road 901 San Antonio Road 210 Schaumburg, IL 60196 Palo Alto, California 94303 211 USA USA 213 Phone: +1-847-576-2753 Phone: +1 650 786-5166 214 Fax: Fax: +1 650 786-5896 215 E-mail: solomon@comm.mot.com E-mail: nordmark@sun.com 217 Authors' Addresses 219 Questions about this document can also be directed to the authors: 221 Charles E. Perkins David B. Johnson 222 Technology Development Group Computer Science Department 223 Mail Stop MPK15-214 224 Room 2682 225 Sun Microsystems, Inc. Carnegie Mellon University 226 901 San Antonio Road 5000 Forbes Avenue 227 Palo Alto, California 94303 Pittsburgh, PA 15213-3891 228 USA USA 229 Phone: +1-650-786-6464 Phone: +1-412-268-7399 230 Fax: +1-650-786-6445 Fax: +1-412-268-5576 231 E-mail: charles.perkins@Sun.COM E-mail: dbj@cs.cmu.edu