Internet DRAFT - draft-wang-extended-ip

draft-wang-extended-ip



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 12:05:55 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 09 Dec 1992 04:36:00 GMT
ETag: "3dde63-5b5a-2b2577b0"
Accept-Ranges: bytes
Content-Length: 23386
Connection: close
Content-Type: text/plain







Network Working Group                                     Zheng Wang
Internet-Draft                             University College London
                                                           June 1992


                  EIP: The Extended Internet Protocol
          a long-term solution to Internet address exhaustion


Status of this Memo

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

Summary

   In this paper, we present the Extended Internet Protocol (EIP) which
   provides a long-term solution to Internet address exhaustion. What we
   propose here is not a new addressing and routing scheme, but a
   framework in which any addressing and routing schemes can be
   accommodated. The goal of EIP is to provide maximum flexibility to
   accommodate any addressing and routing schemes yet to maintain
   maximum backward compatibility with current IP. It 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.  Distribution of this memo is unlimited.

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 in not too distant future the 32-bit IP address
   space will be exhausted altogether.  The total number of IP networks
   will grow to a point where routing algorithms will not be able to
   perform routing based a flat network number.



Expires: 12/1992                                                [Page 1]





Internet-Draft                                                 June 1992


   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.

   There are a number of possible choices for a long-term solution. A
   radical approach to the problem is to change the current IP header
   format completely. Three proposals have been put forward in which the
   current IP is replaced by either a complete new "IP", Nimrod [8] or
   Pip [7] or by an existing connectionless protocol CLNP [6]. 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 (eg. routing, routers, hosts, ARP, RARP, ICMP, TCP,
   UDP, DNS, FTP).  Migrating to a new "IP" in effect creates a new
   "Internet".  The development and deployment of such a new "Internet"
   would take a very large amount of time and effort. In particular, to
   ensure the interoperability between the old and new systems during
   the transition period, almost all upgraded systems have to run both
   the new and old version 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 pro-
        vide address translation service for IP packets across the boun-
        daries. Note that the translation has to be done on the out-
        going 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.



Expires: 12/1992                                                [Page 2]





Internet-Draft                                                 June 1992


        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 present the Extended Internet Protocol (EIP) which
   provides a long-term solution to the Internet address exhaustion.
   What we propose here is not a new addressing and routing scheme, but
   a framework in which any addressing and routing schemes, such as
   those proposed in Nimrod [8], Pip [7], NSAP [9] and CityCodes [10],
   can be accommodated.  The goal of EIP is to provide maximum flexibil-
   ity to accommodate any addressing and routing schemes yet to main-
   tains maximum backward compatibility with current IP. It therefore
   can substantially reduce the amount of modifications to current sys-
   tems and greatly ease the difficulties in transition.

   EIP has a number of very desirable features:

   1)   EIP allows the Internet to have unlimited number of network
        numbers and over 10**9 hosts in each network.

   2)   EIP can accommodate different addressing and routing architec-
        tures such as fixed or variable length addresses, multi-level
        addressing, hierarchical routing and policy routing. It can be
        used as a vehicle for any new addressing and routing architec-
        tures.

   3)   EIP can substantially reduce the amount of modifications needed
        to the current Internet systems. In particular, it does not
        require the upgraded hosts and subnet routers to run two set of
        protocols in parallel.

   4)   EIP requires no changes to all assigned IP addresses and subnet
        structures in local are networks.  and requires no modifications
        to ARP/RARP, ICMP, TCP/UDP checksum.

   5)   EIP can greatly ease the difficulties of transition.  During the
        transition period, no upgrade is required to the subnet routers.
        EIP hosts maintain full compatibility with IP hosts within the
        same network, even after the transition period.  During the
        transition period, IP hosts can communicate with any hosts in
        other networks via a simple translation service.



Expires: 12/1992                                                [Page 3]





Internet-Draft                                                 June 1992


   In the rest of the paper, IP refers to the current Internet Protocol
   and EIP refers to the Extended Internet Protocol (EIP is pronounced
   as "ape" - a step forward in the evolution:-).

Extended Internet Protocol (EIP)

   The EIP header format does not differ very much from the IP header
   format (see Figure 1).  It can be devided into three parts: the
   minimal IP header, the Extension field and the IP options. The
   "Source Address" and "Destination Address" fields in the IP header is
   called the "Source Host ID" and "Destination Host ID" here in the EIP
   header and they are used in EIP for identifying the the source and
   the destination hosts only. The Source Network ID and the Destination
   Network ID, which are used for identifying the source and destination
   networks in EIP, are encoded in the Extension field.  Other fields in
   the EIP header are identical to the corresponding fields in the IP
   header.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version|  IHL  |Type of Service|          Total Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Identification        |Flags|      Fragment Offset    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Time to Live |    Protocol   |         Header Checksum       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Host ID                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination Host ID                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Extension               | Other Options | Padding |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: EIP Header Format

   The Extension field is variable in length and its format is shown in
   Figure 2.

   +--------+--------+--------//---------+----------//------------+
   |10001010| length | Source Network ID | Destination Network ID |
   +--------+--------+--------//---------+----------//------------+

             Figure 2:  The Format of the Extension Field

   The most novel aspects of EIP lie in the Extension field.

   First, the Extension field is structured in such a way that, to IP



Expires: 12/1992                                                [Page 4]





Internet-Draft                                                 June 1992


   hosts and IP routers, it appears to be simply a new IP option with
   the following parameters:

         COPY CLASS NUMBER LENGTH DESCRIPTION
         ---- ----- ------ ------ -----------
           1    0     10     var

         Option:  Type=138

   This feature of the Extension field ensures:

   1)   that when an IP host receives an EIP packets, the EIP Extension
        field is safely ignored as it appears to the IP host an new,
        therefore an unknown, IP option.

   2)   that, as a result of 1), there is no need for translation for
        in-coming EIP packets destined to IP hosts.

   3)   that, as a result of 1), there is no need for subnet routers to
        be upgraded during the transition period (see later section for
        more details).

   4)   that an EIP host or router can determine easily whether the
        field that follows the minmial IP header is an Extension field
        of an EIP packet or an IP option of an IP packet.


   Second, the Extension field is only used for communications between
   different networks.  For communications within the same network,
   there is no need to include the Network IDs in the packet. Therefore,
   the Extension field which contains the Source Network ID and the Des-
   tination Network ID is included in the packet only when the packet is
   destined to a remote network. In other words, in EIP, when the Source
   Network ID and the Destination Network ID are omitted in the packet
   header, it is assumed, by default, that they are both equal to the
   local network.  This feature of the Extension field, together with
   the above feature, ensures complete compatibility between IP and EIP
   within the same network.  IP hosts can communicate with EIP hosts in
   the same network without any changes.  In fact, the IP header and the
   EIP header are identical when they are used within one network.  The
   IP header can be viewed as a special case of the EIP header, ie. when
   communications take place within one network.

   Thrid, the Extension field, when present in the packets, always the
   first field following the minimal IP header. The position of the
   Extension field in the EIP header is therefore fixed, so that the
   Source Network ID and the Destination Network ID can be extracted and
   processed efficiently.



Expires: 12/1992                                                [Page 5]





Internet-Draft                                                 June 1992


   Lastly, the semantics of the Network IDs encoded in the Extension
   field are determined by the addressing scheme used and is not speci-
   fied here. Since the Extension field is variable in length, the Net-
   work IDs are flexible to accommodate any addressing schemes.  The
   Network ID can be either a fixed length node IDs, or a fixed length
   path ID, or a variable length backbone-oriented hierarchical address,
   or a variable length policy source route, or a routing directive.

   A full EIP address consists of a Network ID and a Host.  However,
   Network IDs and Host IDs are always manipulated separately. Using the
   IP address field as the Host ID in EIP has its advantages:

   1)   It maintains full compatibility between IP hosts and EIP hosts
        for communications within one network. Any IP hosts can communi-
        cate with any EIP hosts in the same network without any modifi-
        cations or translation.

   2)   It allows the IP subnet routers to route EIP packet by treating
        the Host ID as the IP address during the transition period,
        therefore the subnet routers are not required to be updated
        along the border routers.

   3)   It allows ARP/RARP to work with both EIP and IP hosts without
        any modifications.

   4)   It allows the translation at the border routers much easier.
        During the transition period when the IP addresses are still
        unique, the network portion of the IP addresses can be directly
        extracted and mapped to EIP Network IDs.


Modifications to IP Systems.

   In this section, we outline the modifications to the IP systems that
   are needed for transition to EIP. Because of the similarity between
   the EIP and IP, the amount of modifications needed to current systems
   are substantially reduced.

   1)   Network Numbers: Each network has to be assigned a new EIP Net-
        work ID based on the addressing scheme used. The mapping between
        the IP network numbers and the EIP Network IDs can be used for
        translation service (see below).

   2)   Host Numbers: There is no need for assigning EIP Host IDs.  All
        existing hosts can use their current IP addresses as their EIP
        Host IDs. New machines may be allocated any number from the 32-
        bit Host ID space since the structure posed on IP addressing is
        no longer necessary. However, during the transition, allocation



Expires: 12/1992                                                [Page 6]





Internet-Draft                                                 June 1992


        of EIP Host IDs should still follow the IP addressing rule, so
        that the EIP Host IDs are still globally unique and can still be
        interpreted as IP addresses.  This will allow a more gradual
        transition to EIP (see below).

   3)   Translation Service: During the transition period when the EIP
        Host IDs are still unique, an address translation service can be
        provided to IP hosts that need communicate with hosts in other
        networks cross the upgraded backbone networks.  The translation
        service can be provided by the border routers.  When a border
        router receives an IP packet, it obtains the Destination Network
        ID by looking up in the mapping table between IP network numbers
        and EIP Network IDs. The border router then adds the Extension
        field with the Source and Destination Network IDs into the
        packet, and forwards to the backbone networks. It is only neces-
        sary to translate the out-going IP packets to the EIP packets.
        There is no need to translate the EIP packets back to IP packets
        even when they are destined to IP hosts.  This is because that
        the Extension field in the EIP packets appears to IP hosts just
        an unknown IP option and is ignored by the IP hosts during the
        processing.

   4)   Border Routers: The new EIP Extension has to be implemented and
        routing has to be done based on the Network ID in the EIP Exten-
        sion field. The border routers may have to provide the transla-
        tion service for out-going IP packets during the transition
        period.

   5)   Subnet Routers: No modifications are required during the transi-
        tion period when EIP Host IDs (which equals to the IP addresses)
        are still globally unique. The subnet routing is carried out
        based on the EIP Host IDs  and when the EIP Host IDs are still
        unique, subnet routers can determine, by treating the EIP Host
        ID as the IP addresses, whether a packet is destined to remote
        networks or not and forward correctly. The Extension field in
        the EIP packets also appear to the IP subnet routers an unknown
        IP option and is ignored in the processing. However, subnet
        routers eventually have to implement the EIP Extension and carry
        out routing based on Network IDs when EIP Host IDs are no longer
        globally unique.

   6)   Hosts: The EIP Extension has to be implemented.  routing has to
        be done based on the Network ID in the EIP Extension field, and
        also based on the Host ID and subnet mask if subnetting is used.
        IP hosts may communication with any hosts within the same net-
        work at any time. During the transition period when the EIP Host
        IDs are still unique, IP hosts can communicate with any hosts in
        other network via the translation service.



Expires: 12/1992                                                [Page 7]





Internet-Draft                                                 June 1992


   7)   DNS: A new resource record (RR) type "N" has to be added for EIP
        Network IDs. The RR type "A", currently used for IP addresses,
        can still be used for EIP Host IDs. RR type "N" entries have to
        be added and RR type "PTR" to be updated.  All other entries
        remain unchanged.

   8)   ARP/RARP: No modifications are required. The ARP and RARP are
        used for mapping between EIP Host IDs and physical addresses.

   9)   ICMP: No modifications are required.

   10)  TCP/UDP Checksum: No modifications are required. The pseudo
        header includes the EIP Source and Destination IDs instead of
        the source and destination IP addresses.

   11)  FTP: No modifications are required during the transition period
        when the IP hosts can still communicate with hosts in other net-
        works via the translation service. After the transition period,
        however, the "DATA Port (Port)" command has to be modified to
        pass the port number only and ignore the IP address.  A new FTP
        command may be created to pass both the port number and the EIP
        address to allow a third party to be involved in the file
        transfer.


Transition to EIP

   In this section, we outline a plan for transition to EIP.

   EIP can greatly reduce the complexity of transition. In particular,
   there is no need for the updated hosts and subnet routers to run two
   protocols in parallel in order to achieve interoperability between
   old and new systems.  During the transition, IP hosts can still com-
   municate with any machines in the same network without any changes.
   When the EIP Host IDs (ie. the 32-bit IP addresses) are still glo-
   bally unique, IP hosts can contact hosts in other networks via trans-
   lation service provided in the border routers.

   The transition goes as follows:


   Phase 0:
        a) Choose an addressing and routing scheme for the Internet.
        b) Implement the routing protocol.
        c) Assign new Network IDs to existing networks.

   Phase 1:
        a) Update all backbone routers and border routers.



Expires: 12/1992                                                [Page 8]





Internet-Draft                                                 June 1992


        b) Update DNS servers.
        c) Start translation service.

   Phase 2:
        a) Update first the key hosts such as mail servers, DNS servers,
        FTP servers and central machines.
        b) Update gradually the rest of the hosts.

   Phase 3
        a) Update subnet routers
        b) Withdraw the translation service.

   The translation service can be provided as long as the Host IDs (ie.
   the 32-bit IP address) are still globally unique. When the IP address
   space is exhausted, the translation service will be withdrawn and the
   remaining IP hosts can only communicate with hosts within the the
   same network. At the same time, networks can use any numbers in the
   32-bit space for addressing their hosts.

References

   [1]  J. Noel Chiappa, "The IP Addressing Issue", Internet Draft,
        October 1990.

   [2]  D. Clark, L. Chapin, V. Cerf, R. Braden, "Towards the Future
        Architecture", RFC 1287, SRI International, December 1991.

   [3]  F. Solensky, F. Kastenholz, "A Revision to IP Address
        Classifications", Internet Draft, March 1992.

   [4]  V. Fuller, T. Li, J. Yu, K. Varadhan, "Supernetting:
        an Address Assignment and Aggregation Strategy", Internet Draft,
        March 1992

   [5]  Z. Wang, J. Crowcroft, "A Two-Tier Address Structure for
        the Internet: a solution to the problem of address space
        exhaustion", RFC-1335, May 1992.

   [6]  R. Callon, "TCP and UDP with Bigger Addresses (TUBA),
        a Simple Porposal for Internet Addressing and Routing",
        RFC-1347, June 1992.

   [7]  P. Tsuchiya, "Pip: The 'P' Internet Protocol", Internet
        Draft, May 1992

   [8]  J. Noel Chiappa "A New IP Routing and Addressing Architecture",
        Internet Draft, 1992.




Expires: 12/1992                                                [Page 9]





Internet-Draft                                                 June 1992


   [9]  R. Colella, E. Gardner, R. Callon, "Guidelines for OSI NSAP
        Allocation in the Internet" RFC 1237, July 1991.

   [10] S. Deering, "City Codes: An Alternative Scheme for OSI
        NSAP Allocation in the Internet", draft, Jan. 1992.

Authors' Address:

   Zheng Wang
   Dept of Computer Science
   University College London
   London WC1E 6BT, UK

   z.wang@cs.ucl.ac.uk





































Expires: 12/1992                                               [Page 10]