home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1300s / rfc1385.txt < prev    next >
Text File  |  1992-11-10  |  39KB  |  955 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                            Z. Wang
  8. Request for Comments: 1385                     University College London
  9.                                                            November 1992
  10.  
  11.  
  12.                   EIP: The Extended Internet Protocol
  13.            A Framework for Maintaining Backward Compatibility
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community. It does
  18.    not specify an Internet standard. Distribution of this memo is
  19.    unlimited.
  20.  
  21. Summary
  22.  
  23.    The Extended Internet Protocol (EIP) provides a framework for solving
  24.    the problem of address space exhaustion with a new addressing and
  25.    routing scheme, yet maintaining maximum backward compatibility with
  26.    current IP. EIP can substantially reduce the amount of modifications
  27.    needed to the current Internet systems and greatly ease the
  28.    difficulties of transition. This is an "idea" paper and discussion is
  29.    strongly encouraged on Big-Internet@munnari.oz.au.
  30.  
  31. Introduction
  32.  
  33.    The Internet faces two serious scaling problems: address exhaustion
  34.    and routing explosion [1-2]. The Internet will run out of Class B
  35.    numbers soon and the 32-bit IP address space will be exhausted
  36.    altogether in a few years time.  The total number of IP networks will
  37.    also grow to a point where routing algorithms will not be able to
  38.    perform routing based a flat network number.
  39.  
  40.    A number of short-term solutions have been proposed recently which
  41.    attempt to make more efficient use of the the remaining address space
  42.    and to ease the immediate difficulties [3-5].  However, it is
  43.    important that a long term solution be developed and deployed before
  44.    the 32-bit address space runs out.
  45.  
  46.    An obvious approach to this problem is to replace the current IP with
  47.    a new internet protocol that has no backward compatibility with the
  48.    current IP. A number of proposals have been put forward: Pip[7],
  49.    Nimrod [8], TUBA [6] and SIP [14].  However, as IP is really the
  50.    cornerstone of the current Internet, replacing it with a new "IP"
  51.    requires fundamental changes to many aspects of the Internet system
  52.    (e.g., routing, routers, hosts, ARP, RARP, ICMP, TCP, UDP, DNS, FTP).
  53.  
  54.    Migrating to a new "IP" in effect creates a new "Internet".  The
  55.  
  56.  
  57.  
  58. Wang                                                            [Page 1]
  59.  
  60. RFC 1385                          EIP                      November 1992
  61.  
  62.  
  63.    development and deployment of such a new "Internet" would take a very
  64.    large amount of time and effort. In particular, in order to maintain
  65.    interoperability between the old and new systems during the
  66.    transition period, almost all upgraded systems have to run both the
  67.    new and old versions in parallel and also have to determine which
  68.    version to use depending on whether the other side is upgraded or
  69.    not.
  70.  
  71.    Let us now have a look at the detailed changes that will be required
  72.    to replace the current IP with a completely new "IP" and to maintain
  73.    the interoperability between the new and the old systems.
  74.  
  75.    1) Border Routers: Border routers have to be upgraded and to provide
  76.       address translation service for IP packets across the boundaries.
  77.       Note that the translation has to be done on the outgoing IP
  78.       packets as well as the in-coming packets to IP hosts.
  79.  
  80.    2) Subnet Routers: Subnet Routers have to be upgraded and have to
  81.       deal with both the new and the old packet formats.
  82.  
  83.    3) Hosts: Hosts have to be upgraded and run both the new and the
  84.       old protocols in parallel. Upgraded hosts also have to determine
  85.       whether the other side is upgraded or not in order to choose the
  86.       correct protocol to use.
  87.  
  88.    4) DNS: The DNS has to be modified to provide mapping for domain
  89.       names and new addresses.
  90.  
  91.    5) ARP/RARP: ARP/RARP have to be modified, and upgraded hosts and
  92.       routers have to deal with both the old and new ARP/RARP packets.
  93.  
  94.    6) ICMP: ICMP has to be modified, and the upgraded routers have to
  95.       be able to generate both both old and new ICMP packets.  However,
  96.       it may be impossible for a backbone router to determine
  97.       whether the packet comes from an upgraded host or an IP host but
  98.       translated by the border router.
  99.  
  100.    7) TCP/UDP Checksum: The pseudo headers may have to be modified to
  101.       use the new addresses.
  102.  
  103.    8) FTP: The DATA PORT (PORT) command has to be changed to pass new
  104.       addresses.
  105.  
  106.    In this paper, we argue that an evolutionary approach can extend the
  107.    addressing space yet maintain backward compatibility.  The Extended
  108.    Internet Protocol (EIP) we present here can be used as a framework by
  109.    which a new routing and addressing scheme may solve the problem of
  110.    address exhaustion yet maintain maximum backward compatibility to
  111.  
  112.  
  113.  
  114. Wang                                                            [Page 2]
  115.  
  116. RFC 1385                          EIP                      November 1992
  117.  
  118.  
  119.    current IP.
  120.  
  121.    EIP has a number of very desirable features:
  122.  
  123.    1) EIP allows the Internet to have virtually unlimited number of
  124.       network numbers and over 10**9 hosts in each network.
  125.  
  126.    2) EIP is flexible to accommodate most routing and addressing
  127.       schemes, such as those proposed in Nimrod [8], Pip [7], NSAP [9]
  128.       and CityCodes [10]. EIP also allows new fields such as Handling
  129.       Directive [7] or CI [11] to be added.
  130.  
  131.    3) EIP can substantially reduce the amount of modifications to
  132.       current systems and greatly ease the difficulties in transition.
  133.       In particular, it does not require the upgraded hosts and subnet
  134.       routers to run two set of protocols in parallel.
  135.  
  136.    4) EIP requires no changes to all assigned IP addresses and subnet
  137.       structures in local are networks.  and requires no modifications
  138.       to ARP/RARP, ICMP, TCP/UDP checksum.
  139.  
  140.    5) EIP can greatly ease the difficulties of transition.  During the
  141.       transition period, no upgrade is required to the subnet routers.
  142.       EIP hosts maintain full compatibility with IP hosts within the
  143.       same network, even after the transition period.  During the
  144.       transition period, IP hosts can communicate with any hosts in
  145.       other networks via a simple translation service.
  146.  
  147.    In the rest of the paper, IP refers to the current Internet Protocol
  148.    and EIP refers to the Extended Internet Protocol (EIP is pronounced
  149.    as "ape" - a step forward in the evolution :-).
  150.  
  151. Extended Internet Protocol (EIP)
  152.  
  153.    The EIP header format is shown in Figure 1 and the contents of the
  154.    header follows.
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Wang                                                            [Page 3]
  171.  
  172. RFC 1385                          EIP                      November 1992
  173.  
  174.  
  175.        0                   1                   2                   3
  176.        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
  177.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  178.       |Version|  IHL  |Type of Service|          Total Length         |
  179.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  180.       |         Identification        |Flags|      Fragment Offset    |
  181.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  182.       |  Time to Live |    Protocol   |         Header Checksum       |
  183.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  184.       |                Source Host Number                             |
  185.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  186.       |              Destination Host Number                          |
  187.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  188.       |     EIP ID    | EIP Ext Length|   EIP Extension (variable)    |
  189.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  190.  
  191.                     Figure 1: EIP Header Format
  192.  
  193.    Version:  4 bits
  194.  
  195.      The Version field is identical to that of IP. This field is set
  196.      purely for compatibility with IP hosts. It is not checked by EIP
  197.      hosts.
  198.  
  199.    IHL:  4 bits
  200.  
  201.      Internet Header Length is identical to that of IP. IHL is set to
  202.      the length of EIP header purely for compatibility with IP. This
  203.      field is not checked by EIP hosts.  see below the EIP Extension
  204.      Length field for more details)
  205.  
  206.    Type of Service:  8 bits
  207.  
  208.      The ToS field is identical to that of IP.
  209.  
  210.    Total Length:  16 bits
  211.  
  212.      The Total Length field is identical to that of IP.
  213.  
  214.    Identification:  16 bits
  215.  
  216.      The Identification field is identical to that of IP.
  217.  
  218.    Flags:  3 bits
  219.  
  220.      The Flags field is identical to that of IP.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Wang                                                            [Page 4]
  227.  
  228. RFC 1385                          EIP                      November 1992
  229.  
  230.  
  231.    Fragment Offset:  13 bits
  232.  
  233.      The Fragment Offset field is identical to that of IP.
  234.  
  235.    Time to Live:  8 bits
  236.  
  237.      The Time to Live field is identical to that of IP.
  238.  
  239.    Protocol:  8 bits
  240.  
  241.      The Protocol field is identical to that of IP.
  242.  
  243.    Header Checksum:  16 bits
  244.  
  245.      The Header Checksum field is identical to that of IP.
  246.  
  247.    Source Host Number:  32 bits
  248.  
  249.      The Source Host Number field is used for identifying the
  250.      source host but is unique only within the source network
  251.      (the equivalent of the host portion of the source IP address).
  252.  
  253.    Destination Host Number:  32 bits
  254.  
  255.      The Destination Host Number field is used for identifying the
  256.      destination host but is unique only within the destination network
  257.      (the equivalent of the host portion of the destination IP address).
  258.  
  259.    EIP ID: 8 bits
  260.  
  261.      The EIP ID field equals to 0x8A. The EIP ID value is chosen
  262.      in such a way that, to IP hosts and IP routers, an EIP appears
  263.      to be an IP packet with a new IP option of following parameters:
  264.  
  265.        COPY CLASS NUMBER LENGTH DESCRIPTION
  266.        ---- ----- ------ ------ -----------
  267.          1    0     TBD    var
  268.  
  269.        Option:  Type=TBD
  270.  
  271.    EIP Extension Length: 8 bits
  272.  
  273.         The EIP Extension Length field indicates the total length
  274.         of the EIP ID field, EIP Extension Length field and the
  275.         EIP Extension field in octets. The maximum length that the
  276.         IHL field above can specify is 60 bytes, which is considered
  277.         too short in future. EIP hosts actually use the EIP Extension
  278.         Length field to calculate the total header length:
  279.  
  280.  
  281.  
  282. Wang                                                            [Page 5]
  283.  
  284. RFC 1385                          EIP                      November 1992
  285.  
  286.  
  287.      The total header length = EIP Extension Length + 20.
  288.  
  289.      The maximum header length of an EIP packet is then 276 bytes.
  290.  
  291.    EIP Extension: variable
  292.  
  293.      The EIP Extension field holds the Source Network Number,
  294.      Destination Network Number and other fields. The format
  295.      of the Extension field is not specified here. In its simplest
  296.      form, it can be used to hold two fixed size fields as the
  297.      Source Network Number and Destination Network Number as the
  298.      extension to the addressing space. Since the Extension
  299.      field is variable in length, it can accommodate almost any
  300.      routing and addressing schemes. For example, the Extension
  301.      field can be used to hold "Routing Directive" etc specified
  302.      in Pip [7] or "Endpoint IDs" suggested in Nimrod [8], or the
  303.      "CityCode" [10]. It can also hold other fields such as the
  304.      "Handling Directive" [7] or "Connectionless ID" [11].
  305.  
  306.    EIP achieves maximum backward compatibility with IP by making the
  307.    extended space appear to be an IP option to the IP hosts and routers.
  308.  
  309.    When an IP host receives an EIP packets, the EIP Extension field is
  310.    safely ignored as it appears to the IP hosts as an new, therefore an
  311.    unknown, IP option.  As a result, there is no need for translation
  312.    for in-coming EIP packets destined to IP hosts and there is also no
  313.    need for subnet routers to be upgraded during the transition period
  314.    see later section for more details).
  315.  
  316.    EIP hosts or routers can, however, determine whether a packet is an
  317.    IP packet or an EIP packet by examining the EIP ID field, whose
  318.    position is fixed in the header.
  319.  
  320.    The EIP Extension field holds the Source and Destination Network
  321.    Numbers, which are only used for communications between different
  322.    networks. For communications within the same network, the Network
  323.    Numbers may be omitted. When the Extension field is omitted, there is
  324.    little difference between an IP packet and an EIP packet.  Therefore,
  325.    EIP hosts can maintain completely compatibility with IP hosts within
  326.    one network.
  327.  
  328.    In EIP, the Network Numbers and Host Numbers are separate and the IP
  329.    address field is used for the Host Number in EIP. There are a number
  330.    of advantages:
  331.  
  332.    1) It maintains full compatibility between IP hosts and EIP hosts
  333.       for communications within one network.  Note that the Network
  334.       Number is not needed for communications within one network. A
  335.  
  336.  
  337.  
  338. Wang                                                            [Page 6]
  339.  
  340. RFC 1385                          EIP                      November 1992
  341.  
  342.  
  343.       host can omit the Extension field if it does not need any other
  344.       information in the Extension field, when it communicates with
  345.       another host within the same network.
  346.  
  347.    2) It allows the IP subnet routers to route EIP packet by treating
  348.       the Host Number as the IP address during the transition period,
  349.       therefore the subnet routers are not required to be updated
  350.       along the border routers.
  351.  
  352.    3) It allows ARP/RARP to work with both EIP and IP hosts without
  353.       any modifications.
  354.  
  355.    4) It allows the translation at the border routers much easier.
  356.       During the transition period when the IP addresses are still
  357.       unique, the network portion of the IP addresses can be directly
  358.       extracted and mapped to EIP Network Numbers.
  359.  
  360. Modifications to IP Systems
  361.  
  362.    In this section, we outline the modifications to the IP systems that
  363.    are needed for transition to EIP. Because of the similarity between
  364.    the EIP and IP, the amount of modifications needed to current systems
  365.    are substantially reduced.
  366.  
  367.    1) Network Numbers: Each network has to be assigned a new EIP Network
  368.       Number based on the addressing scheme used. The mapping
  369.       between the IP network numbers and the EIP Network Numbers can
  370.       be used for translation service (see below).
  371.  
  372.    2) Host Numbers: There is no need for assigning EIP Host Numbers.
  373.       All existing hosts can use their current IP addresses as their
  374.       EIP Host Numbers. New machines may be allocated any number from
  375.       the 32-bit Host Number space since the structure posed on IP
  376.       addressing is no longer necessary. However, during the transition,
  377.       allocation of EIP Host Numbers should still follow the IP
  378.       addressing rule, so that the EIP Host Numbers are still globally
  379.       unique and can still be interpreted as IP addresses.  This will
  380.       allow a more gradual transition to EIP (see below).
  381.  
  382.    3) Translation Service: During the transition period when the EIP
  383.       Host Numbers are still unique, an address translation service
  384.       can be provided to IP hosts that need communicate with hosts in
  385.       other networks cross the upgraded backbone networks.  The
  386.       translation service can be provided by the border routers.  When a
  387.       border router receives an IP packet, it obtains the Destination
  388.       Network Number by looking up in the mapping table between IP
  389.       network numbers and EIP Network Numbers. The border router then
  390.       adds the Extension field with the Source and Destination Network
  391.  
  392.  
  393.  
  394. Wang                                                            [Page 7]
  395.  
  396. RFC 1385                          EIP                      November 1992
  397.  
  398.  
  399.       Numbers into the packet, and forwards to the backbone networks.
  400.       It is only necessary to translate the out-going IP packets to
  401.       the EIP packets.  There is no need to translate the EIP packets
  402.       back to IP packets even when they are destined to IP hosts.
  403.       This is because that the Extension field in the EIP packets
  404.       appears to IP hosts just an unknown IP option and is ignored by
  405.       the IP hosts during the processing.
  406.  
  407.    4) Border Routers: The new EIP Extension has to be implemented and
  408.       routing has to be done based on the Network Number in the EIP
  409.       Extension field. The border routers may have to provide the
  410.       translation service for out-going IP packets during the transition
  411.       period.
  412.  
  413.    5) Subnet Routers: No modifications are required during the transition
  414.       period when EIP Host Numbers (which equals to the IP
  415.       addresses) are still globally unique. The subnet routing is carried
  416.       out based on the EIP Host Numbers and when the EIP Host
  417.       IDs are still unique, subnet routers can determine, by treating
  418.       the EIP Host Number as the IP addresses, whether a packet is
  419.       destined to remote networks or not and forward correctly. The
  420.       Extension field in the EIP packets also appear to the IP subnet
  421.       routers an unknown IP option and is ignored in the processing.
  422.       However, subnet routers eventually have to implement the EIP
  423.       Extension and carry out routing based on Network Numbers when
  424.       EIP Host Numbers are no longer globally unique.
  425.  
  426.    6) Hosts: The EIP Extension has to be implemented.  routing has to
  427.       be done based on the Network Number in the EIP Extension field,
  428.       and also based on the Host Number and subnet mask if subnetting
  429.       is used. IP hosts may communication with any hosts within the
  430.       same network at any time. During the transition period when the
  431.       EIP Host Numbers are still unique, IP hosts can communicate with
  432.       any hosts in other network via the translation service.
  433.  
  434.    7) DNS: A new resource record (RR) type "N" has to be added for EIP
  435.       Network Numbers. The RR type "A", currently used for IP
  436.       addresses, can still be used for EIP Host Numbers. RR type "N"
  437.       entries have to be added and RR type "PTR" to be updated.  All
  438.       other entries remain unchanged.
  439.  
  440.    8) ARP/RARP: No modifications are required. The ARP and RARP are
  441.       used for mapping between EIP Host Numbers and physical
  442.       addresses.
  443.  
  444.    9) ICMP: No modifications are required.
  445.  
  446.    10) TCP/UDP Checksum: No modifications are required. The pseudo
  447.  
  448.  
  449.  
  450. Wang                                                            [Page 8]
  451.  
  452. RFC 1385                          EIP                      November 1992
  453.  
  454.  
  455.        header includes the EIP Source and Destination IDs instead of
  456.        the source and destination IP addresses.
  457.  
  458.    11) FTP: No modifications are required during the transition period
  459.        when the IP hosts can still communicate with hosts in other
  460.        networks via the translation service. After the transition period,
  461.        however, the "DATA Port (Port)" command has to be modified to
  462.        pass the port number only and ignore the IP address.  A new FTP
  463.        command may be created to pass both the port number and the EIP
  464.        address to allow a third party to be involved in the file
  465.        transfer.
  466.  
  467. Transition to EIP
  468.  
  469.    In this section, we outline a plan for transition to EIP.
  470.  
  471.    EIP can greatly reduce the complexity of transition. In particular,
  472.    there is no need for the updated hosts and subnet routers to run two
  473.    protocols in parallel in order to achieve interoperability between
  474.    old and new systems.  During the transition, IP hosts can still
  475.    communicate with any machines in the same network without any
  476.    changes.  When the EIP Host Numbers (i.e., the 32-bit IP addresses)
  477.    are still globally unique, IP hosts can contact hosts in other
  478.    networks via translation service provided in the border routers.
  479.  
  480.    The transition goes as follows:
  481.  
  482.    Phase 0:
  483.         a) Choose an addressing and routing scheme for the Internet.
  484.         b) Implement the routing protocol.
  485.         c) Assign new Network Numbers to existing networks.
  486.  
  487.    Phase 1:
  488.         a) Update all backbone routers and border routers.
  489.         b) Update DNS servers.
  490.         c) Start translation service.
  491.  
  492.    Phase 2:
  493.         a) Update first the key hosts such as mail servers, DNS servers,
  494.         FTP servers and central machines.
  495.         b) Update gradually the rest of the hosts.
  496.  
  497.    Phase 3:
  498.         a) Update subnet routers
  499.         b) Withdraw the translation service.
  500.  
  501.    The translation service can be provided as long as the Host IDs
  502.    (i.e., the 32-bit IP address) are still globally unique. When the IP
  503.  
  504.  
  505.  
  506. Wang                                                            [Page 9]
  507.  
  508. RFC 1385                          EIP                      November 1992
  509.  
  510.  
  511.    address space is exhausted, the translation service will be withdrawn
  512.    and the remaining IP hosts can only communicate with hosts within the
  513.    the same network. At the same time, networks can use any numbers in
  514.    the 32-bit space for addressing their hosts.
  515.  
  516. Related Work
  517.  
  518.    A recent proposal called IPAE by Hinden and Crocker also attempts to
  519.    minimize the modifications to the current IP system yet to extend the
  520.    addressing space [12]. IPAE uses encapsulation so that the extended
  521.    space is carried as IP data. However, it has been found that the 64
  522.    bits IP data returned by an ICMP packet is too small to hold the
  523.    Global IP addresses. Thus, when a router receives an ICMP generated
  524.    by an old IP host, it is not able to convert it into a proper ICMP
  525.    packet. More details can be found in [13].
  526.  
  527. Discussions
  528.  
  529.    EIP does not necessary increase the header length significantly as
  530.    most of the fields in the current IP will be still needed in the new
  531.    internet protocol. There are debates as to whether fragmentation and
  532.    header checksum are necessary in the new internet protocol but no
  533.    consensus has been reached.
  534.  
  535.    EIP assumes that IP hosts and routers ignore unknown IP option
  536.    silently as required by [15,16].  Some people have expressed some
  537.    concerns as to whether current IP routers and hosts in the Internet
  538.    can deal with unknown IP options properly.
  539.  
  540.    In order to look into the issues further, we carried out a number of
  541.    experiments over the use of IP option. We selected 35 hosts over 30
  542.    countries across the Internet. A TCP test program (based on ttcp.c)
  543.    then transmitted data to the echo port (tcp port 7) of each of the
  544.    hosts. Two tests were carried out for each host, one with an unknown
  545.    option (type 0x8A, length 40 bytes) and the other without any
  546.    options.
  547.  
  548.    It is difficult to ensure that the conditions under which the two
  549.    tests run are identical but we tried to make them as close as
  550.    possible. The two tests (test-opt and test-noopt) run on the same
  551.    machine a Sun4) in parallel, i.e., "test-opt& ; test-noopt&" and then
  552.    again in the reverse order, i.e., "test-noopt& ; test-opt&", so each
  553.    test pair actually run twice.  Each host was ping'ed before the tests
  554.    so that the domain name information was cached before the name
  555.    lookup.
  556.  
  557.    The experiments were carried out at three sites: UCL, Bellcore and
  558.    Cambridge University. The tcp echo throughput (KB/Sec) results are
  559.  
  560.  
  561.  
  562. Wang                                                           [Page 10]
  563.  
  564. RFC 1385                          EIP                      November 1992
  565.  
  566.  
  567.    listed in Appendix.
  568.  
  569.    The results show that the IP option was dealt with properly and there
  570.    is no visible performance difference under the test setup.
  571.  
  572. References
  573.  
  574.    [1] Chiappa, N., "The IP Addressing Issue", Work in Progress, October
  575.        1990.
  576.  
  577.    [2] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby,
  578.        "Towards the Future Architecture", RFC 1287, MIT, BBN, CNRI, ISI,
  579.        UCDavis , December 1991.
  580.  
  581.    [3] Solensky, F. and F. Kastenholz, "A Revision to IP Address
  582.        Classifications", Work in Progress, March 1992.
  583.  
  584.    [4] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an
  585.        Address Assignment and Aggregation Strategy", RFC 1338, BARRNet,
  586.        cisco, Merit, OARnet, June 1992.
  587.  
  588.    [5] Wang, Z., and J. Crowcroft, "A Two-Tier Address Structure for the
  589.        Internet: a solution to the problem of address space exhaustion",
  590.        RFC 1335, University College London, May 1992.
  591.  
  592.    [6] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), a Simple
  593.        Proposal for Internet Addressing and Routing", RFC 1347, DEC,
  594.        June 1992.
  595.  
  596.    [7] Tsuchiya, P., "Pip: The 'P' Internet Protocol", Work in Progress,
  597.        May 1992
  598.  
  599.    [8] Chiappa N., "A New IP Routing and Addressing Architecture", Work
  600.        in Progress, 1992.
  601.  
  602.    [9] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI NSAP
  603.        Allocation in the Internet" RFC 1237, NIST, Mitre, DEC, July
  604.        1991.
  605.  
  606.   [10] Deering, S., "City Codes: An Alternative Scheme for OSI NSAP
  607.        Allocation in the Internet", Work in Progress, January 1992.
  608.  
  609.   [11] Clark, D., "Building routers for the routing of tomorrow", in his
  610.        message to Big-Interent@munnari.oz.au, 14 July 1992.
  611.  
  612.   [12] Hinden, R., and D. Crocker, "A Proposal for IP Address
  613.        Encapsulation (IPAE): A Compatible Version of IP with Large
  614.        Addresses", Work in Progress, July 1992.
  615.  
  616.  
  617.  
  618. Wang                                                           [Page 11]
  619.  
  620. RFC 1385                          EIP                      November 1992
  621.  
  622.  
  623.   [13] Partridge, C., "Re: Note on implementing IPAE", in his message to
  624.        Big-Interent@munnari.oz.au, 17 July 1992.
  625.  
  626.   [14] Deering, S., "SIP: Simple Internet Protocol", Work in Progress,
  627.        September 1992.
  628.  
  629.   [15] Braden, R., Editor, "Requirements for Internet Hosts
  630.         -- Communication Layers", RFC 1122, ISI, October 1989.
  631.  
  632.   [16] Almquist, P., Editor, "Requirements for IP Routers", Work in
  633.        Progress, October 1991.
  634.  
  635. Appendix
  636.  
  637.        Throughput Test from UCL (sartre.cs.ucl.ac.uk)
  638.  
  639.       Destination Host          test-noopt     test-opt
  640.       -------------------        ----------     ---------
  641.       oliver.cs.mcgill.ca          1.128756      1.285345
  642.       oliver.cs.mcgill.ca          1.063096      1.239709
  643.       bertha.cc.und.ac.za          0.094336      0.043917
  644.       bertha.cc.und.ac.za          0.075681      0.057120
  645.       vnet3.vub.ac.be              2.090622      2.228181
  646.       vnet3.vub.ac.be              1.781374      1.692740
  647.       itdsrv1.ul.ie                1.937596      2.062579
  648.       itdsrv1.ul.ie                1.928313      1.936784
  649.       sunic.sunet.se              11.064797     11.724055
  650.       sunic.sunet.se              10.861720     10.840306
  651.       pascal.acm.org               2.463790      0.810133
  652.       pascal.acm.org               1.619088      0.860198
  653.       iti.gov.sg                   1.565320      1.983795
  654.       iti.gov.sg                   1.564788      1.921803
  655.       rzusuntk.unizh.ch            9.903805     11.335920
  656.       rzusuntk.unizh.ch            9.597806     10.678098
  657.       funet.fi                     9.897876      9.382925
  658.       funet.fi                    10.487118     11.023745
  659.       odin.diku.dk                 5.851407      5.482946
  660.       odin.diku.dk                 5.992257      6.243283
  661.       cphkvx.cphk.hk               0.758044      0.844406
  662.       cphkvx.cphk.hk               0.784532      0.745606
  663.       bootes.cus.cam.ac.uk        28.341705     29.655824
  664.       bootes.cus.cam.ac.uk        24.804125     23.240990
  665.       pesach.jct.ac.il             1.045922      1.115802
  666.       pesach.jct.ac.il             1.330429      0.978184
  667.       sun1.sara.nl                10.546733     11.500778
  668.       sun1.sara.nl                 9.624833     10.214136
  669.       cocos.fuw.edu.pl             1.747777      1.702324
  670.       cocos.fuw.edu.pl             1.676151      1.716435
  671.  
  672.  
  673.  
  674. Wang                                                           [Page 12]
  675.  
  676. RFC 1385                          EIP                      November 1992
  677.  
  678.  
  679.       apple.com                    4.449559      4.145081
  680.       apple.com                    6.431675      5.520443
  681.       gorgon.tf.tele.no            1.199810      1.374546
  682.       gorgon.tf.tele.no            0.508642      0.993261
  683.       kogwy.cc.keio.ac.jp          3.626448      3.249590
  684.       kogwy.cc.keio.ac.jp          3.913777      4.094849
  685.       exu.inf.puc-rio.br           1.913925      1.795235
  686.       exu.inf.puc-rio.br           1.154936      1.114775
  687.       inria.inria.fr               2.299561      0.599665
  688.       inria.inria.fr               1.219282      0.873672
  689.       kum.kaist.ac.kr              0.252704      0.254199
  690.       kum.kaist.ac.kr              0.236196      0.172367
  691.       sunipc1.labein.es            1.398777      1.243588
  692.       sunipc1.labein.es            0.876177      0.602964
  693.       wifosv.wsr.ac.at             0.531153      0.803387
  694.       wifosv.wsr.ac.at             0.773935      0.557798
  695.       uunet.uu.net                 7.813556      6.764543
  696.       uunet.uu.net                 7.969203      6.657325
  697.       infnsun.aquila.infn.it       2.321197      2.402477
  698.       infnsun.aquila.infn.it       2.400196      2.695016
  699.       muttley.fc.ul.pt             0.545775      0.434672
  700.       muttley.fc.ul.pt             0.284124      0.266017
  701.       dmssyd.syd.dms.csiro.au      2.734685      2.857545
  702.       dmssyd.syd.dms.csiro.au      1.168154      1.462789
  703.       hamlet.caltech.edu           2.552804      2.897286
  704.       hamlet.caltech.edu           3.839141      2.407945
  705.       sztaki.hu                    0.294196      0.403697
  706.       sztaki.hu                    0.236260      0.388755
  707.       menvax.restena.lu            0.465066      0.515361
  708.       menvax.restena.lu            0.358646      0.511985
  709.       nctu.edu.tw                  0.484372      0.816722
  710.       nctu.edu.tw                  0.705733      1.109228
  711.       xalapa.lania.mx              0.899529      0.822544
  712.       xalapa.lania.mx              1.150058      0.881713
  713.       truth.waikato.ac.nz          1.438481      1.993749
  714.       truth.waikato.ac.nz          1.325041      1.833999
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Wang                                                           [Page 13]
  731.  
  732. RFC 1385                          EIP                      November 1992
  733.  
  734.  
  735.          Throughput Test from Bellcore (latour.bellcore.com)
  736.  
  737.       Destination Host          test-noopt     test-opt
  738.       ------------------        ----------     ---------
  739.       oliver.cs.mcgill.ca          1.820014      2.128104
  740.       oliver.cs.mcgill.ca          1.979981      1.866815
  741.       bertha.cc.und.ac.za          0.099289      0.035877
  742.       bertha.cc.und.ac.za          0.118627      0.103763
  743.       vnet3.vub.ac.be              0.368476      0.694463
  744.       vnet3.vub.ac.be              0.443269      0.644050
  745.       itdsrv1.ul.ie                0.721444      0.960068
  746.       itdsrv1.ul.ie                0.713952      0.953275
  747.       sunic.sunet.se               2.989907      2.956766
  748.       sunic.sunet.se               2.100563      2.010292
  749.       pascal.acm.org               2.487185      3.896253
  750.       pascal.acm.org               1.944085      4.269323
  751.       iti.gov.sg                   2.401733      2.735445
  752.       iti.gov.sg                   2.950990      2.793121
  753.       rzusuntk.unizh.ch            4.094820      3.618023
  754.       rzusuntk.unizh.ch            2.952650      2.245001
  755.       funet.fi                     6.703408      5.928008
  756.       funet.fi                     7.389722      5.815122
  757.       odin.diku.dk                 2.094152      2.450695
  758.       odin.diku.dk                 5.362362      4.690722
  759.       cphkvx.cphk.hk               0.092698      0.106880
  760.       cphkvx.cphk.hk               0.496394      0.681994
  761.       bootes.cus.cam.ac.uk         2.632951      2.631322
  762.       bootes.cus.cam.ac.uk         3.717170      1.335914
  763.       pesach.jct.ac.il             0.684029      0.921621
  764.       pesach.jct.ac.il             0.390263      1.095265
  765.       sun1.sara.nl                 3.186035      2.325166
  766.       sun1.sara.nl                 3.053797      3.081236
  767.       cocos.fuw.edu.pl             0.154405      0.124795
  768.       cocos.fuw.edu.pl             0.120283      0.105825
  769.       apple.com                   12.588979     12.957880
  770.       apple.com                   13.861733     12.211125
  771.       gorgon.tf.tele.no            1.280217      1.112675
  772.       gorgon.tf.tele.no            0.243205      0.631096
  773.       kogwy.cc.keio.ac.jp          6.249789      5.075968
  774.       kogwy.cc.keio.ac.jp          3.387490      4.583511
  775.       exu.inf.puc-rio.br           2.089536      2.233711
  776.       exu.inf.puc-rio.br           2.476758      2.249439
  777.       inria.inria.fr               0.653974      0.866246
  778.       inria.inria.fr               0.739127      1.130521
  779.       kum.kaist.ac.kr              1.541682      1.312546
  780.       kum.kaist.ac.kr              0.906632      1.042793
  781.       sunipc1.labein.es            0.101496      0.091456
  782.       sunipc1.labein.es            0.054245      0.101585
  783.  
  784.  
  785.  
  786. Wang                                                           [Page 14]
  787.  
  788. RFC 1385                          EIP                      November 1992
  789.  
  790.  
  791.       wifosv.wsr.ac.at             1.044443      0.369528
  792.       wifosv.wsr.ac.at             0.596935      0.870377
  793.       uunet.uu.net                 9.530348      8.999789
  794.       uunet.uu.net                 8.941888      6.075660
  795.       infnsun.aquila.infn.it       1.619418      1.569645
  796.       infnsun.aquila.infn.it       1.156780      1.158000
  797.       muttley.fc.ul.pt             0.353632      0.416126
  798.       muttley.fc.ul.pt             0.221522      0.155505
  799.       dmssyd.syd.dms.csiro.au      3.433901      3.272839
  800.       dmssyd.syd.dms.csiro.au      3.408975      3.130188
  801.       hamlet.caltech.edu           5.367756      6.325031
  802.       hamlet.caltech.edu           4.828718      5.676571
  803.       sztaki.hu                    0.301120      0.362481
  804.       sztaki.hu                    0.253222      0.519892
  805.       menvax.restena.lu            0.364221      0.480789
  806.       menvax.restena.lu            0.456882      0.580778
  807.       nctu.edu.tw                  0.246523      1.199412
  808.       nctu.edu.tw                  0.423476      0.630833
  809.       xalapa.lania.mx              0.748642      0.607284
  810.       xalapa.lania.mx              0.716781      0.643030
  811.       truth.waikato.ac.nz          2.197595      2.072601
  812.       truth.waikato.ac.nz          2.489748      2.186684
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835.  
  836.  
  837.  
  838.  
  839.  
  840.  
  841.  
  842. Wang                                                           [Page 15]
  843.  
  844. RFC 1385                          EIP                      November 1992
  845.  
  846.  
  847.           Throughput Test from Cam U (cus.cam.ac.uk)
  848.  
  849.       Destination Host          test-noopt     test-opt
  850.       ------------------        ----------     ---------
  851.       oliver.cs.mcgill.ca           1.128756       1.285345
  852.       oliver.cs.mcgill.ca           1.063096       1.239709
  853.       bertha.cc.und.ac.za           0.031218       0.031221
  854.       bertha.cc.und.ac.za           0.034405       0.034925
  855.       vnet3.vub.ac.be               0.568487       0.731320
  856.       vnet3.vub.ac.be               0.558238       0.581415
  857.       itdsrv1.ul.ie                 1.064302       1.284707
  858.       itdsrv1.ul.ie                 0.852089       1.025779
  859.       sunic.sunet.se                7.179942       6.270326
  860.       sunic.sunet.se                5.772485       6.689160
  861.       pascal.acm.org                1.661248       1.726725
  862.       pascal.acm.org                1.557839       1.428193
  863.       iti.gov.sg                    0.600616       0.926690
  864.       iti.gov.sg                    0.772887       0.956636
  865.       rzusuntk.unizh.ch             3.645913       4.504969
  866.       rzusuntk.unizh.ch             1.853503       2.671272
  867.       funet.fi                      4.190147       3.421110
  868.       funet.fi                      2.270988       3.789678
  869.       odin.diku.dk                  1.361227       0.993901
  870.       odin.diku.dk                  1.977774       2.415716
  871.       cphkvx.cphk.hk                1.173451       1.298421
  872.       cphkvx.cphk.hk                1.151376       1.184210
  873.       bootes.cus.cam.ac.uk        269.589141     238.920081
  874.       bootes.cus.cam.ac.uk        331.203020     293.556436
  875.       pesach.jct.ac.il              0.343598       0.492202
  876.       pesach.jct.ac.il              0.582809       0.930958
  877.       sun1.sara.nl                  1.529277       1.470571
  878.       sun1.sara.nl                  0.896041       0.894923
  879.       cocos.fuw.edu.pl              0.131180       0.142239
  880.       cocos.fuw.edu.pl              0.137697       0.148895
  881.       apple.com                     1.330794       0.453590
  882.       apple.com                     0.856476       0.714661
  883.       gorgon.tf.tele.no             0.094793       0.099981
  884.       gorgon.tf.tele.no             0.167257       0.151625
  885.       kogwy.cc.keio.ac.jp           0.154681       0.178868
  886.       kogwy.cc.keio.ac.jp           1.095814       0.871496
  887.       exu.inf.puc-rio.br            0.454272       0.384484
  888.       exu.inf.puc-rio.br            0.705198       0.690708
  889.       inria.inria.fr                0.149511       0.150021
  890.       inria.inria.fr                0.071125       0.077257
  891.       kum.kaist.ac.kr               0.721184       0.549511
  892.       kum.kaist.ac.kr               0.250285       0.296195
  893.       sunipc1.labein.es             0.519284       0.491745
  894.       sunipc1.labein.es             0.990174       1.009475
  895.  
  896.  
  897.  
  898. Wang                                                           [Page 16]
  899.  
  900. RFC 1385                          EIP                      November 1992
  901.  
  902.  
  903.       wifosv.wsr.ac.at              0.360751       0.418554
  904.       wifosv.wsr.ac.at              0.344268       0.326605
  905.       uunet.uu.net                  4.247430       3.305592
  906.       uunet.uu.net                  3.139251       2.945469
  907.       infnsun.aquila.infn.it        0.480731       0.782631
  908.       infnsun.aquila.infn.it        0.230471       0.292273
  909.       muttley.fc.ul.pt              0.239624       0.334286
  910.       muttley.fc.ul.pt              0.586156       0.419485
  911.       dmssyd.syd.dms.csiro.au       3.630623       3.607504
  912.       dmssyd.syd.dms.csiro.au       1.743162       2.994665
  913.       hamlet.caltech.edu            5.897946       4.650703
  914.       hamlet.caltech.edu            5.118200       5.622022
  915.       sztaki.hu                     0.338358       0.225206
  916.       sztaki.hu                     0.113328       0.112637
  917.       menvax.restena.lu             0.224967       0.359237
  918.       menvax.restena.lu             0.452945       0.472345
  919.       nctu.edu.tw                   2.549709       2.037245
  920.       nctu.edu.tw                   2.229093       2.469851
  921.       xalapa.lania.mx               0.713586       0.810107
  922.       xalapa.lania.mx               0.612278       0.731705
  923.       truth.waikato.ac.nz           1.438481       1.993749
  924.       truth.waikato.ac.nz           1.325041       1.833999
  925.  
  926. Security Considerations
  927.  
  928.    Security issues are not discussed in this memo.
  929.  
  930. Author's Address
  931.  
  932.    Zheng Wang
  933.    Dept of Computer Science
  934.    University College London
  935.    London WC1E 6BT, UK
  936.  
  937.    EMail: z.wang@cs.ucl.ac.uk
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Wang                                                           [Page 17]
  955.