From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2005.txt | 283 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 283 insertions(+) create mode 100644 doc/rfc/rfc2005.txt (limited to 'doc/rfc/rfc2005.txt') diff --git a/doc/rfc/rfc2005.txt b/doc/rfc/rfc2005.txt new file mode 100644 index 0000000..121db85 --- /dev/null +++ b/doc/rfc/rfc2005.txt @@ -0,0 +1,283 @@ + + + + + + +Network Working Group J. Solomon +Request for Comments: 2005 Motorola +Category: Standards Track October 1996 + + + Applicability Statement for IP Mobility Support + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + As required by [RFC 1264], this report discusses the applicability of + Mobile IP to provide host mobility in the Internet. In particular, + this document describes the key features of Mobile IP and shows how + the requirements for advancement to Proposed Standard RFC have been + satisfied. + +1. Protocol Overview + + Mobile IP provides an efficient, scalable mechanism for node mobility + within the Internet. Using Mobile IP, nodes may change their point- + of-attachment to the Internet without changing their IP address. + This allows them to maintain transport and higher-layer connections + while moving. Node mobility is realized without the need to + propagate host-specific routes throughout the Internet routing + fabric. The protocol is documented in [MIP-PROTO]. + + In brief, Mobile IP routing works as follows. Packets destined to a + mobile node are routed first to its home network -- a network + identified by the network prefix of the mobile node's (permanent) + home address. At the home network, the mobile node's home agent + intercepts such packets and tunnels them to the mobile node's most + recently reported care-of address. At the endpoint of the tunnel, + the inner packets are decapsulated and delivered to the mobile node. + In the reverse direction, packets sourced by mobile nodes are routed + to their destination using standard IP routing mechanisms. + + Thus, Mobile IP relies on protocol tunneling to deliver packets to + mobile nodes that are away from their home network. The mobile + node's home address is hidden from routers along the path from the + home agent to the mobile node due to the presence of the tunnel. The + encapsulating packet is destined to the mobile node's care-of address + + + +Solomon Standards Track [Page 1] + +RFC 2005 Mobile IP Applicability Statement October 1996 + + + -- a topologically significant address -- to which standard IP + routing mechanisms can deliver packets. + + The Mobile IP protocol defines the following: + + - an authenticated registration procedure by which a mobile node + informs its home agent(s) of its care-of address(es); + + - an extension to ICMP Router Discovery [RFC1256] which allows mobile + nodes to discover prospective home agents and foreign agents; and + + - the rules for routing packets to and from mobile nodes, including + the specification of one mandatory tunneling mechanism ([MIP-IPinIP]) + and several optional tunneling mechanisms ([MIP-MINENC] and + [RFC1701]). + +2. Applicability + + Mobile IP is intended to solve node mobility across changes in IP + subnet. It is just as suitable for mobility across homogeneous media + as it is for mobility across heterogeneous media. That is, Mobile IP + facilitates node movement from one Ethernet segment to another as + well as it accommodates node movement from an Ethernet segment to a + wireless LAN. + + One can think of Mobile IP as solving the "macro" mobility management + problem. It is less well suited for more "micro" mobility management + applications -- for example, handoff amongst wireless transceivers, + each of which covers only a very small geographic area. In this + later situation, link-layer mechanisms for link maintenance (i.e. + link-layer handoff) might offer faster convergence and less overhead + than Mobile IP. + + Mobile IP scales to handle a large number of mobile nodes in the + Internet. Without route optimization as described in [MIP-OPTIM], + however, the home agent is a potential load point when serving many + mobile nodes. When home agents become overburdened, additional home + agents can be added -- and even dynamically discovered by mobile + nodes -- using mechanisms defined in the Mobile IP documents. + + Finally, it is noted that mobile nodes are assigned (home) IP + addresses largely the same way in which stationary hosts are assigned + long-term IP addresses; namely, by the authority who owns them. + Properly applied, Mobile IP allows mobile nodes to communicate using + only their home address regardless of their current location. Mobile + IP, therefore, makes no attempt to solve the problems related to + local or global, IP address, renumbering. + + + + +Solomon Standards Track [Page 2] + +RFC 2005 Mobile IP Applicability Statement October 1996 + + +3. Security + + Mobile IP mandates the use of cryptographically strong authentication + for all registration messages exchanged between a mobile node and its + home agent. Optionally, strong authentication can be used between + foreign agents and mobile nodes or home agents. Replay protection is + realized via one of two possible mechanisms -- timestamps or nonces. + + Due to the unavailability of an Internet key management protocol, + agent discovery messages are not required to be authenticated. + + All Mobile IP implementations are required to support, at a minimum, + keyed MD5 authentication with manual key distribution. Other + authentication and key distribution algorithms may be supported. + + Mobile IP defines security mechanisms only for the registration + protocol. Implementations requiring privacy and/or authentication of + data packets sent to and from a mobile node should use the IP + security protocols described in RFCs 1827 and 1826 for this purpose. + +4. MIB + + At the time of publication of this Applicability Statement, a + Management Information Base (MIB) for Mobile IP has been written and + documented in RFC 2006. + +5. Implementations + + Several implementations of Mobile IP are known to exist. The + following list gives the origin and a contact for several such + implementations: + + Organization: Contact: + + CMU Dave Johnson + FTP Software Frank Kastenholz + IBM Charlie Perkins + Motorola Jim Solomon + Nokia Gunyho Gabor + SUN Gabriel Montenegro + Telxon Frank Ciotti + +6. Implementation Experience + + FTP Software hosted an interim meeting, October 23-27, 1995 in which + interoperability of several implementations was demonstrated. The + following major features of the Mobile IP protocol were tested: + + + + +Solomon Standards Track [Page 3] + +RFC 2005 Mobile IP Applicability Statement October 1996 + + + 1) Mobile Nodes receiving and processing Agent Advertisements. + 2) Agents receiving Agent Solicitations and responding with Agent + Advertisements. + 3) Mobile Nodes registering with foreign agents on foreign networks. + 4) Packets being received by the mobile node after having been + tunneled by the home agent and de-tunneled by the foreign agent. + 5) Packets from the mobile node being routed directly to their + destinations. + 6) Mobile nodes discovering that their connectivity/subnet had + changed and re-registering at their new location. + 7) Mobile nodes discovering that their current foreign agent had + rebooted and therefore re-registering with that foreign agent. + 8) The required form of tunneling (IP-in-IP encapsulation + [MIP-IPinIP]) as well as the one of the optional forms of tunneling; + namely, Minimal Encapsulation [MIP-MINENC]. + 9) Mobile nodes de-registering upon returning to their home network. + 10) Registrations being rejected for authentication failures, + including invalid authenticators as well as mismatched + identification values (replay protection). + 11) TCP connections remaining open (with data flowing) while a mobile + node moved from its home network to a foreign network and then + back again to the home network. + + Interoperability of at least two independent implementations was + demonstrated for all of the features listed above. + +7. Summary + + The co-chairs, on behalf of the working group participants, believe + that the Mobile IP working group has satisfied the requirements set + forth in [RFC1264] for the advancement of Mobile IP to Proposed + Standard RFC. Specifically, the technical specification document is + stable, a MIB has been written, the security architecture has been + set forth in accordance with IAB principles, and several independent + implementations have been demonstrated to be interoperable. + +8. References + + [RFC1256] Deering, S., Editor, "ICMP Router Discovery Messages", RFC + 1256, September 1991. + + [RFC1701] Hanks, S. et. al., "Generic Routing Encapsulation (GRE)", + RFC 1701, October 1994. + + [RFC1264] Hinden, R., "Internet Routing Protocol Standardization + Criteria", RFC 1264, October 1991. + + + + + +Solomon Standards Track [Page 4] + +RFC 2005 Mobile IP Applicability Statement October 1996 + + + [MIP-IPinIP] Perkins, C., Editor, "IP Encapsulation within IP", + RFC 2003, October 1996. + + [MIP-OPTIM] Johnson, D., and C. Perkins, "Route Optimization in + Mobile IP", Work in Progress. + + [MIP-PROTO] Perkins, C., Editor, "IP Mobility Support", RFC 2002, + October 1996. + + [MIP-MINENC] Perkins, C., Editor, "Minimal Encapsulation within IP", + RFC 2004, October 1994. + +9. Author's Address + + Questions about this memo can be directed to: + + Jim Solomon + Motorola Inc. + 1301 E. Algonquin Rd. - Rm 2240 + Schaumburg, IL 60196 + + Voice: +1-847-576-2753 + Fax: +1-847-576-3240 + EMail: solomon@comm.mot.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Solomon Standards Track [Page 5] + -- cgit v1.2.3