Network Working Group                                     Zheng Wang
Internet-Draft                             University College London
                                                       Paul Tsuchiya
                                                            Bellcore
                                                        October 1992


           The EIPIP Protocol: a Pip engine with an EIP shell


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 memo, we present an internet protocol called "EIPIP".  EIPIP
   is basically a protocol with a Pip engine and an EIP shell; it has
   the full capacity of Pip and all the desirable properties of EIP. We
   discuss the modifications required to the current Internet systems,
   the support for old IP hosts, deployment plan and implementation
   experience.  Distribution of this memo is unlimited.

Introduction

   In this memo, we present an internet protocol called "EIPIP".  EIPIP
   is basically a protocol with a Pip engine [1-3] and an EIP shell [4];
   it has the full capacity of Pip and all the desirable properties of
   EIP.

   Pip is a new generation protocol which has the following unique
   features:

   1)   Clear separation of routing, handling and identification func-
        tions,



Expires: 4/1993                                                 [Page 1]


Internet-Draft                                              October 1992


   2)   Rich and flexible routing mechanisms,

   3)   Simple and fast forwarding, and

   4)   Powerful tagging mechanism.

   EIP is a framework for a new internet protocol to maintain backward
   compatibility with current IP. It has following desirable properties:

   1)   Backward compatibility with current IP hosts,

   2)   Minimal modifications to the host and router software, and the
        DNS system,

   3)   No modifications to ARP/RARP, ICMP and TCP/UDP pseudo checksum,

   4)   Simple and gradual transition to a new internet protocol.

   In the following sections, we assume that the readers are familiar
   with both Pip and EIP.

The EIPIP Header

   The EIPIP header is partitioned into four basic parts (Figure 1).  Of
   the four parts, three parts (Router Part, Router Options Part and
   Host Options Part) are identical to the corresponding parts of Pip.
   The Misc Part of EIPIP is different from that of Pip; it is the
   merger of the Misc Part and the Host Part of Pip, and the fields are
   re-arranged to allow backward compatibility with IP.  The construc-
   tion of the FTIF chain in EIPIP is slightly different from that in
   Pip; the first and the last FTIFs (i.e. the host portion of the FTIF
   chain) are in the Misc Part so the Router Part only contains the mid-
   dle fragments of the FTIF chain (i.e. the network portion of the FTIF
   chain). However, the FTIF chain in the nested Router Part is identi-
   cal to that in Pip.

         +===========================+
         |      Misc Part (MP)       |   Both Hosts and Routers may use
         +===========================+
         |      Router Part (RP)     |   For forwarding and encapsulation
         +===========================+
         |      Router Options (RO)  |   Both Routers and Hosts use
         +===========================+
         |      Host Options (HO)    |   Only Hosts use
         +===========================+

                     Figure 1: EIPIP Header Format




Expires: 4/1993                                                 [Page 2]


Internet-Draft                                              October 1992


   The Misc Part of EIPIP is shown in Figure 2. The Misc Part contains a
   minimal IP header (i.e. the first 5 32-bit words), then the  EIPIP ID
   fields, followed by some fields from the Host Part of Pip. EIPIP
   merges the Host Part of Pip into the Misc Part because many fields in
   the Host Part of the Pip are already provided in the minimal IP
   header. The fields EIPIP ID and Data Offset serve two purposes: 1) as
   an identifier for EIPIP host and routers to identify whether a packet
   is an EIPIP packet or IP packet, and 2) as a backward compatibility
   mechanism for IP hosts to ignore the extended space safely.

          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                    |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |    EIPIP ID   |  Data Offset  |   RO Offset   |   HO Offset   |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                        Packet ID (PID)                        |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-   Source EID   -+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+  Destination EID  +-+-+-+-+-+-+-+-+-+-+-+-+
         |                                                               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 2: Misc Part (fixed length, 11 32-bit words)

   Each field is described below:

     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 EIPIP hosts and routers.

     IHL:  4 bits




Expires: 4/1993                                                 [Page 3]


Internet-Draft                                              October 1992


       Internet Header Length is identical to that of IP. IHL is
       set to the length of EIPIP header purely for compatibility
       with IP. This field is not checked by EIPIP hosts. If the
       length of the EIPIP header exceeds 60 bytes (i.e. 15 words
       - the maximum value that IHL can hold), it is set to zero.
       (see the Data Offset field below and the section on translation
        service for more details).

     Type of Service:  8 bits

       The ToS field is identical to that of IP. But this field
       is not used by EIPIP hosts and routers.

     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.

     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
       (it is the first item of the Pip FTIFs that identifies the
       host or the equivalent of the host portion of the Source
       IP Address).



Expires: 4/1993                                                 [Page 4]


Internet-Draft                                              October 1992


     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
       (It is the last item of the Pip FTIFs or the equivalent
       of the host portion of the Destination IP Address).

     EIPIP ID: 8 bits

       The EIPIP ID field equals to 0x8A. The EIPIP ID has two
       purposes: 1) an EIPIP host or router can determine
       whether a packet is an EIPIP packet or an IP packet
       by examining the EIPIP ID field, and 2) an IP host
       or router can safely ignore the extended space as the
       EIPIP ID appears to them an unknown IP option with

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

         Option:  Type=138

     Data Offset: 8 bits

       The Data Offset field indicates the offset to the transport
       layer data with the EIPIP ID field as the reference byte.
       In EIPIP, the Data Offset field is used to locate the
       transport layer data and also the total length of the
       packet header (Total Length = Data Offset + 20 bytes).
       The maximum EIPIP header length is, therefore, 576 bytes.

     Router Options Offset: 8 bits

       The Router Option Offset (RO Offset) field indicates the
       offset to the Router Options Part with the EIPIP ID field
       as the reference byte.

     Host Options Offset: 8 bits

       The Host Option Offset (HO Offset) field indicates the
       offset to the Host Options Part with the EIPIP ID field
       as the reference byte.

       The three fields Data offset, RO Offset and HO Offset
       are also used for determining whether the Router Options
       Part and Host Option Part are present or not, and if
       present, the length of the Options Part.
       (Router Options Part length = HO Offset - RO Offset



Expires: 4/1993                                                 [Page 5]


Internet-Draft                                              October 1992


       and Host Options Part length = Data Offset - HO Offset).

   The Router Part of EIPIP is identical to that of Pip (shown in Figure
   3) and is detailed in [3].

         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |         HD/RC Epoch           |     Routing Context (RC)      |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | FL|FTIF Offset|             Handling Directive (HD)           |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                        FTIFs (variable)                       |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 3: Router Part (variable length)

   The Router Options Part and Host Options Part of EIPIP are identical
   to that of Pip (shown in Figure 4) and are detailed in [3].

         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                    Option Length                              |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         |                  Option Lists (variable length)               |
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 4: Router and Host Options (variable length)

   The tunnelling in EIPIP is identical to that of Pip, i.e. by encapsu-
   lating the Router Part in another Router Part. There is one Router
   Part for each nested tunnel (Figure 5):

         +===========================+
         |      Misc Part (MP)       |   Both Hosts and Routers may use
         +===========================+
         |      Router Part (RP)     |   For forwarding and encapsulation
         +===========================+
         |      Router Part (RP)     |   For forwarding and encapsulation
         +===========================+
                      .
                      .
                      .
         +===========================+
         |      Router Part (RP)     |   For forwarding and encapsulation
         +===========================+
         |      Router Options (RO)  |   Both Routers and Hosts use
         +===========================+
         |      Host Options (HO)    |   Only Hosts use
         +===========================+




Expires: 4/1993                                                 [Page 6]


Internet-Draft                                              October 1992


               Figure 5: EIPIP Header Format when Tunnelling

Modifications to current Internet Systems

   In this section, we outline the modifications to the Internet systems
   that are needed for transition to EIPIP. Because of the backward com-
   patibility nature of EIPIP, the amount of modifications needed to
   current systems are substantially reduced.

   1)   Network Numbers: Each network has to be assigned the FTIF chain
        fragments based on the addressing scheme used. The mapping
        between the IP network numbers and the FTIF chain fragments can
        be used for translation service (see below).

   2)   Host Numbers: There is no need for assigning EIPIP Host Numbers.
        All existing hosts can use their current IP addresses as their
        EIPIP Host Numbers. New machines may be allocated any number
        from the 32-bit Host Number space since the structure posed on
        IP addressing is no longer necessary. However, during the tran-
        sition, allocation of EIPIP Host Numbers should still follow the
        IP addressing rule, so that the EIPIP Host Numbers are still
        globally unique and can still be interpreted as IP addresses.
        This will allow a more gradual transition to EIPIP (see below).

   3)   Translation Service: During the transition period when the EIPIP
        Host Numbers 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 trans-
        lation service can be provided by the border routers.  When a
        border router receives an IP packet, it obtains the FTIFs by
        looking up in the mapping table between IP network numbers and
        corresponding FTIFs. The border router then adds the extended
        fields after the minimal IP header, and forwards to the backbone
        networks.  Normally it is only necessary for border routers to
        translate out-going IP packets to the EIPIP packets since an IP
        host will treat the extended fields in the in-coming EIPIP pack-
        ets as an unknown IP option thus ignore them silently.  However,
        translation on in-coming packets may be also desirable in the
        following two cases: 1) there are hosts on the local network
        that do not handle the unknown IP options correctly, and 2) the
        FTIF chain in the incoming packet is so long that the packet
        header extended 60 bytes (that is reflected by the fact that the
        IHL is set to zero). In this case, the extended fields in an
        EIPIP packet have to be deleted for IP hosts to handle it
        correctly.

   4)   Border Routers: The routing protocol has to be modified based on
        the addressing scheme used. All border routers have to be



Expires: 4/1993                                                 [Page 7]


Internet-Draft                                              October 1992


        upgraded to full capacity EIPIP systems and also carry out
        translation service during the transition period.

   5)   Subnet Routers: No modifications are required during the transi-
        tion period when EIPIP Host Numbers (which equals to the IP
        addresses) are still globally unique. The subnet routing can be
        carried out based on the EIPIP Host Numbers as when the EIP Host
        IDs are still unique, subnet routers can determine, by treating
        the EIP Host Number as the IP addresses, whether a packet is
        destined to remote networks or not and forward correctly. The IP
        subnet routers will treat the extended fields in the EIPIP pack-
        ets as an unknown IP option and ignore it. However, subnet
        routers eventually have to upgraded to full EIPIP systems and
        carry out routing based on FTIFs when EIPIP  Host Numbers are no
        longer globally unique.

   6)   Hosts: No modifications are required for communications within
        one network. For communications with hosts in other networks, a
        host has to either use the translation service offered by the
        border routers or be upgraded to a full EIPIP system.

   7)   DNS: A new resource record (RR) type "N" has to be added for the
        FTIF chain. The RR type "A", currently used for IP addresses,
        can still be used for the first and last FTIFs so that the DNS
        can serve both IP hosts and EIPIP hosts without first determin-
        ing whether a request comes from an IP host or an EIPIP host. An
        IP host will only request for RR type A while an EIPIP host will
        request for both RR type A and N.  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 EIPIP Host Numbers and physical
        addresses.

   9)   ICMP: No modifications are required.

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

   11)  FTP: No modifications are required during the transition period
        when the IP numbers are still unique. The hosts can still use IP
        addresses to communicate with hosts in other networks 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 domain name to



Expires: 4/1993                                                 [Page 8]


Internet-Draft                                              October 1992


        allow a third party to be involved in the file transfer.

   12)  RPC/SNMP: No modifications are required during the transition
        period when the IP numbers are still unique. The hosts can still
        use IP addresses to communicate with hosts in other networks via
        the translation service. After the transition period, the embed-
        ded the IP addresses have to be replace with domain names.


Support for Old IP Hosts

   Because of the backward compatible nature of EIPIP, EIPIP hosts do
   not have to run dual-stack to communicate with IP hosts.

   The support for old IP hosts can be described in two cases:  1)
   intra-network communications, i.e. the source and destination hosts
   locate within a single network and 2) inter-network communications,
   i.e.  the source and destination hosts locate in two different net-
   work. In each case, there are three scenarios:  1) an IP host sends
   packets to an EIPIP host, 2) an EIPIP host sends packets to an IP
   host, 3) an IP host sends packet to another IP host.


   1)   Intra-Network Communications: EIPIP hosts and IP hosts can com-
        municate with each other in any fashion without any additional
        support. As the source and destination hosts locate within a
        single network, the FTIF chain only contains two FTIFs which are
        that source and destination Network Numbers, i.e. all necessary
        information for packet delivery is present in the minimal IP
        header. Thus, IP and EIPIP are fully compatible within a single
        network.

   2)   Inter-Network Communications: EIPIP hosts and IP hosts can com-
        municate with each other with the support of the translation
        service. When an IP host sends a packet to an EIPIP/IP host in
        another network, the border router will map the network portion
        of the IP address into proper FTIF chain and add the extended
        fields, i.e. translating the IP packet into an EIPIP packet. At
        the destination border, normally the border router does not have
        to translate the packet even it is destined to an IP host,
        except when IHL = 0, i.e. the FTIF chain is so long that the
        packet header length exceeds 60 bytes.

Deployment Plan

   The backward compatible nature of EIPIP significantly reduces the
   complexity of the transition. The upgrade to EIPIP can be achieved in
   a gradual and uncoordinated fashion.



Expires: 4/1993                                                 [Page 9]


Internet-Draft                                              October 1992


   The transition can be divided into two periods:  preparation period
   and transition period.


   1)   Preparation Period:
        a) assign FTIF chain fragments for each current network numbers
        based on the addressing scheme.
        b) update DNS database to add the mapping for the FTIF frag-
        ments.
        c) upgrade and test key hosts in each network before the back-
        bone network changeover. Note that the upgrade of hosts in each
        network does not have to be coordinated as EIPIP hosts can
        traverse the IP Internet without any additional support when IP
        addresses are still unique (see next section for more detail).

   2)   Transition Period:
        a) upgrade all border and backbone routers to EIPIP.
        b) update all DNS servers.
        c) start translation service.
        d) upgrade the rest of hosts and subnet routers gradually.
        f) upgrade the FTP/SNMP/RPC gradually.

   During the transition period, the addresses for new hosts are
   assigned following the IP address rule so that IP addresses are still
   unique. This allows simpler mapping to be used in the transition ser-
   vice.

   When the IP addresses are no longer unique, the IP hosts can only
   communicate within a single network and applications that has embed-
   ded IP addresses such as FTP/SNMP/RPC have to be upgraded.

Implementation Experience


   In this section, we present the experience we had with an experimen-
   tal EIPIP implementation. Note that the implementation was done for a
   demo and was used for experimentation.  The aim of the implementation
   is, therefore, to make minimum modifications to the code rather than
   to achieve high performance.

   We treat current Internet as two levels and use the IP address as the
   EIPIP host number (the host portion of the FTIF chain).  We use the
   network portion of the IP address as the network portion of the FTIF
   chain or look up the network portion of the FTIF chain from a table
   which contains the allocated FTIF fragments. We take the first 8
   characters of the domain name as the endpoint ID.  The handling
   directive is currently set to 0 and routing directive to 1 (level 1).




Expires: 4/1993                                                [Page 10]


Internet-Draft                                              October 1992


   For example, for latour.bellcore.com (128.96.41.50)
   FTIF chain = (128.96.41.50)^(128.96.0.0) EID = latour.b
   Note that the first FTIF (i.e. IP address) is in the minimal IP
   header and the second one in the extended field. Therefore both IP
   routers and can EIPIP routers can forward the packet correctly with
   the same routing information, as long as the IP addresses are still
   unique. As a result, EIPIP packets can traverse current Internet
   without any additional support.

   It turned out that on BSD derived systems, it is possible to generate
   EIPIP packets without any kernel modifications.  This is largely
   because IP kernel code does not check the IP option data passed over
   from the application so that the extended fields can be passed by the
   application program with the existing setsockopt() system call. The
   modifications are just a few lines of c code.

   We created a test program called "eipip" which is based on the ttcp.c
   program. The eipip program can transfer files via four combinations:
   UDP/IP, TCP/IP, UDP/EIPIP, TCP/EIPIP.  The first EIPIP packet was
   sent out on 22 Sept 1992. Various tests have been carried out to
   hosts across the Internet.

   We also modified the tcpdump program for displaying the EIPIP packets
   on ethernets.  The following is an example of the trace that you can
   get from the tcpdump program.

   17:01:12.033548 latour.bellcore.com.2131 > waffle.cs.ucl.ac.uk.echo:
   S 1490432000:1 490432000(0) win 4096 (ttl 47, id 14824
   EIPIP {srcid=latour destid=waffle.c hd=0 rc=1
   ftifs=(128.96.41.50)+(128.96.0.0)+(128.16.0.0)+(128.16.8.88)})

   We are currently enhancing the host demo software to 1) translate the
   IP network number into two levels of FTIF instead of just one, and 2)
   write the IP address into the EID field as specified by [5].

   In addition, we are building a router for demo purposes.  This router
   will be able to route packets based on the Routing Directive created
   by the host demo software.

References

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

   [2]  P. Tsuchiya, "Pip Overview and Examples", Internet Draft,
        June, 1992.

   [3]  P. Tsuchiya, "Pip Header Processing", Internet Draft,



Expires: 4/1993                                                [Page 11]


Internet-Draft                                              October 1992


        Nov 1992.

   [4]  Z. Wang, "EIP: The Extended Internet Protocol -
        a framework for maintaining backward compatibility",
        Internet Draft, June 1992.

   [5]  P. Tsuchiya, "Pip Identifiers", Internet Draft, November
        1992.











































Expires: 4/1993                                                [Page 12]