TCP and UDP in the Mobile World, or What is Wrong with Mobile IP version 6, and How to Fix it

Transcription

1 TCP and UDP in the Mobile World, or What is Wrong with Mobile IP version 6, and How to Fix it Pekka Nikander Ericsson Research NomadicLab 1, 2 Abstract The TCP/IP protocol suite was originally designed in late 1970s, and finalized in Since then, its trans - port layer protocols, TCP and UDP, have been rela - tively stable. On the other hand, the environment where the protocols work, and the requirements placed upon them, have gradually but constantly changed. So far, it has been possible to cope with the situation by upgrad - ing underlying protocol, i.e., IP, or by adding patches between the IP layer and the upper layers. The current Mobile IP standard is a prime example of this kind of patching; it goes hoops over to create an illusion of a static environment to both TCP and UDP. In a way, this has been necessary in order to provide full backward support to the legacy applications and network infra - structure. The advent of the next generation of IP, IP version 6, creates a possibility to change the situation. However, in our opinion, the situation is not changing, at least not to the extent desired. The current Mobile IP version 6 (MIP6) proposal is still trying to support the old semantics towards TCP and UDP, and, among other things, doing so greatly increases both protocol processing complexity and the average IP header size. In this paper, we analyze the assumptions behind the current Mobile IP version 4 and 6 design, and point out how some of the assumptions do not necessarily hold for version 6. After that, we present a different mobility ar - chitecture for IPv6, and compare our proposal with other approaches. 1. The research forming background for this paper was conducted when the author was on leave from Erics - son Research, and acted as a professor at Helsinki University of Technology. 2. The opinions presented in this paper are in no way endorsed by Ericsson or related to Ericsson official policy, and present solely the personal opinions of the author. 1 Introduction To us, it seems like the future IPv6 world will be fundamentally different from the current IPv4 Internet. We believe that most of the IPv6 enabled devices will be small and often mobile, embedded in various everyday things. For example, it seems like the mobile phones will more and more become parts of our clothing, and get integrated to other types of digital gadgets that we carry around. In the new world, there are a few fundamental differences in networking, when compared it to the current typical use. First, the majority of the devices will be mobile. Second, many of the devices will have multiple simultaneous network connections, often called simultaneous multi-access. For example, a future mobile home might well have BlueTooth, UMTS, and HiperLAN 2 connections. Furthermore, it might want to move sessions from UMTS to HiperLAN 2 (or vice versa) whenever the faster or cheaper access becomes available, and back to the other when connectivity with the better access network is lost. Since both mobility and wireless access seem to become commodities, support for them should be integrated to the network infrastructure from the very beginning. Unfortunately, this is not always the case in the current IPv6 architecture. As the IPv6 specifications stand today, they still reflect much of the existing IPv4 thinking. For example, mobility [2] is more or less an add on to the architecture, there are a number of well-known problems with TCP performance when used over wireless links, and the current security architecture does not adequately address all of the security threats caused by the dynamic addressing architecture and mobility [18]. In this paper, we concentrate on mobility, simultaneous multi-access, and security. The actual physical characteristics of the air interface, and its effects to the individual protocols, such as TCP, are beyond the scope of this

2 paper. However, we consider some cases where they cause pressures towards the architecture. The rest of this paper is organized as follows. First, before going to the topic in detail, in Section 1.1 we first briefly outline the tradeof between routing and mobility with respect to address stability. In the light of this, in Section 2 we describe a number of problems in the current IPv6 architecture. After that, in Section 3, we propose a small but fundamental change to the architecture. In Section 4 we present our initial evaluation, and show that the revised architecture has a number of benefits when compared to the current one. Finally, Section 5 contains our conclusions of this research. 1.1 Addressing, routing, and mobility The purpose of addresses is to act as means of reaching their owners. That is, if you want to reach a party, and have an address for that party, the assumption is that sending your packet labeled with the address will take your packet to the expected recipient. In a packet switched network, the routing function takes care of passing the packets to their destinations. Basically, a router takes a packet, inspects the destination address, looks for an entry in the routing table, and forwards the packet based on the information in the routing table. Now, the size and complexity of the routing table is a function of the number of addresses and the amount of aggregation that can be performed on the addresses. That is, if it is possible to bunch together a number of addresses, the size and complexity of the routing table is decreased. This, in turn requires that addresses having the same beginning, or prefix, are topologically located at the same part of the network. Now, since efficiency of the routing infrastructure requires that addresses are aggretable, mobility seems to have opposite requirements than routing. That is, the structure of the routing infrastructure makes it impossible to locate addresses at arbitrary locations; the routing tables would not be aggretable any more. Thus, no packet based mobility scheme can be based on an assumption that it is possible to move IP addresses arbitrarily from a position to another. In other words, it is the network that provides the addresses based on the topology, and the mobile nodes simply must use, as their active address, an address provided by the network at their current location. The current Mobile IP solution to this problem is to use two addresses: the home address is based on mobile node s identity, and the care-ofaddress (CoA) is based on the current location. 2 Problems in the current IPv6 architecture When the present IPv6 architecture was devised in mid 1990 s, the currently ongoing explosion of wireless internet access was not in sight. Mobile IP was still at its infancy at that time [8], and there were relatively little cooperation between the people working on Mobile IP and IPv6 sadly enough, there still seems to be relatively little interaction between these two groups of people. Hence, the implicit assumption was to base IPv6 design on the then (and still currently) mostly static network model. In the static model, both in the IPv4 and IPv6 worlds, most of the hosts are assumed to be static, or at least to have some kind of static addresses. In our opinion, it begins to be time to abandon this assumption. If we take the currently extremist view of assuming that almost all IPv6 hosts will be mobile, have more or less dynamic addresses, and want to adaptively use several simultaneous network connections as the same time, a number of problems are revealed. In this section, we take a look at a few of them. First, in Section 2.1, we discuss the Mobile IPv6 assumption of home addresses. Next, in Section 2.2, we discuss why we believe that the idea of static addressing should be abandoned for nonmobile hosts, too. Section 2.3 represents a already existing security problem, which we call the address ownership problem, and briefly proposes one solution to it. Finally, Section 2.4 discusses simultaneous multi-access and Section 2.5 multihomed of sites and hosts. 2.1 To have a home or not to have The present Mobile IPv6 architecture [2] is heavily based on the assumption that each and every mobile host has a unique home address. Currently, the home address has multiple uses. First, the home address acts as a connection endpoint identifier for long living connections. That is, whenever you have a TCP connection or a series related UDP transactions that you want to continue even when moving you are expected to use your home address as the address associated with your TCP and UDP sockets. Second, the home address can be used to reach you, i.e., all packets sent to your home address are expected to be forwarded to you. Third, there seems to be a growing tendency to use the home address as a means to identify you for billing and charging, and also for other purposes like personalized advertising and profile collection and correlation. Now, if we imagine a world where your future PDA, handsfree earplug, wristwatch, jacket, and maybe even your socks, have IP addresses, at least I am having hard time imagining that you would like to have global 2

3 reachability and traceability for all of them. Besides, where would the home agent run, required to maintain the home addresses. Maybe at a home server located at the basement of your house, or maybe in the processor installed to keep track of the contents of your fridge. Viable solutions, certainly, but maybe not the desirable ones. If nothing else, the administrative burden might be just a little bit too high. In our future vision, most of the mobile devices do not have any natural home location. Therefore, providing them with a home address requires awkward and unnecessarily complex solutions. On the other hand, the devices would still like to maintain TCP connections even if their IP addresses change dynamically due to mobility activity. Thus, as a requirement for a natural mobility solution in IPv6, we would like to see an architecture where home addresses and agents may be used, whenever desired for reachability or traceability purposes, but where they are not mandatory. Furthermore, we believe that the solution described in Section 3 fulfils this goal. 2.2 Site renumbering and other sources of address change While mobility provides an IP enabled device with a series of relatively fast changing addresses, the IPv6 specifications include a number of features that seem to provide even stationary hosts with a series of changing addresses. The two most prominent reasons for these infrequent address changes are privacy [4] and site renumbering [3]. Let us look at site renumbering first. In the current Internet, whenever a company wants to change its ISP or the logical point of attachment to the Internet, hell breaks loose. Since the IP address are owned by the ISP, changing ISP means changing all addresses. As we all know, that will require a little bit of effort. Furthermore, open connections have zero probability of survival. In the IPv6 world, the basic situation is still much the same: you must change your addresses, but the situation is much more automated. The router renumbering protocol [3] may be used to inform the routers within the company about the change. Address autoconfiguration [5] will yield the currently used addresses obsolete, forcing all new connections to be created with new addresses. Unfortunately, all the currently open connections will still, eventually, be broken as the traffic ceases to flow through the old ISP. The privacy extension [4] allows a host to initiate an address change itself. When is used, the situation becomes pretty much the same. The old connections must eventually be terminated, unless the host wants to keep the old address available just to keep the old connections flowing. In both situations, the system would benefit if the existing connections could be seamlessly transferred to use the new addresses. Our modified architecture provides this possibility. 2.3 The address ownership problem Whenever Mobile IPv6 Binding Updates [2], IPv6 Routing Extension Headers [1], or ICMPv6 Redirects [6] are used, a host s idea of where to send packets with a certain IP address change. That is, instead of passing a packet to the next router based on its destination address and the default routing rules, the host creates its own idea how and where to pass the packet. This is useful, since it allows various optimizations. Binding Updates provide route optimization for mobile hosts, Routing Extension Headers allow alternative routes to be used in the face of network breaks etc., and Redirects allow various useful functions like load balancing between routers. Changing a host s idea of routing is a two-edged sword. In addition to being useful, it is also a potential vulnerability. Basically, it is an excellent too for traffic hijacking. You just convince your a host that its peer is currently reachable through you, and you get all the traffic from your target host to its peer passed to you. If you want to have traffic in both directions, you just play different faces to the target and its peer. In attempt to close this vulnerability, the current specifications require that Binding Updates, Routing Extension Headers, and ICMP Redirects (among other things), must be authenticated with IPsec Authentication Headers (AH) [14]. Unfortunately, the specifications mostly forget to mention another requirement, authorization, and even in the cases where authorization is mentioned, the specs are rather silent about what authorization does mean. In fact, depending on the scope of communication, the authorization problem may be relatively easy or very hard to solve. Let us approach the hard end of spectrum through an example. Now, let us consider a case where an arbitrary mobile node (MN) wants to send a Mobile IPv6 Binding Update (BU) to another arbitrary host that it is communicating with, i.e., to a correspondent node (CN). Now, 3

4 in order to do so, the MN must first establish an IPsec AH Security Association (SA) [14] with the CN. This can be made through a number of mechanisms, the most prominent of which is to use the IKE protocol. Since the MN and CN do not know each other in advance, they need to have some credentials passed to the IKE in order to be able to create the SA securely. These credentials may be based on, e.g., using a Public Key Infrastructure (PKI) and certificates, or using the Authentication, Authorization, and Accounting (AAA) architecture. So far so good. Let us now consider the credentials. Apparently, the credentials must include some information about the Home Address (HA) that the MN wants to use. If they didn t, a dishonest MN could claim to have any arbitrary host s address as its home address, thereby stealing the traffic sent by the CN to the victim host. Thus, the credentials must tell what home address or home addresses the MN is allowed to use. So far so good, other than that the current specifications do not present this requirement. (We are currently in the progress of proposing the specifications to be updated.) Now, unfortunately, the final and hardest question is the credibility of the credentials. Let us consider the PKI case first. Today, it is relatively easy for anyone hosting a Web site to get an X.509 certificate for that domain name. A little bit of DNS tweaking, and you can make the domain name to point to any arbitrary address, and through a relatively simple DNS cache poisoning you can even make reverse DNS to match. Thus, an X.509 certificate containing a domain name is definitely not secure enough alone. How about the case of AAA, then? In the AAA infrastructure, an operator basically accepts whatever comes from its trusted peers. Thus, in order to launch such an attack successfully, you just become a small operator at some obscure Pacific island, behave in all other respectfully, but just occasionally happen to lie about the home addresses your customers are using. Or maybe you just happen to work for NSA, and act on the auspice of an operator NSA happens to own. Thus, neither the PKI nor the AAA infrastructure, as currently planned to be deployed, is sufficient enough to securely prove an arbitrary CN that an previously unknown MN is really authorized to use a particular home address. Fortunately, there is one solution that will work, though, once deployed. If the reverse DNS infrastructure is secured using DNSsec, it could be used to map the claimed home address to a public key. Now, if that public key is used for IKE, the CN can be sure that the key is actually authorized to use the claimed address. Unfortunately, this use of DNS is still under discussion, and it is not known at this writing, when secure reverse IPv6 DNS will be available, if ever. 2.4 Simultaneous multi-access In the future world of integrated wireless gadgets, many of the devices may have several simultaneous radio connections to the fixed infrastructure. Furthermore, it is probable that the radio coverage of the various access networks will vary differently from area to area. Therefore, the devices need to be able to dynamically switch from using one radio access network to another radio access network. Sometimes the different access networks use different technologies, sometimes they are based on the same technology but may be administratively totally different. Since the IP addressing infrastructure is heavily based on routing topology, and great concern is paid on routing table optimization [CIDR, IPv6 addressing architecture], changing the underlying radio access means that the current IP address(es) also change. Now, even if the current Mobile IPv6 specification [MIP6] provides the necessary functionality to change the current IP address, i.e., to register a new care-ofaddress (CoA). Unfortunately, it allows only one careof-address to be used at one time; furthermore, changing the CoA transfers all connections (that use a specific home address) to use the new CoA. Thus, from the point of view of simultaneous multi-access, the current Mobile IPv6 is not very flexible. It is certainly possible to use several home addresses in order to get more flexibility in assigning various long lived connections on different access networks, but such a practice is not in line with the original intend of the Mobile IPv6 specification. Again, this is one area where we believe that our proposed solution can do better. It offers more flexibility to assign different flows on different access networks, and makes it easier and more lightweight to move connections from using one access network to using another. 2.5 Multihoming of sites and hosts The final problematic area that we cover here is multihoming. However, as the area is a fairly large one with deep implications on addressing, routing, and routing protocols, and relatively well documented elsewhere (e.g. [9],[15]), just a few remarks are given here. 4

5 First, when considering single host multihoming and simultaneous multi-access, there is considerable overlap. In a way, what we call simultaneous multi-access is the mobile variant of traditional single host multihoming. Consequently, there is some overlap in the solutions designed for multihoming (e.g. SCTP [12]) and the solution presented in this paper. This issue is discussed in some more detail in Section, below. Another, more complicated area is multihomed sites, and their mobile equivalent, mobile networks having multiple connections both to other mobile networks and to the fixed infrastructure. This is an area of active research, related to Mobile IP in general [15], ad hoc networking and routing, general addressing and routing information aggregation, among others. Further details are beyond the scope of this paper. 3 From address orientation to host orientation In this section, we briefly describe our proposed changes to the Mobile IPv6 architecture. Technically, the proposed changes are fairly small, but from the architectural point of view, they have fundamental effects. That is, they slightly change the semantics of the API between the IP layer and the upper layers; on the other hand, no changes to the syntax of the API nor the wire protocols are required. First, in Section 3.1, we describe the new basic data structure, the Host Cache. After that, in Section 3.2, we describe how the Host Cache is used to bind the communication endpoints, i.e., the sockets, into hosts rather than single IP addresses. Finally, Section 3.3 describes the effects on applications. 3.1 Host Cache The Host Cache is a new fundamental data structure introduced in our architecture. In our vision, each IPv6 host would maintain a Host Cache. The Host Cache consist of Host Cache entries, each describing information about some a peer host. An extract from a typical Host Cache contents is depicted in Figure 1. The most important piece of information stored in a Host Cache entry is the set of IP addresses through which the host is currently reachable. For example, an entry representing a fixed, non-multihomed host just contains a single address. Correspondingly, an entry describing a fixed multihomed host would contain a Local host 0000:0000:0000:0000:0000:0000:0000:0001 fe80:0000:0000:0000:0000:0000:0000:0001 fe80:0000:0000:0000:0201:02ff:fe33:0fb9 3ffe:0200:0010:0005:0201:02ff:fe33:0fb9 fe80:0000:0000:0000:0200:c0ff:fe99:0eac 3ffe:0200:0010:0005:0200:c0ff:fe99:0eac homeless1.nomadiclab.com 3ffe:0200:0020:0175:0200:c0ff:ff66:17a5 3ffe:0200:0050:1bc7:0200:c0ff:ff55:7291 Incoming SA Figure 1: Typical Host Cache contents fixed set of addresses, and an entry describing a mobile host contains would contain a dynamic set of addresses. For security reasons, all updates to the host caches must be authorized, as we already discussed in Section 2.3. Therefore, each cache entry also contains a reference to a pair of IPSEC AH Security Associations (SA). The SAs are used to protect the updates. Once a cache entry is created, it is the responsibility of the host represented by the entry, to keep the entry up to date. The peer takes care of this by sending Mobile IPv6 Binding Updates. Thus, from a Mobile IPv6 point of view, a Binding Update does not any more update the single binding between a home address and a care-ofaddress, but it adds or deletes addresses in the host address set. This allows the correspondent hosts to keep up to date information about all the addresses of a mobile host instead of just using a single care-ofaddress. Furthermore, no explicit home addresses are needed; to identify a cache entry, any existing address within a cache entry can be used. 3.2 Socket Bindings Outgoing SA homeless2.hut.fi 3f80:0200:0000:093c:0200:c0ff:ff99:1cae 3f80:0200:0000:0952:0200:c0ff:ff30:1f47 Incoming SA Outgoing SA We add a slim data structure layer between the transport layer protocols and the IP layer. In practice, this change is most clearly visible in the way sockets, i.e., communication endpoints, are bound in the data structures. In the 5

6 socket local foreign Local host 0000:0000:0000:0000:0000:0000:0000:0001 fe80:0000:0000:0000:0000:0000:0000:0001 fe80:0000:0000:0000:0201:02ff:fe33:0fb9 3ffe:0200:0010:0005:0201:02ff:fe33:0fb9 fe80:0000:0000:0000:0200:c0ff:fe99:0eac 3ffe:0200:0010:0005:0200:c0ff:fe99:0eac homeless1.nomadiclab.com 3ffe:0200:0020:0175:0200:c0ff:ff66:17a5 3ffe:0200:0050:1bc7:0200:c0ff:ff55:7291 Figure 2: Socket bindings in our modified IPv6 architecture current TCP/IP, a connected socket is bound to a single local and a single foreign address. In our modified architecture, a socket is not bound to two single addresses but to two Host Cache entries. Figure 2, on the next page, depicts our modified data structure. A local Host Cache entry enumerates the local addresses which the socket may use, and, a foreign Host Cache entry enumerates the addresses of the foreign host that it knows about. When a packet is sent, the sending host may select the destination address freely among the active addresses available at the foreign host cache entry. The selection may be made on packet bases. Once the destination address is selected, the source address may be selected among the ones available at the local Host Cache entry. Similarly, when a packet is received, its source and destination addresses are compared against the Host Cache. If there is a foreign Host Cache entry that contains the source address and a corresponding local Host Cache entry that contains the destination address, it is easy to determine where the pass the packet to. 3.3 Effects on Applications Most applications never detect the proposed change of semantics in the underlying IP layer. They open a connection using whatever IP address the local DNS resolver gives them, thereafter just forget about the address. If the underlying addresses change, the application is completely unaware of that as long as the connection continues to function as before. We call this class of applications address agnostic. Unfortunately, there are a few classes of applications that are not that address agnostic. First, many UDP servers use unconnected UDP sockets, and compose reply packets by themselves, based on the addresses received in the query. Second, there is a small class of badly designed applications that send IP addresses within protocol packets. FTP is the prime example of these. And third, there are some applications that store IP addresses in long term storage, or otherwise explicitly handle IP addresses. Let us consider these next. First, most UDP applications work normally even if the underlying IP addresses change. Typically, the UDP transactions are relatively short term, and in the rare case that the reply is completely lost, they rely on error recovery mechanisms built on the top of UDP. Second, the badly designed protocols that include IP addresses inside upper layer protocol packets may or may not suffer from the changing addresses. In principle, even FTP could survive since the IP address is needed only temporarily when opening a new transfer connection. However, in practice few if any FTP clients request their current IP address individually for every PORT command, but instead store the address and reuse it whenever needed. Thus, in practise, most of the applications in this category would need work. On the other hand, most of these applications will need to be reworked anyhow in the process of adapting them to work in the IPv6 world. The third class of applications, i.e., those that store IP addresses for extended periods of time, are in clear conflict with the Internet Architecture (RFC 1958 [13], Section 4.1), and they need to be fixed in any case. Thus, in summary, we believe that all well designed applications will continue unaffected even when running on the top of the new architecture. What comes to the exceptions, it is our strong opinion that they have design flaws anyway, and should be fixed in order to be compliant with the Internet Architecture and sound security principles. Once that is done, even those applications should work fine. 6

7 4 Evaluation Even though we are still in early phases in our research, we have very good feelings about solution. It seems to help in solving a number of hard problems that IPv6 may be facing in the future. Thus, in Section 4.1, we first briefly describe these benefits, together with some potential drawbacks. In Section 4.2 we compare our solution to some related work, and especially discuss the overlapping functionality with SCTP. 4.1 Benefits and drawbacks The main benefit of our proposed change is the loosening of the currently very strict binding between hosts and addresses. That is, the binding the logical communication endpoints (sockets) to data structures representing hosts instead of binding them directly to addresses greatly enhances flexibility. From performance point of view, the main benefit is that packets do not need any extra headers even when flowing between two mobile nodes or between a mobile node and a stationary node. This is much better than the current Mobile IPv6, which requires that the Home Address Destination Option and/ or the Routing Header Extension must be used, adding bytes to each IP packet. If we look back at the problems described in Section 2, there is no need for explicit home addresses in our system. Home agents may be used as before for forwarding packets to mobile nodes, but home addresses are not needed any more for identifying connection endpoints. In addition to other benefits, this may also be used as a mechanism to enhance privacy, since it is no more so easy to track single devices and users. In addition to mobility, other things that cause address changes, including site renumbering and using the privacy extension [4], clearly benefit as connections can easily survive the address changes without any extra overhead. What comes to simultaneous multi-access and multihoming, there are also immediate benefits. As our scheme allows several addresses to be associated with a single host, it allows the correspondent nodes to have an accurate idea of the addresses and reachability of a mobile node or a multihomed host. In a way, this allows the selection of the used address and access medium to be made independently, allowing the decision to be made as a policy decision instead of being mandated by implementation limitations. On the other hand, added flexibility means added security problems, too. In a way, the address ownership problem (see Section 2.3) may potentially have much larger consequences than it does in the current architecture. However, since the problem needs to be solved anyway, we don t see any reason for further worries. On the other hard, we assume that our proposal may even open up new possibilities to solve the address ownership problem (see the related Internet Drafts [17][18]). 4.2 Related work In general, IP mobility solutions can be divided into two groups [16]: address translation schemes [2][8], working at the network layer, and connection forwarding [7][9][12] techniques, usually located at the transport layer. Perhaps the main difference between these two approach is in attitude. Most address translation schemes attempt to hide mobility from the transport layer and the layers above, while connection forwarding is usually a transport layer function, and often more or less visible to the applications, too. Compared to these other approaches, our proposal is slightly different. It is basically a connection forwarding technique, but instead of being located at the transport layer, it is located at the top of the network layer, or perhaps between the network and transport layers. Furthermore, in our scheme the transport protocols or the applications do not need to be aware of mobility, or rather, they may become aware if they want to become. Interactions with SCTP. The Stream Control Transport Protocol (SCTP) [12] is a new IETF standard providing enhanced TCP like transport service. Even though it is primarily designed to provide transport to signalling protocols, e.g., SS7, some people expect that it may replace TCP in some application areas. As a primary feature, the SCTP protocol allows the connection endpoints to be defined as groups if IP addresses. The basic motivation behind this has been the need to provide robustness and load balancing capabilities to large multihomed hosts. To further enhance robustness, in their recent Internet Draft [10], R. R. Stewart et al. propose a method for dynamically adding and removing addresses from the SCTP endpoint address sets. However, from the mobility point of view, the proposed addition to SCTP defines one possible connection forwarding method. If the SCTP protocol is to become the de facto transport standard in the IPv6 networks, care should be taken that there will not be overlapping functionality in the network and transport layers. Thus, one of the future issues to study is to see if the currently presented architecture could be applied to SCTP, thereby simplifying SCTP. 7

8 5 Conclusions In this paper, we have argued that the IPv6 architecture, as it stands today, is not the best possible one when considering wireless and mobile hosts. Thus, as we believe that the majority of future IPv6 hosts are going to be small, wireless, mobile devices, there is a strong need to update the IPv6 architecture. To facilitate this needed change, we propose a technically small but semantically largish change to the IPv6 architecture. In our approach, the basic idea is to represent hosts with a group of equal addresses, instead of using a single fixed address to identify the host. Furthermore, the address groups may be dynamic, allowing the groups to accurately represent the reachability of the hosts in question. The major benefits our approach are the following. First, it allows natural representation of fixed multihomed hosts and of mobile hosts that have multiple simultaneous connections with several access networks. Second, it allows mobile hosts, and other hosts in need to change their currently active addresses, to maintain long term connections in a efficient and natural way. Finally, our approach reduces the average IP header size by not requiring any extra headers in the packets flowing from and to mobile hosts. As there is no increase in the amount of signalling, our approach is clearly more efficient that the currently standardize approach. On the security side, our approach highlights the need to solve what we call the address ownership problem in IPv6. In this paper, we briefly explained the problem and mentioned one solution. An accompanying paper [18] describes the problem in more detail, and proposes additional solutions. References [1] S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC 2460, Internet Engineering Task Force, December [2] David B. Johnson and Charles Perkins, Mobility Support in IPv6, work in progress, Internet Draft draft-ietf-mobileip-ipv6-13.txt, Internet Engineering Task Force, November [3] M. Crawford, Router Renumbering for IPv6, RFC 2894, Internet Engineering Task Force, August [4] Thomas Narten and Richard Draves, Privacy Extensions for Stateless Address Autoconfiguration in IPv6, Internet Draft draft-ietf-ipngwg-addrconf-privacy-03.txt, work in progress, Internet Engineering Task Force, September [5] S. Thomson and T. Narten, IPv6 Stateless Address Autoconfiguration, RFC 2462, Internet Engineering Task Force, December [6] A. Conta and S. Deering, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification, RFC 2463, Internet Engineering Task Force, December [7] Alex C. Snoeren, Hari Balakrishnan, An Endto-End Approach to Host Mobility, Proceedings of ACM MobiCOM 2000, ACM, [8] P. Bhagwat, C. Perkins, and S. Tripathi, Network layer mobility: an Architecture and Survey, IEEE Personal Communications, June [9] C. Huitema, Multi-homed TCP, Internet Draft (expired), Inria, May [10] R. R. Stewart, Q. Xie, M. Tuexen, I. Rytina, SCTP Dynamic Addition of IP addresses, Internet Draft draft-stewart-addip-sctp-sigtran-01.txt, work in progress, Internet Engineering Task Force, November [11] Irene Wu, Beichuan Zhang, and Bing Zhang, Extended Transmission Control Protocol (ETCP) Project, Berkeley University, December 1997, ETCP/ [12] R. Stewart et. al., Stream Control Transmission Protocol, RFC 2960, Internet Engineering Task Force, October [13] B. Carpenter (Editor), Architectural Principles of the Internet, RFC 1958, Internet Architecture Board, June [14] S. Kent and R. Atkinson, IP Authentication Header, RFC 2402, Internet Engineering Task Force, November [15] Thierry Ernst, Ludovic Bellier, Castelluccia Claude and Hong-Yon Lach, Mobile Networks Support in Mobile IPv6, Internet Draft drafternst-mobileip-v6-network-00.txt, work in progress, July [16] Janne Lundberg, Infrastructureless IP Mobility for Multi-homed hosts, Master s Thesis, Helsinki University of Technology, February [17] Pekka Nikander, Janne Lundberg, Catharina Candolin, and Tuomas Aura, Homeless Mobile IPv6, work in progress, Internet Draft draft-nikander-mobileip-homelessv6-00.txt, Internet Engineering Task Force, November [18] Pekka Nikander et. al., The Address Ownership Problem in IPv6, Internet Draft draft-nikanderipng-addressownership-00.txt, Internet Engineering Task Force, February

9 This document was created with Win2PDF available at The unregistered version of Win2PDF is for evaluation or non-commercial use only.