Internet DRAFT - draft-wang-transition

draft-wang-transition



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 12:06:23 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 09 Dec 1992 04:39:00 GMT
ETag: "3dde64-31c3-2b257864"
Accept-Ranges: bytes
Content-Length: 12739
Connection: close
Content-Type: text/plain





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


               Transition to the Future Internet Protocol
                a comparison of three transition schemes


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

   A number of schemes have been put forward to replace the current IP
   with a new internet protocol. In this memo, we examine the issues in
   the transition to a new internet protocol.  Three schemes are
   compared in detail.

Introduction

   The Internet faces two serious scaling problems: address exhaustion
   and routing explosion.  A number of schemes have been put forward to
   replace the current IP with a new internet protocol [1-6].  However,
   transition to a new internet protocol can be a long and painful
   process. It is important that the transition aspects of the proposed
   schemes be carefully looked at.

   From the perspective of transition, there are two basic approaches
   for the future internet protocol:

   1)   A evolutionary approach that attempts to maintain maximum back-
        ward compatibility in the header format with the current IP and
        minimize the modifications to the current IP systems.



Expires: 12/1992                                                [Page 1]

Internet-Draft                                              October 1992


   2)   A revolutionary approach that simply replaces the current IP
        with a completely new header format.

   EIP and IPAE are two proposals based on the evolutionary approach.
   EIP achieves backward compatibility by making the extended space
   appears a new option to current IP systems [4]. IPAE adds a new layer
   above the IP so that the extended space appears to be user data to
   current IP systems [5].  CNAT outlined a translation mechanism for
   transition to a completely new header format [8].

   In this paper, we look into the three transition strategies:  EIP,
   IPAE and using a completely new header format, and compare the amount
   of modifications needed to current IP systems and the complexity of
   making the new and old systems interoperable.

   Note that EIP and IPAE are examined here as a transition mechanism
   rather than a complete protocol. The issue of routeing and addressing
   are not discussed here.

Scenario One: Using a completely new header format

   In this section, we describe the modifications needed for transition
   to a NewIP with a completely new header format.

   Border Routers:

      a) all border routers have to be upgraded to the NewIP.

   Subnet Routers:

      a) all subnet routers have to be upgraded along the border
         routers.
      b) all subnet routers have to run both IP and NewIP.

   Domain Name Service:

      a) DNS servers have to be modified to provide mapping for new
         addresses.
      b) DNS servers have to provide mapping for both old and new
         addresses depending on the host that requests the mapping.

   Hosts:

      a) the upgraded hosts have to be assigned an new address in
         addition to the current IP address.
      b) the upgraded hosts have to run IP and NewIP in parallel.
      c) the upgraded hosts have to determine whether the destination
         host is upgreaded or not at the beginning of a connection.



Expires: 12/1992                                                [Page 2]

Internet-Draft                                              October 1992


   ARP/RARP:

      a) ARP/RARP header format has to be changed to accommodate
         the new type of addresses.
      b) the upgraded hosts and routers have to run both the old and
         new ARP/RARP protocols.

   ICMP:

      a) ICMP header format has to be changed as the ICMP data
         contains the IP header.
      b) upgraded hosts and routers have to run both old and new
         ICMP protocols.

   TCP/UDP:

      a) the pseudo headers in the checksum have to be modified to
         use the new addresses or set to zero.
      b) the upgraded hosts have to construct different pseudo headers
         depending on whether the destination host is upgraded or not.

   FTP/RPC/SNMP:

      a) the applications that pass addresses as data, such as
         the FTP's DATA PORT (PORT) command used at the beginning
         of each file transfer, have to be changed.


   Translation Service for IP Packets:

      a) the translation has to be done on out-going IP packets.
      b) the translation has to be done on in-coming packets
         destined to IP hosts.

   Translation Service for ICMP Packets:

      a) ICMP packets have to be translated differently from IP
         packets since the ICMP includes the IP header and
         64 bytes data as the ICMP data, and the whole ICMP is then
         encapsulated in the IP header.
      b) if the translation is done by encapsulation, the router
         has to first translate the NewIP packet back to an IP packet,
         then form the ICMP, next encapsulate the ICMP in IP header,
         finally this resultant IP packet is encapsulated in NewIP
         and sent off to the source.
      c) if the translation is done by conversion, the router has
         to convert the NewIP packet back to IP packet, then form the
         ICMP data, next encapsulate the ICMP data into NewIP.



Expires: 12/1992                                                [Page 3]

Internet-Draft                                              October 1992


Scenario Two: Using EIP

   In this section, we describe the modifications needed for transition
   to a NewIP with EIP.

   Border Routers:

      a) all border routers have to be upgraded to the EIP.

   Subnet Routers:

      a) subnet routers do not have to be upgraded as long as the
         IP addresses are still unique.
      b) upgraded subnet routers run EIP only but can handle IP packets
         without any additional changes.

   Domain Name Service:

      a) DNS servers have to be modified to provide mapping for new
         addresses.
      b) only network numbers have to be updated.

   Hosts:

      a) the upgraded hosts needs to be assigned a network number
         and it can use the current IP address as the host number.
      b) the upgraded hosts run EIP only but can handle IP packets
         without additional changes.

   ARP/RARP:

      a) no changes are required.

   ICMP:

      a) no changes to the format are required.
      b) new ICMP messages may be added.

   TCP/UDP:

      a) no changes are required.

   FTP/RPC/SNMP:

      a) the applications that pass addresses as data, such as
         the FTP's DATA PORT (PORT) command used at the beginning
         of each file transfer, do not have to be changed before
         IP addresses run out.



Expires: 12/1992                                                [Page 4]

Internet-Draft                                              October 1992


   Translation Service for IP Packets:

      a) the translation needs to be done on out-going IP packets.
      b) no need for translation on in-coming packets to IP hosts.

   Translation Service for ICMP Packets:

      a) no special treatment is needed for ICMP packets.


Scenario Three: Using IPAE

   In this section, we describe the modifications needed for transition
   to a NewIP with IPAE.

   Border Routers:

      a) all border routers have to be upgraded to IPAE.

   Subnet Routers:

      a) subnet routers do not have to be upgraded as long as the
         IP addresses are still unique.
      b) upgraded subnet routers run IPAE only but can handle IP packets
         without any additional changes.

   Domain Name Service:

      a) DNS servers have to be modified to provide mapping for new
         addresses.
      b) only network numbers have to be updated.

   Hosts:

      a) the upgraded hosts needs to be assigned a network number
         and it can use the current IP address as the host number.
      b) the upgraded hosts run IPAE only but can handle IP packets
         without additional changes.

   ARP/RARP:

      a) no changes are required.

   ICMP:

      a) changes to the format are required (see below Translation
         of ICMP packets for more details).
      b) new ICMP messages may be added.



Expires: 12/1992                                                [Page 5]

Internet-Draft                                              October 1992


   TCP/UDP:

      a) no changes are required.

   FTP/RPC/SNMP:

      a) the applications that pass addresses as data, such as
         the FTP's DATA PORT (PORT) command used at the beginning
         of each file transfer, do not have to be changed before
         IP addresses run out.


   Translation Service for IP Packets:

      a) the translation has to be done on out-going IP packets.
      b) the translation has to be on in-coming packets to IP hosts.

   Translation Service for ICMP Packets:

      a) ICMP packets have to be translated differently from IP
         packets since the ICMP includes the IP header and
         64 bytes data as the ICMP data, and the whole ICMP is then
         encapsulated in the IP header.
      b) The translation has to be done to the IPAE header
         that carries ICMP data and the IPAE header that is
         included inside the ICMP data.
      c) The ICMP packets sent by IP hosts can not be translated
         because the 64-bit data included inside the ICMP data is
         not large enough to carry the network numbers and other
         information for translation [7]. This problem can cause
         programs such as "ping" unworkable.

Discussion

   Using a completely new IP format effectively requires each
   host to run the new and old protocol
   stacks in parallel, which includes FTP/SNMP/RPC,
   UDP/TCP, IP, ARP/RARP, DNS and ICMP.

   EIP and IPAE mainatin some degree of backward compatibility
   by retaining some of the IP packet format. The difference
   between EIP and IPAE lies in ICMP. Since IPAE introduces
   an extra layer between transport and network layers, ICMP
   which has an IP header inside its data is a bit problematic.
   For EIP, ICMP requires no changes at all.

   Another possible difference between EIP and IPAE is that
   EIP allows new fields other than address (e.g. endpoint ids -



Expires: 12/1992                                                [Page 6]

Internet-Draft                                              October 1992


   EIDs) while IPAE does not. This is because IPAE does not use
   the extended fields within a single "commonwealth" while EIP
   allows hosts to use extended fields even within a single
   network.

References

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

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

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

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

   [5]  R. Hinden, D. Crocker, "A Proposal for IP Adress
        Encapsulation (IPAE): A Compatible Version of IP with Large
        Addresses", Internet-draft, July 1992.

   [6]  S. Deering, "Simple Internet Protocol (SIP)", draft note,
        Sept, 1992.

   [7]  C. Partridge, "Re: Note on implementing IPAE",
        in his message to Big-Interent@munnari.oz.au, 17 July 1992.

   [8]  R. Callon, "Overview of a proposal for Internet Addressing
        and Routing", Internet-Draft, March 1992.


Authors' Address:

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

   z.wang@cs.ucl.ac.uk








Expires: 12/1992                                                [Page 7]