EIP: The Extended Internet Protocol
RFC 1385

Document Type RFC - Historic (November 1992; No errata)
Obsoleted by RFC 6814
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1385 (Historic)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                            Z. Wang
Request for Comments: 1385                     University College London
                                                           November 1992

                  EIP: The Extended Internet Protocol
           A Framework for Maintaining Backward Compatibility

Status of this Memo

   This memo provides information for the Internet community. It does
   not specify an Internet standard. Distribution of this memo is
   unlimited.

Summary

   The Extended Internet Protocol (EIP) provides a framework for solving
   the problem of address space exhaustion with a new addressing and
   routing scheme, yet maintaining maximum backward compatibility with
   current IP. EIP can substantially reduce the amount of modifications
   needed to the current Internet systems and greatly ease the
   difficulties of transition. This is an "idea" paper and discussion is
   strongly encouraged on Big-Internet@munnari.oz.au.

Introduction

   The Internet faces two serious scaling problems: address exhaustion
   and routing explosion [1-2]. The Internet will run out of Class B
   numbers soon and the 32-bit IP address space will be exhausted
   altogether in a few years time.  The total number of IP networks will
   also grow to a point where routing algorithms will not be able to
   perform routing based a flat network number.

   A number of short-term solutions have been proposed recently which
   attempt to make more efficient use of the the remaining address space
   and to ease the immediate difficulties [3-5].  However, it is
   important that a long term solution be developed and deployed before
   the 32-bit address space runs out.

   An obvious approach to this problem is to replace the current IP with
   a new internet protocol that has no backward compatibility with the
   current IP. A number of proposals have been put forward: Pip[7],
   Nimrod [8], TUBA [6] and SIP [14].  However, as IP is really the
   cornerstone of the current Internet, replacing it with a new "IP"
   requires fundamental changes to many aspects of the Internet system
   (e.g., routing, routers, hosts, ARP, RARP, ICMP, TCP, UDP, DNS, FTP).

   Migrating to a new "IP" in effect creates a new "Internet".  The

Wang                                                            [Page 1]
RFC 1385                          EIP                      November 1992

   development and deployment of such a new "Internet" would take a very
   large amount of time and effort. In particular, in order to maintain
   interoperability between the old and new systems during the
   transition period, almost all upgraded systems have to run both the
   new and old versions in parallel and also have to determine which
   version to use depending on whether the other side is upgraded or
   not.

   Let us now have a look at the detailed changes that will be required
   to replace the current IP with a completely new "IP" and to maintain
   the interoperability between the new and the old systems.

   1) Border Routers: Border routers have to be upgraded and to provide
      address translation service for IP packets across the boundaries.
      Note that the translation has to be done on the outgoing IP
      packets as well as the in-coming packets to IP hosts.

   2) Subnet Routers: Subnet Routers have to be upgraded and have to
      deal with both the new and the old packet formats.

   3) Hosts: Hosts have to be upgraded and run both the new and the
      old protocols in parallel. Upgraded hosts also have to determine
      whether the other side is upgraded or not in order to choose the
      correct protocol to use.

   4) DNS: The DNS has to be modified to provide mapping for domain
      names and new addresses.

   5) ARP/RARP: ARP/RARP have to be modified, and upgraded hosts and
      routers have to deal with both the old and new ARP/RARP packets.

   6) ICMP: ICMP has to be modified, and the upgraded routers have to
      be able to generate both both old and new ICMP packets.  However,
      it may be impossible for a backbone router to determine
      whether the packet comes from an upgraded host or an IP host but
      translated by the border router.

   7) TCP/UDP Checksum: The pseudo headers may have to be modified to
      use the new addresses.

   8) FTP: The DATA PORT (PORT) command has to be changed to pass new
      addresses.

   In this paper, we argue that an evolutionary approach can extend the
   addressing space yet maintain backward compatibility.  The Extended
   Internet Protocol (EIP) we present here can be used as a framework by
   which a new routing and addressing scheme may solve the problem of
   address exhaustion yet maintain maximum backward compatibility to

Wang                                                            [Page 2]
RFC 1385                          EIP                      November 1992

   current IP.

   EIP has a number of very desirable features:
Show full document text