idnits 2.17.1 draft-ietf-mobileip-ip4inip4-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-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. ** 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 199: '...ular to the path MAY be added. In par...' RFC 2119 keyword, line 201: '... MAY affect the choice of secu...' RFC 2119 keyword, line 207: '...tunneled. An encapsulating agent MUST...' RFC 2119 keyword, line 211: '... MUST discard the datagram. If the ...' RFC 2119 keyword, line 226: '...its interfaces, an implementation MUST...' (13 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 (10 May 1996) is 10213 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') -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. '10') Summary: 13 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 10 May 1996 5 IP Encapsulation within IP 6 draft-ietf-mobileip-ip4inip4-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 22 months, and may be updated, replaced, or obsoleted by other documents 23 at any time. It is not appropriate to use Internet Drafts as 24 reference material, or to cite them other than as a ``working draft'' 25 or ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check 28 the ``1id-abstracts.txt'' listing contained in the internet-drafts 29 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 30 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 31 Rim). 33 Abstract 35 This document specifies a method by which an IP datagram may 36 be encapsulated (carried as payload) within an IP datagram. 37 Encapsulation is suggested as a means to alter the normal IP routing 38 for datagrams, by delivering them to an intermediate destination 39 which would not be otherwise selected by the (network part of the) 40 IP destination field. This may be done for any of a variety of 41 reasons, but is particular useful for adherence to the mobile-IP 42 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 alter the normal IP routing 49 for datagrams, by delivering them to an intermediate destination 50 which would not be otherwise selected based the (network part of the) 51 IP destination field. The process of encapsulation and decapsulation 52 a datagram is frequently referred to as "tunneling" the datagram, and 53 the encapsulator and decapsulator are then considered to be the the 54 "endpoints" of the tunnel. 56 In the most general encapsulation case we have 58 source ---> encapsulator --------> decapsulator ---> destination 60 with these being separate machines. There may in general be multiple 61 source-destination pairs using the same tunnel. 63 2. Motivation 65 The mobile-IP working group has specified the use of encapsulation 66 as a way to deliver datagrams from a mobile host's "home network" 67 to an agent which can deliver datagrams to the mobile host by 68 conventional means [7]. The use of encapsulation may also be 69 desirable whenever the source (or an intermediate router) of an 70 IP datagram must influence the route by which a datagram is to be 71 delivered to its ultimate destination. Other possible applications 72 include preferential billing, choice of routes with selected security 73 attributes, and general policy routing. 75 It is generally true that encapsulation and source routing techniques 76 can be used in similar ways to affect the routing of a datagram, but 77 there are several technical reasons to prefer encapsulation: 79 - There are unsolved security problems associated with the use of 80 source routing. 82 - Current internet routers exhibit performance problems when 83 forwarding datagrams which use the IP source routing option. 85 - Too many internet hosts process source routing options 86 incorrectly. 88 - Firewalls may exclude source-routed datagrams. 90 - Insertion of an IP source route option may complicate the 91 processing of authentication information by the source and/or 92 destination of a datagram, depending on how the authentication is 93 specified to be performed. 95 - It is considered impolite for intermediate routers to make 96 modifications to datagrams which they did not originate. 98 These technical advantages must be weighed against the disadvantages 99 posed by the use of encapsulation: 101 - Encapsulated datagrams typically are longer than source routed 102 datagrams. 104 - Encapsulation cannot be used unless it is known in advance that 105 the tunnel endpoint for the encapsulated datagram can decapsulate 106 the datagram. 108 Since the majority of internet hosts today do not perform well 109 when IP loose source route options are used, the second technical 110 disadvantage of encapsulation is not as serious as it might seem at 111 first. 113 3. IP in IP Encapsulation 115 An outer IP header is inserted before the datagram's IP header: 117 +---------------------------+ 118 | Outer IP Header | 119 +---------------------------+ +---------------------------+ 120 | IP Header | | IP Header | 121 +---------------------------+ ====> +---------------------------+ 122 | | | | 123 | IP Payload | | IP Payload | 124 | | | | 125 +---------------------------+ +---------------------------+ 127 The format of the IP header is described in RFC 791[9]. The outer 128 IP header source and destination addresses identify the "endpoints" 129 of the tunnel. The inner IP header source and destination addresses 130 identify the sender and recipient of the datagram. The inner IP 131 header is not changed by the node which encapsulates it, except 132 to decrement the TTL before delivery. The inner header remains 133 unchanged during its delivery to the tunnel endpoint. No change 134 to IP options in the inner header occurs during delivery of the 135 encapsulated datagram through the tunnel. If need be, other protocol 136 headers such as the IP Authentication header [1] may be inserted 137 between the outer IP header and the inner IP header (also see 138 section 6.3). 140 3.1. IP Header Fields and Handling 142 Version 144 4 146 IHL 148 The Internet Header Length measures the length (in bytes) of 149 the outer IP header exclusive of its payload, but including any 150 options which the encapsulating agent may insert. 152 TOS 154 The type of service is copied from the inner IP header. 156 Total Length 158 The length measures the length of the outer IP header along 159 with its payload, that is to say (typically) the inner IP 160 header and the original datagram. 162 Identification, Flags, Fragment Offset 164 These three fields are set in accordance with the procedures 165 specified in [9]. The "Don't Fragment" bit in the outer IP 166 header is copied from the corresponding flag in the inner IP 167 header. 169 Time to Live 171 The Time To Live (TTL) field in the outer IP header is set to a 172 value appropriate for delivery of the encapsulated datagram to 173 the tunnel endpoint. 175 Protocol 177 The protocol field in the outer IP header is set to protocol 178 number 4 for the encapsulation protocol. 180 Header Checksum 182 The Header Checksum is computed over the length (in bytes) of 183 the outer IP header exclusive of its payload, but including any 184 options which the encapsulating endpoint may insert. 186 Source Address 188 The IP address of the encapsulating agent, that is, the tunnel 189 starting point. 191 Destination Address 193 The IP address of the decapsulating agent, that is, the tunnel 194 completion point. 196 Options 198 not copied from the inner IP header. However, new options 199 particular to the path MAY be added. In particular, any 200 supported flavors of security options of the inner IP header 201 MAY affect the choice of security options for the tunnel. It 202 is not expected that there be a one-to-one mapping of such 203 options to the options or security headers selected for the 204 tunnel. 206 The inner TTL is decremented by one. If the resulting TTL is 207 0, the datagram is not tunneled. An encapsulating agent MUST 208 NOT encapsulate a datagram with TTL = 0 for delivery to a tunnel 209 endpoint. The TTL is not changed when decapsulating. If, after 210 decapsulation, the inner datagram has TTL zero, a tunnel endpoint 211 MUST discard the datagram. If the decapsulator forwards the datagram 212 to some network interface, it will decrement the TTL as a result of 213 doing normal IP forwarding. See also subsection 4.4. 215 The encapsulating agent is free to use any existing IP mechanisms 216 appropriate for delivery of the encapsulated payload to the tunnel 217 endpoint. In particular, this means that use of IP options and 218 fragmentation are allowed, unless the "Don't Fragment" bit is set in 219 the inner IP header. This is required so that hosts employing Path 220 MTU discovery [6] can obtain the information they seek. 222 3.2. Routing Failures 224 Routing loops within a tunnel are particularly dangerous when 225 they cause datagrams to arrive again at the encapsulator. If the 226 IP Source matches any of its interfaces, an implementation MUST 227 NOT further encapsulate. If the IP Source matches the tunnel 228 destination, an implementation SHOULD NOT further encapsulate. See 229 also subsection 4.4. 231 4. ICMP messages from within the tunnel 233 After an encapsulated datagram has been sent, the encapsulating 234 agent may receive an ICMP [8] message from any intermediate router 235 within the tunnel, except for the tunnel endpoint. The action taken 236 by the encapsulating agent depends on the type of ICMP message 237 received. When the received message contains enough information, the 238 encapsulating agent may use the incoming message to create a similar 239 ICMP message, to be sent to the originator of the inner IP datagram. 240 This process will be referred to as "relaying" the ICMP message to 241 the source of the original unencapsulated datagram. Relaying an ICMP 242 message requires that the encapsulator must strip off the outer IP 243 header which it receives from the sender of the ICMP message. For 244 cases where the received message does not contain enough data, see 245 section 5. 247 4.1. Destination Unreachable (Type 3) 249 Destination Unreachable messages are handled depending upon their 250 type. The model suggested here allows the tunnel to "extend" a 251 network to include non-local (e.g., mobile) hosts. Thus, if the 252 original destination in the unencapsulated datagram is on the same 253 network as the encapsulating agent, certain Destination Unreachable 254 codes may be modified to conform to the suggested model. 256 Network Unreachable (Code 0) 258 A Destination Unreachable message may be returned to 259 the original sender. If the original destination in 260 the unencapsulated datagram is on the same network as 261 the encapsulating agent, the newly generated Destination 262 Unreachable message sent by the encapsulating agent MAY have 263 code 1 (Host Unreachable), since presumably the datagram 264 arrived to the correct network and the encapsulating agent is 265 trying to create the appearance that the original destination 266 is local even if it's not. Otherwise, the encapsulating agent 267 must return a Destination Unreachable with code 0 message to 268 the original sender. 270 Host Unreachable (Code 1) 272 The encapsulating agent must relay Host Unreachable messages to 273 the source of the original unencapsulated datagram. 275 Protocol Unreachable (Code 2) 277 When the encapsulating agent receives a Protocol Unreachable 278 ICMP message, it should send a Destination Unreachable message 279 with code 0 or 1 (see the discussion for code 0) to the sender 280 of the original unencapsulated datagram. Since the original 281 sender might only rarely use protocol 4, it would be usually be 282 meaningless to return code 2 to that sender. 284 Port Unreachable (Code 3) 286 This code should never be received by the encapsulating 287 agent, since the outer IP header does not refer to any port 288 number. It must not be relayed to the source of the original 289 unencapsulated datagram. 291 Datagram Too Big (Code 4) 293 The encapsulating agent must relay Datagram Too Big messages to 294 the source of the original unencapsulated datagram. 296 Source Route Failed (Code 5) 298 This code should be treated by the encapsulating agent 299 itself. It must not be relayed to the source of the original 300 unencapsulated datagram. 302 4.2. Source Quench (Type 4) 304 The encapsulating agent SHOULD NOT relay Source Quench messages to 305 the source of the original unencapsulated datagram, but instead 306 activate whatever congestion control mechanisms it implements to 307 alleviate the congestion detected within the tunnel. 309 4.3. Redirect (Type 5) 311 The encapsulating agent may act on the Redirect message if it is 312 possible, but it should not relay the Redirect back to the source of 313 the datagram which was encapsulated. 315 4.4. Time Exceeded (Type 11) 317 ICMP Time Exceeded messages report routing loops within the tunnel 318 itself. Reception of Time Exceeded messages by the encapsulator MUST 319 be reported to the originator as Host Unreachable (Type 3 Code 1). 320 Host Unreachable is preferable to Network Unreachable; since the 321 datagram was handled by the encapsulator, and the encapsulator is 322 often considered to be on the same network as the destination address 323 in the original unencapsulated datagram, the datagram is considered 324 to have reached the correct network, but not the correct destination 325 host within that network. 327 4.5. Parameter Problem (Type 12) 329 If the parameter problem points to a field copied from the original 330 unencapsulated datagram, the encapsulating agent may relay the ICMP 331 message to the source; otherwise, if the problem occurs with an IP 332 option inserted by the encapsulating agent, then the encapsulating 333 agent must not relay the ICMP message to the source. Note that an 334 encapsulating agent following prevalent current practice will never 335 insert any IP options into the encapsulated datagram, except possibly 336 for security reasons. 338 4.6. Other messages 340 Other ICMP messages are not related to the encapsulation operations 341 described within this protocol specification, and should be acted on 342 as specified in [8]. 344 5. Tunnel Management 346 Unfortunately, ICMP only requires IP routers to return 8 bytes (64 347 bits) of the datagram beyond the IP header. This is not enough to 348 include the encapsulated header, so it is not always possible for the 349 home agent to immediately reflect the ICMP message from the interior 350 of a tunnel back to the originating host. 352 However, by carefully maintaining "soft state" about its tunnels, 353 the encapsulating router can return accurate ICMP messages in most 354 cases. The router SHOULD maintain at least the following soft state 355 information about each tunnel: 357 - MTU of the tunnel (subsection 5.1) 358 - TTL (path length) of the tunnel 359 - Reachability of the end of the tunnel 361 The router uses the ICMP messages it receives from the interior of a 362 tunnel to update the soft state information for that tunnel. ICMP 363 errors that could be received from one of the routers along the 364 tunnel interior include: 366 - Datagram Too Big 367 - Time Exceeded 368 - Destination Unreachable 369 - Source Quench 371 When subsequent datagrams arrive that would transit the tunnel, 372 the router checks the soft state for the tunnel. If the datagram 373 would violate the state of the tunnel (such as, the TTL is less than 374 the tunnel TTL) the router sends an ICMP error message back to the 375 source, but also forwards the datagram into the tunnel. 377 Using this technique, the ICMP error messages sent by encapsulating 378 routers will not always match up one-to-one with errors encountered 379 within the tunnel, but they will accurately reflect the state of the 380 network. 382 Tunnel soft state was originally developed for the IP address 383 encapsulation (IPAE) specification [4]. 385 5.1. Tunnel MTU Discovery 387 When the Don't Fragment bit is set by the originator and copied 388 into the outer IP header, the proper MTU of the tunnel will 389 be learned from ICMP (Type 3 Code 4) "Datagram Too Big" errors 390 reported to the encapsulator. To support originating hosts 391 which use this capability, all implementations MUST support Path 392 MTU Discovery [5, 6] within their tunnels. In this particular 393 application there are several advantages: 395 - As a benefit of Tunnel MTU Discovery, any fragmentation which 396 occurs because of the size of the encapsulation header is 397 performed only once after encapsulation. This prevents multiple 398 fragmentation of a single datagram, which improves processing 399 efficiency of the path routers and tunnel decapsulator. 401 - If the source of the unencapsulated datagram is doing MTU 402 discovery then it is desirable for the encapsulator to know the 403 MTU to the decapsulator. If it doesn't know the MTU then it 404 can transfer the DF bit to the outer datagram; however, if that 405 triggers ICMP Datagram Too Big from within the tunnel (and hence 406 returned to the encapsulator) the encapsulator cannot always 407 return a correct ICMP response to the source unless it has kept 408 state information about recently sent datagrams. If the tunnel 409 MTU is returned to the source by the encapsulator in a Datagram 410 Too Big message, the MTU that is conveyed SHOULD be the MTU of 411 the tunnel minus the size of the encapsulating IP header. This 412 will avoid fragmentation of the original IP datagram by the 413 encapsulator, something that is otherwise certain to occur. 415 - If the source is not doing MTU discovery it is still desirable 416 for the encapsulator to know the MTU to the decapsulator. In 417 particular it is much better to fragment the inner datagram than 418 to allow the outer datagram to be fragmented. Fragmenting the 419 inner datagram can be done without special buffer requirements 420 and without the need to keep state in the decapsulator. 421 By contrast if the outer datagram is fragmented then the 422 decapsulator needs to keep state and buffer space on behalf of 423 the destination. 425 The encapsulator SHOULD in normal circumstances do MTU discovery 426 and try to send datagrams with the DF bit set. However there are 427 problems with this approach. When the source sets the DF bit it can 428 react quickly to resend the information if it gets a ICMP Datagram 429 Too Big. When the encapsulator gets a ICMP Datagram Too Big, but the 430 source had not set the DF bit, then there is nothing sensible that 431 the encapsulator can do to let the source know. The encapsulator MAY 432 keep a copy of the sent datagram whenever it tries increasing the MTU 433 - this will allow it to resend the datagram fragmented if it gets a 434 datagram too big response. Alternatively the encapsulator MAY be 435 configured for certain classes of input to not set the DF bit when 436 the source has not set the DF bit. 438 5.2. Congestion 440 Tunnel soft state will collect indications of congestion, such as 441 an ICMP (Type 4) Source Quench or a Congestion Experienced flag in 442 datagrams from the decapsulator (tunnel peer). When forwarding 443 another datagram into the tunnel, it is appropriate to use approved 444 means for controlling congestion [3]; Source Quench messages SHOULD 445 NOT be sent to the originator. 447 6. Security Considerations 449 IP encapsulation potentially reduces the security of the Internet. 450 For this reason care needs to be taken in the implementation and 451 deployment. 453 Assume an organization has good physical control of a secure subset 454 of its network. Assume that the routers connecting that secure 455 network do not allow in datagrams with source addresses belonging to 456 interfaces on that secure network. In that situation it is possible 457 to safely deploy protocols within that network which depend on the 458 source address of datagrams for authentication purposes. 460 Networks with physical security can still be used to run protocols 461 which are convenient, but which have implementation or protocol bugs 462 which would make them dangerous to use if external sources have 463 access to the protocol. The external sources can be excluded using 464 router datagram filtering. 466 IP encapsulation protocols may allow datagrams to bypass the checks 467 in the border routers. There are two cases to consider: 469 - The case where the people controlling the border routers are 470 trying to protect inner machines from themselves. 472 - The case where the inner machine is looking after its own 473 defense. 475 An uncooperative inner machine cannot be protected by the border 476 router except by barring all packets to that machine. There is 477 nothing to stop encapsulated IP coming in to that inner machine in 478 otherwise harmless datagrams such as port 53 UDP datagrams (i.e., 479 apparently DNS datagrams). So there is a strong case for placing 480 the security controls at the host rather than the router. However, 481 in situations where the administrative control of the inner machine 482 is cooperative but lacks thoroughness or competence, security can be 483 enhanced by also putting protection in the border routers. 485 6.1. Router Considerations 487 Routers need to be aware of IP encapsulation protocols so they can 488 correctly filter incoming datagrams. 490 Beyond that it is desirable that filtering be integrated with IP 491 authentication [1]. In the case of IP encapsulation this can have 492 2 forms: Encapsulation might be allowed (in some cases) as long 493 as the encapsulating datagrams authentically come from an expected 494 encapsulator. Alternatively encapsulation might be allowed if the 495 encapsulated datagrams have authentication. 497 Data which is encapsulated and encrypted [2] may also pose a problem. 498 In this case the router can only filter the datagram if it knows 499 the security association. To allow this sort of encryption in 500 environments where all packets need to be filtered (or at least 501 accounted for) a mechanism must be in place for the receiving host 502 to securely communicate the association to the border router. This 503 might, more rarely, also apply to the association used for outgoing 504 datagrams. 506 6.2. Host Considerations 508 Receiving IP encapsulation software SHOULD classify incoming 509 datagrams and only allow datagrams fitting one of the following 510 categories: 512 - The protocol is harmless: source address based authentication is 513 not needed. 515 - The datagram can be trusted because of trust in the authentically 516 identified encapsulating host. That authentic identification 517 could come from physical security plus border router 518 configuration but is more likely to come from AH authentication. 520 - The inner datagram has AH authentication. 522 Some or all of this checking could be done in border routers rather 523 than the receiving host but it is better if border router checks are 524 used as backup rather than being the only check. 526 6.3. Using Security Options 528 The security options of the inner IP header MAY affect the choice of 529 security options for the encapsulating IP header. 531 7. Acknowledgements 533 Parts of sections 3 and 5 of this document were taken from sections 534 (authored by Bill Simpson) of earlier versions of the mobile-IP 535 Internet Draft [7]. Good ideas have also been included from RFC 536 1853 [10], also authored by Bill Simpson. "Security Considerations" 537 (section 6) was largely contributed by Bob Smart. Thanks also to 538 Anders Klemets for finding mistakes and suggesting many improvements 539 to the draft. 541 References 543 [1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. 545 [2] R. Atkinson. IP Encapsulating Security Payload. RFC 1827, 546 August 1995. 548 [3] F. Baker, Editor. Requirements for IP Version 4 Routers. RFC 549 1812, June 1995. 551 [4] R. Gilligan, E. Nordmark, and B. Hinden. IPAE: The SIPP 552 Interoperability and Transition Mechanism. Internet Draft -- 553 work in progress, March 1994. 555 [5] S. Knowles. IESG Advice from Experience with Path MTU 556 Discovery. RFC 1435, March 1993. 558 [6] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191, 559 November 1990. 561 [7] C. Perkins, Editor. ietf-draft-mobileip-protocol-16.txt - work 562 in progress. IPv4 Mobility Support, April 1996. 564 [8] J. B. Postel, Editor. Internet Control Message Protocol. RFC 565 792, September 1981. 567 [9] J. B. Postel, Editor. Internet Protocol. RFC 791, September 568 1981. 570 [10] W. Simpson. IP in IP Tunneling. RFC 1853, October 1995. 572 Author's Address 574 Questions about this memo can be directed to: 576 Charles Perkins 577 Room H3-D34 578 T. J. Watson Research Center 579 IBM Corporation 580 30 Saw Mill River Rd. 581 Hawthorne, NY 10532 583 Work: +1-914-784-7350 584 Fax: +1-914-784-6205 585 E-mail: perk@watson.ibm.com 587 The working group can be contacted via the current chairs: 589 Jim Solomon Tony Li 590 Motorola, Inc. cisco systems 591 1301 E. Algonquin Rd. 170 W. Tasman Dr. 592 Schaumburg, IL 60196 San Jose, CA 95134 594 Work: +1-847-576-2753 Work: +1-408-526-8186 595 E-mail: solomon@comm.mot.com E-mail: tli@cisco.com