Skip to main content

IPv4 with Adaptive Address Space

Document Type Replaced Internet-Draft (individual)
Expired & archived
Authors Abraham Chen , Ramamurthy Ati
Last updated 2016-11-13
Replaced by draft-chen-ati-with-adaptive-address-space, draft-chen-ati-adaptive-ipv4-address-space
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Replaced by draft-chen-ati-with-adaptive-address-space, draft-chen-ati-adaptive-ipv4-address-space
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), discusses the IPv4 public address pool expansion and the Internet system architecture enhancement aspects. It was originated by a study called ExIP (Extended IPv4) analyzing the use of the first available octet (eight bits) in the reserved private network pools (10/8, 172.16/12 and 192.168/16) to achieve a moderate address space expansion factor of 256 by each, while maintaining their familiar operation characteristics. Along the way, a parallel yet similar effort, called EnIP (Enhanced IPv4), was discovered. EnIP fully utilizes the same private network pools to increase the address space by a factor of 17.1M with end-to-end connectivity. EzIP is a superset that proposes one unified format for not only encompassing the considerations of both, but also identifying additional capabilities and flexibilities. For example, EzIP may expand an IPv4 address at least by a factor of 256 to as high as 256M without affecting the existing IPv4 public address assignments, while still keeping intact the current private networks for the 256M case if desired. The EzIP is in full conformance with the IPv4 protocol, and supports not only both categories of connectivity, but also their interoperability. The traditional Internet traffic and the IoT operations may coexist simultaneously without perturbing their existing setups, while offering end-users the freedom to choose one or the other. If the IPv4 public pool were reorganized, the assignable pool could be multiplied by 512M or even up to 2B times with end-to-end connectivity. EzIP may be deployed as a firmware enhancement to the Internet edge routers or private network gateways wherever needed, or simply installed as an inline adjunct module between the two, enabling a seamless introduction. The 256M case establishes a spherical layer of routers providing a complete interconnection between the Internet and end-users. This configuration enables the entire current Internet and private networks characteristics to remain intact. These proposed interim facilities would afford IPv6 more time to orderly reach the maturity and the availability levels required for delivering a long-term general service.


Abraham Chen
Ramamurthy Ati

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)