rfc1385.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 955 行 · 第 1/3 页

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 [e-mail].

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:

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

   2) EIP is flexible to accommodate most routing and addressing
      schemes, such as those proposed in Nimrod [8], Pip [7], NSAP [9]
      and CityCodes [10]. EIP also allows new fields such as Handling
      Directive [7] or CI [11] to be added.

   3) EIP can substantially reduce the amount of modifications to
      current systems and greatly ease the difficulties in transition.
      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.

   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 is shown in Figure 1 and the contents of the
   header follows.















Wang                                                            [Page 3]

RFC 1385                          EIP                      November 1992


       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 Number                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Destination Host Number                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     EIP ID    | EIP Ext Length|   EIP Extension (variable)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: EIP Header Format

   Version:  4 bits

     The Version field is identical to that of IP. This field is set
     purely for compatibility with IP hosts. It is not checked by EIP
     hosts.

   IHL:  4 bits

     Internet Header Length is identical to that of IP. IHL is set to
     the length of EIP header purely for compatibility with IP. This
     field is not checked by EIP hosts.  see below the EIP Extension
     Length field for more details)

   Type of Service:  8 bits

     The ToS field is identical to that of IP.

   Total Length:  16 bits

     The Total Length field is identical to that of IP.

   Identification:  16 bits

     The Identification field is identical to that of IP.

   Flags:  3 bits

     The Flags field is identical to that of IP.





Wang                                                            [Page 4]

RFC 1385                          EIP                      November 1992


   Fragment Offset:  13 bits

     The Fragment Offset field is identical to that of IP.

   Time to Live:  8 bits

     The Time to Live field is identical to that of IP.

   Protocol:  8 bits

     The Protocol field is identical to that of IP.

   Header Checksum:  16 bits

     The Header Checksum field is identical to that of IP.

   Source Host Number:  32 bits

     The Source Host Number field is used for identifying the
     source host but is unique only within the source network
     (the equivalent of the host portion of the source IP address).

   Destination Host Number:  32 bits

     The Destination Host Number field is used for identifying the
     destination host but is unique only within the destination network
     (the equivalent of the host portion of the destination IP address).

   EIP ID: 8 bits

     The EIP ID field equals to 0x8A. The EIP ID value is chosen
     in such a way that, to IP hosts and IP routers, an EIP appears
     to be an IP packet with a new IP option of following parameters:

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

       Option:  Type=TBD

   EIP Extension Length: 8 bits

        The EIP Extension Length field indicates the total length
        of the EIP ID field, EIP Extension Length field and the
        EIP Extension field in octets. The maximum length that the
        IHL field above can specify is 60 bytes, which is considered
        too short in future. EIP hosts actually use the EIP Extension
        Length field to calculate the total header length:



Wang                                                            [Page 5]

RFC 1385                          EIP                      November 1992


     The total header length = EIP Extension Length + 20.

     The maximum header length of an EIP packet is then 276 bytes.

   EIP Extension: variable

     The EIP Extension field holds the Source Network Number,
     Destination Network Number and other fields. The format
     of the Extension field is not specified here. In its simplest
     form, it can be used to hold two fixed size fields as the
     Source Network Number and Destination Network Number as the
     extension to the addressing space. Since the Extension
     field is variable in length, it can accommodate almost any
     routing and addressing schemes. For example, the Extension
     field can be used to hold "Routing Directive" etc specified
     in Pip [7] or "Endpoint IDs" suggested in Nimrod [8], or the
     "CityCode" [10]. It can also hold other fields such as the
     "Handling Directive" [7] or "Connectionless ID" [11].

   EIP achieves maximum backward compatibility with IP by making the
   extended space appear to be an IP option to the IP hosts and routers.

   When an IP host receives an EIP packets, the EIP Extension field is
   safely ignored as it appears to the IP hosts as an new, therefore an
   unknown, IP option.  As a result, there is no need for translation
   for in-coming EIP packets destined to IP hosts and there is also no
   need for subnet routers to be upgraded during the transition period
   see later section for more details).

   EIP hosts or routers can, however, determine whether a packet is an
   IP packet or an EIP packet by examining the EIP ID field, whose
   position is fixed in the header.