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]