Network Working Group Nathan Meyers Internet-Draft Informational An Alternate Approach to Achieving IP Mobility draft-meyers-etherip-mobility-00.txt This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright (C) The Internet Society 2001. All Rights Reserved. Abstract This memo describes an experimental approach to achieving IP mobility comparable to that described for Mobile IP (RFC2002), while addressing some of the issues impeding rapid adoption of Mobile IP. The value of Mobile IP is well known, but its adoption has been slow. One reason for this is the disruption it brings to mobile nodes: it requires mobile client software and processes to participate in its administration. The needed software is not mature or widely available, and deployment will be disruptive under the best of circumstances. We describe an IP mobility approach, based on the Xerox EtherIP protocol, that can reduce or remove the dependence on platform- specific mobile client software and processes. Background: IP Mobility and Wireless Networks The relevance of IP mobility is increasing with the rapid adoption of IEEE 802.11 wireless LANs. IP mobility brings two powerful advantages to such LANs: By allowing wireless access points to exist in multiple subnets, it supports roaming across arbitrarily large internets - including, for example, city-wide "community nets" based on 802.11. It allows wireless access points to be routed, rather than bridged (today's prevalent practice), to wired networks while preserving the "LAN-like" IP connectivity of wireless nodes. This enables good security practices, such as firewalls and VPNs, to be implemented at the boundary between secure wired LANs and not-so- secure wireless LANs. Proposal: Extending the LAN The problem of IP mobility appears when a device crosses the LAN boundary in an internet. The RFC2002[1] solution is to "extend the subnet" by tunnelling its level-3 protocol across the internet. This memo suggests an alternate solution: extending the LAN by tunnelling its level-2 protocol across an internet. The notion of tunnelling level-2 protocol over IP is not new: it is intrinsic to L2TP (RFC2661 [2]). And Xerox's EtherIP protocol, developed in 1991 and described in publications by Housley and Hollenbeck, provides for encapsulation of Ethernet frames in IP datagrams. The effect of this tunnelling is a virtual ethernet that spans arbitrary distances across an internet. The advantage of using level-2 tunnelling for IP mobility is that mobility can be achieved without requiring any special support in the mobile client device itself. This approach has an obvious limitation relative to Mobile IP: level-2 tunnelling imposes uniformity requirements on the underlying LAN architecture - for example, one cannot trivially tunnel between ethernet and token ring LANs. Nevertheless, the approach is broadly applicable to the IP mobility problem because of ethernet's prevalence in small networks and because of the affinities among IEEE 802.x networks. In particular, most 802.11 wireless access points include bridging hardware for connection to 802.3 ethernets. Describing the Extended LAN The basic architecture of this mobility solution can be described simply: Two or more ethernet subnets on an internet are identified to participate in the extended LAN. Each subnet has two routes to the internet: 1) A conventional router that handles traffic for nodes that belong on the subnet, and 2) an ethernet tunnel that handles traffic for roaming nodes connected to the LAN but configured for a different subnet. The ethernet tunnels from the various participating subnets are interconnected through a virtual switch to form a virtual ethernet. To better illustrate the architecture, we describe our experimental implementation. An Experimental Implementation: Some Background An experimental implementation has been built using OpenBSD nodes for the routing, tunnelling, and bridging devices. OpenBSD was chosen because it offers two powerful pseudo-devices that support the implementation work: A bridge pseudo-device that can route ethernet packets between multiple ethernet devices. This device will be represented in the schematic thus: --|BR|-- with connections on either side to ethernet devices being bridged. An ethernet pseudo-device that implements Xerox's EtherIP protocol. OpenBSD has a "generic tunnel interface" that, when coupled with the bridge, acts as such a device. Here is the schematic: --|BR|--|GIF|-- The flow of data through these devices looks like this: --|BR|--------------|GIF|-- ->ethernet frame-> ->etherip datagram-> <-ethernet frame<- <-etherip datagram<- with the GIF device providing encapsulation and decapsulation of the frames from and to the bridge. The GIF device serves as one endpoint of a dedicated tunnel, so the complete picture of the tunnel is: --|BR|--|GIF|---- < internet > ----|GIF|--|BR|-- where the two LANs off to the left and right of the page can now exchange ethernet frames as needed. Note that EtherIP is connectionless, but each GIF pseudo-device is configured to work with exactly one remote GIF endpoint. An Experimental Implementation: Describing the Router To complete the picture of a router in this extended LAN, we add four network interface cards, E1, E2, E3, and E4. Schematically, the router that connects the LAN to the internet looks like this: LAN OpenBSD-based Router | | | +--|E1|---------------|E3|-- < internet > | | +--|E2|--|BR|--|GIF|--|E4|-- < internet > | | local | devices | or --+ access | point | | Devices E1 and E2 connect to the local subnet, E3 and E4 to the internet. The E1-E3 path comprises a standard router, forwarding IP packets (possibly performing NAT) in the usual way between the subnet and the internet. The E2-E4 path is for ethernet frames that do not belong on the subnet - for example, from roaming mobile devices configured for a different subnet. E2 does not have an IP address, but promiscuously captures all frames. Any frames for devices not found on the LAN (plus broadcast frames such as ARP) are forwarded by the BR to the GIF for encapsulation in an EtherIP datagram and forwarding to the other end of the tunnel. Similarly, any etherip datagrams received by E4 are decapsulated, passed through the bridge, and injected into the LAN. This provides the needed connectivity for the roaming node. Note that E3 and E4 can easily be the same interface - the distinction here is purely conceptual. It's also possible with OpenBSD to use a single interface for E1 and E2, although not all interactions between the routing and bridging functionality are well-defined and this is not recommended. An Experimental Implementation: Building the Virtual LAN To complete the extended LAN, we join these routers through a virtual switch that can route the encapsulated ethernet frames. The OpenBSD bridge pseudo-device described earlier can handle more than two ethernet connections - that is, it can also function as a switch. The virtual switch in the experimental implementation is a single node with a single IP address that implements one endpoint for each EtherIP tunnel, and a switch pseudo-device to route packets between these endpoints (we represent the NIC as "|E|"): | |---|GIF|---| | | |---|GIF|---| | < internet > ---|E|---|GIF|---|BR| | |---|GIF|---| | | |---|GIF|---| | Combining (and simplifying) the diagrams, we illustrate the interconnection of two routers and the switch: | LAN1 +--|E1|--|BR1|--|GIF1|--|E2|--~~~~~~~|~~|---|GIF3|---| | | | |---|GIF4|---| | --|E5|---|GIF5|---|BR3| | | |---|GIF6|---| | LAN2 +--|E3|--|BR2|--|GIF2|--|E4|--~~~~~~~|~~|---|GIF7|---| | | where the "~~~" symbols represent the two EtherIP tunnels - GIF1/GIF3 and GIF2/GIF7. In this simplified diagram, we've left out the normal, non-tunnelled routes from the LANs to the internet. We've also excluded other participating LANs from the diagram. An Experimental Implementation: Describing the Communications With the overall connection architecture just shown, we describe the behavior of a mobile node configured for LAN1's subnet but connected to LAN2. Any outbound packet from our mobile node will be targeted at some device - another node or the gateway - expected on LAN1's subnet. The following sequence takes place: The mobile node sources an ARP request. This is passed from E3 to BR2 to GIF2, which encapsulates it in an EtherIP packet that is sent to the internet through E4. The EtherIP packet is received by E5, decapsulated by GIF7, and sent to BR3. BR3 records an association between the mobile node's MAC address and the virtual ethernet device GIF7 in its address cache, and also broadcasts the ARP to GIF3, GIF4, GIF5, and GIF6. Each reencapsulates the ARP in an EtherIP datagram and sends it to its remote tunnel endpoint. One of these datagrams is received by E2, decapsulated by GIF1, and passed through BR1 and E1 to the mobile node's home LAN. The target node or gateway, if present, generates an ARP reply and records an ARP table entry. The ARP reply travels the request's route in reverse: E1 to BR1 to GIF1 to E2, over the internet to E5, GIF3, and BR3. BR3 adds another entry to its MAC address cache (for the target node or gateway) and forwards the reply back to LAN2 through GIF7, E5, E4, GIF2, BR2, and E3. At this point, the two IP endpoints have found each other and all further packets follow this same route. The MAC address cache entries maintained by BR3 enable the communication to proceed without wasteful packet-flooding of the other tunnels. The scenario changes only slightly if the first communication is from LAN1 to LAN2 (for example, a packet received by LAN1's gateway needs to find the mobile node): in this case the ARP request originates in LAN1 and its reply in LAN2, but the pathways and logic are identical. An Experimental Implementation: Analysis There is, of course, a wide gulf between an experimental implementation and a useful deployment. Here are some issues raised by the implementation shown here: ARP is intended for use on a LAN, not across a slow, unreliable network. So this architecture, while good for a small network, does not trivially scale to a large network. RFC1029[3] discusses a similar problem (albeit on a smaller scale) when scaling up a small LAN with bridges. Some of the approaches discussed there, such as adding ARP caching functionality to bridges, might profitably be applied to this problem. Roaming does not break any IP connections as a mobile node moves between subnets, but it does introduce a delay for packets trying to find the roaming node. This delay is caused by the central switch's (BR3 in the diagram) caching of MAC address routes, which delays the search for the mobile node's new location. This can be addressed by enforcing a short timeout on the switch's cache (at the cost of greater bandwidth demands). The switch will also find and record the mobile node's new location as soon as that node sends a frame. The mobile node could assist with periodic pings (although this, too, adds bandwidth cost). The most economical approach, in terms of performance and bandwidth conservation, would be new virtual switch logic that drops, in a timely fashion, a cache entry that appears to be dead. This will enable the packet flooding necessary to find the roaming mobile node in its new location. The LANs participating in this extended LAN can have public or private IP addresses, but a node with any particular IP address should not appear on more than one LAN. Although not mandatory, common sense suggests a further restriction: the LANs should be in different subnets. The star topology of the extended LAN imposes scaling challenges as well as a dependence on a single point of failure. This can be addressed with approaches comparable to those used to scale up physical LANs - for example, a hierarchy of switches such as this: | |---|GIF|---| | | |---|GIF|---| | ---|E|---|GIF|---|BR|---|GIF|---|E|---+ | |---|GIF|---| | | | |---|GIF|---| | +---|E|---|GIF|---| | |BR| | |---|GIF|---| | +---|E|---|GIF|---| | | |---|GIF|---| | | ---|E|---|GIF|---|BR|---|GIF|---|E|---+ | |---|GIF|---| | | |---|GIF|---| | Multiple tunnelling routes may also be used for redundancy, using Spanning-Tree Protocol in the virtual bridges and switches to eliminate loops. The notion of a mobile node's "home network" is not terribly rigid: it is whatever LAN happens to be configured for a subnet matching the mobile node's IP address and happens to provide a gateway at the address expected by the mobile node. This becomes an issue of special interest if DHCP is used: a mobile node's "home network" may be whichever nearby LAN answers its DHCP query. But complication quickly ensues: once the node has a home network, any DHCP renewal or release message must be received by the home network. This will require unorthodox handling of DHCP within each participating LAN: renewal or release messages referencing a different subnet must be ignored by the local DHCP server and tunnelled to the home network. Conclusions Although we have an experimental implementation of an extended LAN, much still needs to be learned about its usability with real-world internets and, in particular, with wireless networks. We expect to iterate on this draft as a result of further experimentation and discussion. References [1] C. Perkins. IP Mobility Support, RFC 2002, October 1996. [2] W. Townsley, et al. Layer 2 Tunnelling Protocol ("L2TP"), RFC 2661, August 1999. [3] G. Parr. A More Fault Tolerant Approach to Address Resolution For A Multi-LAN System of Ethernets. May 1988. Security Considerations Tunnelled ethernet packets have the same security vulnerabilities as any other unarmored IP traffic. Much work has gone into security considerations for Mobile IP, and we will explore similar ideas for inclusion in future versions of this draft. Author's Address Nathan Meyers 2124 NE 60th Avenue Portland, OR 97213 USA Phone: +1-503-282-7185 EMail: nmeyers@javalinux.net Full Copyright Statement Copyright (C) The Internet Society 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.