RFC 1674

RFC 1674: A Cellular Industry View of IPng 📱🎀

okay bestie, so this is RFC 1674 💖, written by Mark S. Taylor (the header just says M. Taylor) from the CDPD Consortium. It's Informational and dated August 1994 🦋. The header is under Network Working Group 🌸, and it doesn't list anything it obsoletes or updates, so nothing gets replaced here 💅.

Status of this Memo ✨

This memo gives info to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🫶.

Abstract 🌈

This memo is a response to RFC 1550, "IP: Next Generation (IPng) White Paper Solicitation" 📝. Everything in this paper is meant as input to the technical discussions within IETF 🧚. It is NOT an endorsement or commitment from the cellular industry, the Cellular Digital Packet Data (CDPD) consortium of service providers, or any of its constituent companies 🙈.

Introduction 🎀

This is a draft of the requirements for IPng, as imagined by reps of the Cellular Digital Packet Data (CDPD) consortium of service providers 💅. They're the leading providers for this nascent tech, which will give mobility to native mainstream connectionless network layer-based apps, so it's their goal to support whatever form IPng takes ✨. However, there are several requirements they feel IPng must meet 👑.

Mobility 🦋

Since they'll be offering mobile services, their main requirement is that IPng not inhibit their support of mobility 🚀. IPng must not impede devices from being able to operate anywhere anytime 🌍. Apps on these mobile devices must look and feel the same to the user no matter where they are 💖. NPDUs should be self-contained and must not disallow the redirection built into their mobility solution. In other words, IPng must be connectionless 🫶.

Also, since IPng gives a chance for design upgrades beyond IPv4, they propose that native support for mobility be treated as an explicit IPng requirement 🔥. Local area and wide area wireless tech opens up new chances for both TCP/IP and the Internet 🌸. Mobility works no matter if the data link is wired or wireless, but the fast rollout of wireless tech really pumps up the need for topological flexibility 💜.

As a side effect of mobility, "occasionally-connected hosts" matter way more 🙈. Being able to handle occasionally-connected hosts in IPng is a requirement 😭.

Scale 🌈

For scale, they picture some 20 to 40 million users by the year 2007 📈. A "user" can be anything from a vending machine to a "road warrior" 🚗. Those numbers are for North America alone 🇺🇸. Worldwide, they expect IPng should be able to support billions of "users" 🌏. And because the sparseness of network address assignments (needed for subnetting, etc.) is a thing, IPng should support at least tens or hundreds of billions of addresses 🤯.

Addressing 🍓

For addressing, they'd expect addresses to be hierarchical 🌳. A node with multiple links should require only a single address, although having more than one address should also be possible 🎀. The mapping of names to addresses should be independent of location, because an address should be an address, not a route 🗺️. Variable-length addressing is also required to keep the protocol (IPng) extensible for later 🧩. Address assignment should be distributed, not centralized like it is now 💅.

Security 🔐

IPng should also support security mechanisms that will matter more and more on the proverbial "information highway" for commercial users 🛣️. Security services that may optionally be expected from a Layer 3 entity like IPng include:

• peer entity authentication 🪪
• data confidentiality 🤫
• traffic flow confidentiality 🌊
• data integrity 🧷
• location confidentiality 📍

Accounting 💜

The ability to do accounting at Layer 3 is a requirement 🧾. The CDPD specification can serve as a model for the kind of accounting services they need 📚.

Route Selection 🗺️

In the voice comms arena, "equal access" and choice of an "interexchange carrier (IXC)" are issues that must be addressed 📞. Similar requirements for data may also exist 👀.

Source- and policy-based routing for inter-domain traffic can address this requirement 🛤️. IPng must allow the selection of at least the first transient network service provider based on the source host 🙌.

Data Efficiency 🍃

The bandwidth of wide area wireless networks is a precious resource, so its use must be optimized 💎. IPng must allow optimal use of the underlying Layer 2 medium 🎯. Layer 3 Protocol Control Information (PCI) should be as condensed as possible 🪶. The protocol should be optimized for data efficiency ⚡.

Packet prioritization must also be supported by IPng to optimize the use of low speed networks 🐢. This requirement includes both class and grade of service definitions for flexibility 🎛️.

Transition 🦢

The final requirement for IPng is that it must interoperate with IP for the foreseeable future 🔮. Bridging mechanisms must be supported, and a strategy for transitioning from IPv4 to IPng must be defined 🌉. Use of options fields, etc., is one mechanism to support the requirement for IPng protocols to handle IP addresses and headers 🧳.

Security Considerations 💀

See section on Security. 🔗

Author's Address 🎀

• Mark S. Taylor 💖
• Director of System Development
• McCaw Cellular Communications, Inc.
• Wireless Data Division
• 10230 NE Points Drive
• Kirkland, WA 98033-7869 USA
• EMail: mark.s.taylor@airdata.com 📧