Qualcomm white paper on mobility and IP addressing

February 1997


1. Qualcomm believes that there is a large pent-up market demand for an easily implemented "basic" IS-95 packet data service that can and should be widely deployed as soon as possible. This service would provide packet-level connectivity to the Internet with IP addresses dynamically assigned by the serving system as part of the PPP link establishment procedure.

2. Qualcomm believes that "IP mobility", defined as the ability to use the same static (permanently assigned) IP address in a home system and when roaming, is not needed by the vast majority of mobile packet data applications. Furthermore, mobility (no matter how it is implemented) entails significant per-packet network overhead. Even if mobility is provided, its use should be optional.

3. The rare mobile application that does need static addressing is best served by the Mobile IP protocol as it is currently being standardized in the Internet Engineering Task Force (IETF). Mobile IP is functionally superior to CDPD mobility, in that the former supports "roaming" between arbitrary parts of the Internet, including both wired and wireless networks.

4. The Mobile IP "Foreign Agent" feature can be implemented either in the IS-95 base station or in the mobile user's computer. The latter option shows how a user can add his own mobility features to a basic packet data service without the cooperation or even the knowledge of the packet data service provider. This further argues against any delay in deploying an IS-95 packet data service on account of mobility features.

5. Billing and mobility are independent issues in IS-95. The serving system can use the mobile station ESN and MIN, plus the existing IS-95 intersystem service features, to identify and verify a roaming mobile and to generate billing records.


The Nature of Mobile Applications

It is the nature of mobile networking that virtually every application runs as a client on the mobile computer, communicating with servers running elsewhere in fixed locations. Internet application protocols in common use include the following:

Domain Name Service (DNS) - request the IP address for a domain name.

File Transfer Protocol (FTP) - send or receive files.

Hyper Text Transport Protocol (HTTP) - request the retrieval of a web page. The main protocol of the World Wide Web.

Simple Mail Transport Protocol (SMTP) - send electronic mail, either to a relay server or to the ultimate destination.

Post Office Protocol (POP) - request the delivery of incoming electronic mail.

Telnet - interactively log into a remote computer.

Some of these protocols (e.g., DNS, HTTP, POP) are limited to the transfer of information from server to client. But by definition, the client always initiates a transaction (a self-contained exchange of packets) by sending the very first packet to the remote server.

Except for Telnet sessions, most Internet transactions are short lived. Most are over in seconds from the initial service request by the client.

A transaction typically-though not necessarily-coincides with the lifetime of a single TCP connection. In some cases (e.g., DNS) a transaction consists of an exchange of connectionless UDP packets without a TCP connection. To increase efficiency, a closely spaced series of transactions to the same server sometimes "reuses" a single TCP connection. However, the self-contained nature of a transaction implies that the TCP connection could be torn down and reestablished between connections with only a loss in efficiency-no actual data would be lost.

Because it sends the first packet, a client must know the server's IP address in advance. But the reverse is not true. Since every Internet packet includes the IP address of the sender, a server always knows where to respond even if the client's IP address changes from one transaction to the next-though a new TCP connection may have to be established in the case of TCP connection reuse.

Further lessening the need for static IP addressing in a IS-95 packet data system is the inherent mobility provided in the physical layer for both voice and data users. None of the IP address mobility issues discussed here even arise in a IS-95 system unless the user roams to another system.

Portable Computing Has Already Made Dynamic Addressing Commonplace

Portable computing is characterized by intermittent, ad-hoc connectivity to the Internet. Much of the time the user's computer is powered off to conserve batteries or is otherwise "off the net" because no suitable communications are available. Even when connectivity is theoretically available, a user may choose to not use it because of cost or other practical factors (e.g., the inflight telephone services that cost several dollars per minute for connect time.)

At other times, a portable computer user can choose from several ways to connect to the net. For example, a conference or trade show may provide high speed public network connections for its attendees as an alternative to direct long distance calls back to one's company modem bank. A small branch office may subscribe to a local public Internet Service Provider (ISP) for connectivity to reach its home office network, again as an alternative to direct long distance dialing.

The portable user generally must accept a dynamically assigned IP address belonging to the local serving system. Even when dialing into his "home" company's network over the PSTN, he must generally accept a temporary IP address assigned by the terminal server/router.

For these reasons, existing operating systems and applications have already implemented dynamic addressing support. For example, Microsoft Windows 95, arguably the most important PC operating system, includes a TCP/IP stack with support for both DHCP (Dynamic Host Configuration Protocol) and PPP with automatic address assignment. Both schemes allow the serving system to assign a temporary IP address and related information to the portable user for the duration of his association with the serving network. Other popular operating systems such as Linux (UNIX) generally also support DHCP and/or dynamic PPP.

Application protocols have been created specifically to preserve the dynamically addressed, client-only nature of the portable computer user. The best example is the Post Office Protocol, POP. Before POP, email messages were delivered to their ultimate destination by the Simple Mail Transport Protocol, SMTP. As generally implemented, SMTP provides only for the transfer of email from client to server. (A "TURN" command originally defined in SMTP was never widely implemented for security reasons.) Portable computers, however, are generally unable to run full-time SMTP servers for all the reasons given above, so they are unable to receive incoming mail with SMTP. POP was therefore created so that a portable user can pick up his mail from a "post office" machine that runs SMTP on behalf of the user and stores incoming mail until the portable user picks it up with POP.

In sum, the mobile/portable computer user is already able to deal with intermittent connectivity and dynamically assigned IP addresses; there is simply no overriding need for a permanent IP address in a IS-95 packet data service.

An Aside on Security

The claim is sometimes made that fixed IP addresses are needed for security reasons, e.g., so that a company can authenticate the remote user by his IP address. While it is true that some companies do follow such a policy, it is notoriously easy to forge IP source addresses in Internet packets. The long history of Internet break-ins that exploit "trusted" IP addresses (e.g., the BSD rlogin/rsh command mechanisms) shows that it is simply not safe to do so.

It is simply improper to make any security decisions whatsoever based on the IP address of a remote system. Sometimes a plaintext password is required, regardless of remote IP address; while slightly better than simply trusting a given IP address this practice is highly vulnerable to "password sniffing" (eavesdropping), a practice known to be widespread on the Internet.

The best security uses cryptographic user authentication, preferably combined with full end-to-end encryption to thwart eavesdropping on user data. Such systems can confidently accept connections regardless of the remote IP address-dynamic or static.

Dynamic Addressing is Often Preferable To Static Addressing

As discussed above, most portable computer operating systems support dynamic addressing, and this is entirely sufficient to support their client-mode applications. In fact, dynamic addressing is actually preferable to static addressing for such applications because of the suboptimal routing implied by static addressing.

Consider a user of a hypothetical cellular system with a static IP address belonging to his home system. When he roams, normal Internet routing causes every packets addressed to him to pass through his home system and then be forwarded to his serving system. This is true even if those packets originated in or near his serving system, and even if they belong to a transaction initiated by the client.

Making matters worse is the fairly recent practice, for security reasons, of filtering IP packets leaving an ISP on the basis of their source addresses. The intent is to discourage IP source address spoofing of the type used in recent "SYN bombing" attacks on various ISPs. Prior to source address filtering, the Internet ignored the source addresses on the packets it routed, meaning that packets sent by a statically-addressed mobile host could go directly to their destination even if packets to the same mobile host had to be routed through the "home" network that "owns" the mobile host's static address.

The likely result of source address filtering is that all traffic to and from a mobile host with a static IP address will have to pass through the home network that owns the IP address. This is clearly wasteful of Internet resources, considering that mobile-initiated network transactions can instead use a temporary IP address assigned by the serving system that would eliminate any non-optimal routing.

Although it is true that the wired Internet is generally much faster than the IS-95 traffic channel, making the wasteful use of the former less of an issue, reliability and delay concerns still argue in favor of the more efficient approach. In other words, even if the extra load imposed on the Internet by inefficient routing is negligible and costs the carriers nothing, it nonetheless increases the delay and decreases the reliability of the overall service as seen by the customer, with no corresponding benefit.

Some Applications Do Need Static Addressing

Although the vast majority of existing portable computer applications - perhaps even all of them - do just fine with dynamic IP addressing, Qualcomm agrees that new applications may appear that require fixed IP addresses for some mobile and portable computers as they move between IS-95 systems.

One class of such applications involve the mobile station as a server. An example would be the rapid notification of incoming electronic mail without requiring the mobile user to continually poll his POP server. Note that the notification need only cause the mobile station to initiate a conventional POP session as a client. For efficiency, the POP session could use a temporary IP address rather than the static address used to receive the notification.

Another class involves mobile networks, i.e., several TCP/IP-speaking computers connected to a local area network, with this network connected to the Internet via a service like IS-95 packet data. The main problem with this configuration occurs when the mobile computers need to speak to each other over the LAN; since this implies that there is at least one server on the LAN, it must have an IP address that the other computers can know.

There are several possible approaches to this situation.

One approach is to assign a fixed subnet to the mobile network and to have the serving carrier participate in normal Internet dynamic routing by advertising this subnet to the Internet whenever it is connected to that carrier. Though this approach is perhaps the simplest in concept, it is unlikely to work in practice. The size of the routing tables in the Internet "core" have grown enormously with the growth of the Internet and already many Internet carriers have adopted policies to not route subnetwork address blocks smaller than a certain size. The minimum size is typically 16,384 hosts-far larger than the typical mobile subnet is likely to be.

Another approach is to implement two virtual interfaces on each computer attached to the mobile LAN. One interface has a fixed IP address and is used only to communicate with the other computers on the LAN; the other interface has a dynamic address and is used to communicate with the external Internet through the IS-95 packet data system. In this situation, the IS-95 system would have to assign more than one dynamic address, one for each computer on the mobile LAN that needs external Internet connectivity.

A third approach is to designate one of the computers as a Mobile IP Foreign Agent and to assign permanent IP addresses to the other computers. This approach has the advantage of not requiring any changes to the other computers. It has the disadvantage of forcing the use of Mobile IP for off-LAN traffic by the other computers even when it is not needed.

For Those Applications Needing Static Addressing, IETF Mobile IP Is The Better Approach

CDPD provides the customer with a fixed, carrier-provided IP address that can be used with any participating CDPD carrier. This solves the address mobility problem of roaming between CDPD systems, but it does not solve the more general (and ultimately more important) problem of "roaming" between CDPD and non-CDPD systems, including wired networks.

In contrast, the IETF Mobile IP approach is not specific to any particular subnetwork technology. Mobile IP users can roam between Ethernets, CDPD networks, IS-95 packet data networks, dialup modem links-indeed, any subnetwork that can provide Internet connectivity with a temporarily assigned IP address belonging to that subnet.

For those users who need static addressing, the ability to move transparently between a wired (e.g., Ethernet) and wireless (e.g., IS-95) subnetwork is likely to be extremely important. A good example is a laptop computer connected to an office Ethernet when its owner is in his office, and to an IS-95 packet-capable phone when its owner travels. In this situation, Mobile IP allows the user to assign a static address from a subnetwork of his own choosing, which would most likely be his office Ethernet. He could then carry that address with him as he travels.

This is not possible with CDPD mobility alone. Given the low cost and high speed of Ethernet as compared to CDPD (or IS-95, for that matter), it seems unlikely that any mobility scheme that doesn't support "roaming" to one's office Ethernet would be considered satisfactory. This implies that any user who truly requires static IP addressing will be forced to implement Mobile IP. This would render superfluous any CDPD-style mobility provided by the carrier.

Client Implementation Issues

The discussion of Mobile IP has suggested the simultaneous use of static and dynamic IP addresses by the same mobile computer. The static address would be used by servers running on the mobile computer to accept and respond to incoming requests, while the more efficient dynamic address would be used by clients initiating transactions to other servers.

This actually seems fairly straightforward to implement in existing TCP/IP-capable operating systems, including Windows 95 (though that system rarely supports Internet servers that need static IP addresses). The TCP/IP stack in that operating system seems to be modeled after that in BSD Unix and its many variations, including support for multiple subnetwork interfaces. Two separate network interfaces could therefore be implemented to an IS-95 packet data unit. One would be the "real" interface, bearing whatever temporary IP address has been assigned to it by the serving system. The other is a "virtual" interface bearing the static IP address belonging to the user's Mobile IP home system. Servers would accept incoming packets addressed to either the temporary or the static IP address, but since the temporary address is unlikely to be known by prospective remote clients only the static IP address is likely to be actually used for this purpose.

The IP routing table is configured to steer all outbound packets by default to the dynamic interface. This causes any local clients to automatically adopt the current dynamic IP address, meaning that traffic between these clients and remote hosts would be routed optimally over the Internet. If the dynamic IP address were to be changed by the serving system (e.g., if an intersystem handoff were to occur) then any pending client transactions would admittedly fail, but this seems like a rare occurrence; applications unwilling to tolerate this risk could instead specify the static local IP address at the expense of increased Internet traffic and propagation delays.

As an aside, the routing "subnet mask" associated with the static interface would cause clients connecting to remote hosts on the home network to use the static IP address by default. This is reasonable, since the indirect routing normally associated with Mobile IP packet forwarding is not present when the remote host is on the home network. It is also likely that the long-lived transactions most vulnerable to being terminated by an intersystem handoff will be to hosts on one's home network (e.g., consider an idle Telnet session to one's office computer). The use of the static interface in this case would allow the session to be kept open across IS-95 system boundaries without inefficient Internet usage.


Billing and mobility are separate issues in IS-95, because every IS-95 mobile (including a data capable mobile), unlike a CDPD terminal, has a unique MIN and ESN to identify it to a serving system. When a basic packet data user roams into a new serving system, the same standard IS-95 mechanisms originally designed for voice calls can identify the roamer, contact its home system for account verification, and optionally authenticate the mobile station. The serving system can then record usage (airtime, plus possibly packet and/or byte counts), generate a billing record from this information and forward it to the home system, again using the same mechanisms already defined and in place for roaming voice calls.