16. Transition

   The transition of the Internet from IPv4 to IPv6 has to meet two
   separate needs.  There is a short term need to define specific
   technologies and methods to transition IPv4 networks, including the
   Internet, into IPv6 networks and an IPv6 Internet.  There is also a
   long term need to do broad-based operational planning for transition,
   including developing methods to allow decentralized migration

   strategies, understanding the ramifications of a long period of
   coexistence when both protocols are part of the basic infrastructure,
   developing an understanding of the type and scope of architectural
   and interoperability testing that will be required to ensure a
   reliable and manageable Internet in the future.

16.1 Transition - Short Term

   Any IPng transition plan must take into account the realities of what
   types of devices vendors will build and network managers will deploy.
   The IPng transition plan must define the procedures required to
   successfully implement the functions which vendors will be likely to
   include in their devices.  This is the case even if there are good
   arguments to recommend against a particular function, header
   translation for example.  If products will exist it is better to have
   them interoperate than not.

   We recommend that a new IPng Transition (NGTRANS) Working Group be
   formed with Bob Gilligan of Sun Microsystems and xxx of yyy as co-
   chairs to design the mechanisms and procedures to support the
   transition of the Internet from IPv4 to IPv6 and to give advice on
   what procedures and techniques are preferred.

   The work of the group will fall into three areas:

   * Define the processes by which the Internet will make the transition
     from IPv4 to IPv6.  As part of this effort, the group will produce
     a document explaining to the general Internet community what
     mechanisms will be employed in the transition, how the transition
     will work, the assumptions about infrastructure deployment inherent
     in the operation of these mechanisms, and the types of
     functionality that applications developers will be able to assume
     as the protocol mix changes over time.
   * Define and specify the mandatory and optional mechanisms that
     vendors should implement in hosts, routers, and other components of
     the Internet in order for the transition to be carried out. Dual-
     stack, encapsulation and header translation mechanisms must all be
     defined, as well as the interaction between hosts using different
     combinations of these mechanisms.  The specifications produced will
     be used by people implementing these IPv6 systems.
   * Articulate a concrete operational plan for the Internet to make the
     transition from IPv4 to IPv6.  The result of this work will be a
     transition plan for the Internet that network operators and
     Internet subscribers can execute.
                                                             [Gillig94c]

   The working group is expected to complete its work around the end of
   1994 and disband at that time.  The group will use the "Simple SIPP
   Transition (SST)" [Gilig94a] overview document as the starting point
   for its work.

16.2 Transition - Long Term

   There are a number of transition related topics in addition to
   defining the specific IPv4 to IPv6 mechanisms and their deployment,
   operation and interaction.  The ramifications and procedures of
   migrating to a new technology or to a new version of an existing
   technology must be fully understood.

   We recommend that the Transition and Coexistence Including Testing
   (TACIT) Working Group, which was started a few months ago, explore
   some of the basic issues associated with the deployment of new
   technology into an established Internet.  The TACIT Working Group
   will focus on the generic issues of transition and will not limit
   itself to the upcoming transition to IPv6 because, over time,
   enhancements to IPv6 (IPv6ng) will be developed and accepted.  At
   that point they will need to be deployed into the then existing
   Internet.  The TACIT Working Group will be more operationally
   oriented than the NGTRANS Working Group and will continue well into
   the actual IPv6 transition.

   The main areas of exploration are:

   * Make the transition from a currently deployed protocol to a new
     protocol while accommodating heterogeneity and decentralized
     management.
   * Since it is often difficult or impossible to replace all legacy
     systems or software, it is important to understand the
     characteristics and operation of a long period of coexistence
     between a new protocol and the existing protocol.
   * The Internet must now be considered a utility.  We are far removed
     from a time when a new technology could be deployed to see if it
     would work in large scale situations.  Rigorous architectural and
     interoperability testing must be part of the predeployment phase of
     any proposed software for the Internet. Testing the scaling up
     behaviors and robustness of a new protocol will offer particular
     challenges. The WG should determine if there are lessons to be
     learned from:  OSPF, BGP4 and CIDR Deployment, the AppleTalk 1 to 2
     transition, DECnet Phase 4 to Phase 5 planning and transition,
     among others.

   The TACIT Working Group will explore each of these facets of the
   deployment of new technology and develop a number of documents to
   help guide users and managers of affected data networks and provide
   to the IETF:

   * Detailed descriptions of problem areas in transition and
     coexistence, both predicted, based on lessons learned, and observed
     as the IPv6 process progresses.
   * Recommendations for specific testing procedures.
   * Recommendations for coexistence operations procedures
   * Recommendations for the smoothing of decentralized transition
     planning.
                                                         [Huston94]

17. Other Address Families

   There are many environments in which there are one or more network
   protocols already deployed or where a significant planning effort has
   been undertaken to create a comprehensive network addressing plan. In
   such cases there may be a temptation to integrate IPv6 into the
   environment by making use of an existing addressing plan to define
   all or part of the IPv6 addresses.  The advantage of doing this is
   that it permits unified management of address space among multiple
   protocol families.  The use of common addresses can help facilitate
   transition from other protocols to IPv6.

   If the existing addresses are globally unique and assigned with
   regard to network topology this may be a reasonable idea.  The IETF
   should work with other organizations to develop algorithms that could
   be used to map addresses between IPv6 and other environments.  The
   goal for any such mapping must be to provide an unambiguous 1 to 1
   map between individual addresses.

   Suggestions have been made to develop mapping algorithms for Novell
   IPX addresses, some types of OSI NSAPs, E164 addresses and SNA
   addresses.  Each of these possibilities should be carefully examined
   to ensure that use of such an algorithm solves more problems than it
   creates.  In some cases it may be better to recommend either that a
   native IPng addressing plan be developed instead, or that an IPv6
   address be used within the non-IP environment. [Carpen94b]

   We recommend that, in conjunction with other organizations,
   recommendations about the use of non-IPv6 addresses in IPv6
   environments and IPv6 addresses in non-IPv6 environments be
   developed.

18. Impact on Other IETF Standards

   Many current IETF standards are affected by IPv6.  At least 27 of the
   current 51 full Internet Standards must be revised for IPv6, along
   with at least 6 of the 20 Draft Standards and at least 25 of the 130
   Proposed Standards. [Postel94]

   In some cases the revisions consist of simple changes to the text,
   for example, in a number of RFCs an IP address is referred to in
   passing as a "32 bit IP address" even though IP addresses are not
   directly used in the protocol being defined.  All of the standards
   track documents will have to be checked to see if they contain such
   references.

   In most of the rest of the cases revisions to the protocols,
   including packet formats, will be required.  In many of these cases
   the address is just being carried as a data element and a revised
   format with a larger field for the address will have no effect on the
   functional paradigm.

   In the remaining cases some facet of the operation of the protocol
   will be changed as a result of IPv6.  For example, the security and
   source route mechanisms are fundamentally changed from IPv4 with
   IPv6.  Protocols and applications that relied on the IPv4
   functionality will have to be redesigned or rethought to use the
   equivalent function in IPv6.

   In a few cases this opportunity should be used to determine if some
   of the RFCs should be moved to historic, for example EGP [Mills84]
   and IP over ARCNET. [Provan91]

   The base IPng Working Group will address some of these, existing IETF
   working groups can work on others, while new working groups must be
   formed to deal with a few of them. The IPng Working Group will be
   responsible for defining new versions of ICMP, ARP/RARP, and UDP.  It
   will also review RFC 1639, "FTP Operation Over Big Address Records
   (FOOBAR)" [Piscit94] and RFC 1191 "Path MTU Discovery" [Mogul90]

   Existing working groups will examine revisions for some of the
   routing protocols: RIPv2, IS-IS, IDRP and SDRP.  A new working group
   may be required for OSPF.

   The existing DHCP Working Group may be able to revise DHCP and
   examine BOOTP.

   A TCPng Working Group will be formed soon, and new working groups
   will have to be formed to deal with standards such as SNMP, DNS, NTP,
   NETbios, OSI over TCP, Host Requirements, and Kerberos as well as
   reviewing most of the RFCs that define IP usage over various media.

   In addition to the standards track RFCs mentioned above there are
   many Informational and Experimental RFCs which would be affected as
   well as numerous Internet Drafts (and those standards track RFCs that
   we missed).

   We recommend that the IESG commission a review of all standards track
   RFCs to ensure that a full list of affected documents is compiled. We
   recommend that the IESG charge current IETF working groups with the
   task of understanding the impact of IPv6 on their proposals and,
   where appropriate, revise the documents to include support for IPv6.

   We recommend that the IESG charter new working groups where required
   to revise other standards RFCs.

19. Impact on non-IETF standards and on products

   Many products and user applications which rely on the size or
   structure of IPv4 addresses will need to be modified to work with
   IPv6.  While the IETF can facilitate an investigation of the impacts
   of IPv6 on non-IETF standards and products, the primary
   responsibility for doing so resides in the other standards bodies and
   the vendors.

   Examples of non-IETF standards that are effected by IPv6 include the
   POSIX standards, Open Software Foundation's DCE and DME, X-Open, Sun
   ONC, the Andrew File System and MIT's Kerberos.  Most products that
   provide specialized network security including firewall-type devices
   are among those that must be extended to support IPv6.

20. APIs

   It is traditional to state that the IETF does not "do" APIs.  While
   there are many reasons for this, the one most commonly referenced is
   that there are too many environments where TCP/IP is used, too many
   different operating systems, programming languages, and platforms.
   The feeling is that the IETF should not get involved in attempting to
   define a language and operating system independent interface in the
   face of such complexity.

   We feel that this historical tendency for the IETF to avoid dealing
   with APIs should be reexamined in the case of IPv6.  We feel that in
   a few specific cases the prevalence of a particular type of API is
   such that  a single common solution for the modifications made

   necessary by IPv6 should be documented.

   We recommend that Informational RFCs be solicited or developed for
   these few cases.  In particular, the Berkeley-style sockets
   interface, the UNIX TLI and XTI interfaces, and the WINSOCK
   interfaces should be targeted.  A draft document exists which could
   be developed into the sockets API description. [Gillig94b]

21. Future of the IPng Area and Working Groups

   In our presentation at the Houston IETF meeting we stated that the
   existing IPng proposal working groups would not be forced to close
   down after the recommendation was made.  Each of them has been
   working on technologies that may have applications in addition to
   their IPng proposal and these technologies should not be lost.

   Since the Toronto IETF meeting the existing IPng working groups have
   been returned to the Internet Area.  The group members may decide to
   close down the working groups or to continue some of their efforts.
   The charters of the working groups must be revised if they choose to
   continue since they would no longer be proposing an IPng candidate.

   In Toronto the chairs of the SIPP Working Group requested that the
   SIPP Working Group be concluded.  The chairs of the TUBA Working
   Group requested that the TUBA working group be understood to be in
   hiatus until a number of the documents in process were completed, at
   which time they would request that the working group be concluded.

   We recommend that the IPng Area and its Directorate continue until
   the basic documents have entered the standards track in late 1994 or
   early 1995 and that after such time the area be dissolved and those
   IPng Area working groups still active be moved to their normal IETF
   areas.

22. Security Considerations

   The security of the Internet has long been questioned.  It has been
   the topic of much press coverage, many conferences and workshops.
   Almost all of this attention has been negative, pointing out the many
   places where the level of possible security is far less than that
   deemed necessary for the current and future uses of the Internet. A
   number of the RFC 1550 White Papers specifically pointed out the
   requirement to improve the level of security available [Adam94,
   Bell94b, Brit94, Green94, Vecchi94, Flei94] as does "Realizing the
   Information Future". [Nat94]

   In February of 1994, the IAB convened a workshop on security in the
   Internet architecture.  The report of this workshop [IAB94] includes
   an exploration of many of the security problem areas and makes a
   number of recommendations to improve the level of security that the
   Internet offers its users.

   We feel that an improvement in the basic level of security in the
   Internet is vital to its continued success.  Users must be able to
   assume that their exchanges are safe from tampering, diversion and
   exposure.  Organizations that wish to use the Internet to conduct
   business must be able to have a high level of confidence in the
   identity of their correspondents and in the security of their
   communications.  The goal is to provide strong protection as a matter
   of course throughout the Internet.

   As the IAB report points out, many of the necessary tools are not a
   function of the internetworking layer of the protocol.  These higher
   level tools could make use of strong security features in the
   internetworking layer if they were present. While we expect that
   there will be a number of special high-level security packages
   available for specific Internet constituencies, support for basic
   packet-level authentication will provide for the adoption of a much
   needed, widespread, security infrastructure throughout the Internet.

   It is best to separate the support for authentication from the
   support for encryption.  One should be able to use the two functions
   independently.  There are some applications in which authentication
   of a corespondent is sufficient and others where the data exchanged
   must be kept private.

   It is our recommendation that IPv6 support packet authentication as a
   basic and required function.  Applications should be able to rely on
   support for this feature in every IPv6 implementation.  Support for a
   specific authentication algorithm should also be mandated while
   support for additional algorithms should be optional.

   Thus we recommend that support for the Authentication Header be
   required in all compliant IPv6 implementations.

   We recommend that support for a specific authentication algorithm be
   required.  The specific algorithm should be determined by the time
   the IPv6 documents are offered as Proposed Standards.

   We recommend that support for the Privacy Header be required in IPv6
   implementations.

   We recommend that support for a privacy authentication algorithm be
   required. The specific algorithm should be determined by the time the
   IPv6 documents are offered as Proposed Standards.

   Clearly, a key management infrastructure will be required in order to
   enable the use of the authentication and encryption headers.
   However, defining such an infrastructure is outside the scope of the
   IPv6 effort.  We do note that there are on-going IETF activities in
   this area. The IPv6 transition working groups must coordinate with
   these activities.

   Just as clearly, the use of authentication and encryption may add to
   the cost and impact the performance of systems but the more secure
   infrastructure is worth the penalty.  Whatever penalty there is
   should also decrease in time with improved software and hardware
   assistance.

   The use of firewalls is increasing on the Internet.  We hope that the
   presence of the authentication and privacy features in IPv6 will
   reduce the need for firewalls, but we do understand that they will
   continue to be used for the foreseeable future.  In this light, we
   feel that clear guidance should be given to the developers of
   firewalls on the best ways to design and configure them when working
   in an IPv6 environment.

   We recommend that an "IPv6 framework for firewalls" be developed.
   This framework should explore the ways in which the Authentication
   Header can be used to strengthen firewall technology and detail how
   the IPv6 packet should be analyzed by a firewall.

   Some aspects of security require additional study.  For example, it
   has been pointed out [Vecchi94] that, even in non-military
   situations, there are places where procedures to thwart traffic
   analysis will be required.  This could be done by the use of
   encrypted encapsulation, but this and other similar requirements must
   be addressed on an on-going basis by the Security Area of the IETF.
   The design of IPv6 must be flexible enough to support the later
   addition of such security features.

   We believe that IPv6 with its inherent security features will provide
   the foundation upon which the Internet can continue to expand its
   functionality and user base.

23. Authors' Addresses

   Scott Bradner
   Harvard University
   10 Ware St.
   Cambridge, MA 02138

   Phone: +1 617 495 3864
   EMail: sob@harvard.edu


   Allison Mankin
   USC/Information Sciences Institute
   4350 North Fairfax Drive, Suite 400
   Arlington, VA 22303

   Phone: +1 703-807-0132
   EMail: mankin@isi.edu

Appendix A - Summary of Recommendations

   5.3 Address Assignment Policy Recommendations
      changes in address assignment policies are not recommended
      reclamation of underutilized assigned addresses is not currently
         recommended
      efforts to renumber significant portions of the Internet are not
         currently recommended
      recommend consideration of assigning CIDR-type address blocks out
         of unassigned Class A addressees
   11. IPng Recommendation
      recommend that "Simple Internet Protocol Plus (SIPP) Spec. (128
         bit ver)" [Deering94b] be adopted as the basis for IPng
      recommend that the documents listed in Appendix C be the basis of
         IPng
   13. IPng Working Group
      recommend that an IPng Working Group be formed, chaired by Steve
         Deering and Ross Callon
      recommend that Robert Hinden be the document editor for the IPng
         effort
   14. IPng Reviewer
      recommend that an IPng Reviewer be appointed and that Dave Clark
         be that reviewer
   15. Address Autoconfiguration
      recommend that an Address Autoconfiguration Working Group be
         formed, chaired by Dave Katz and Sue Thomson
   16.1 Transition - Short Term
      recommend that an IPng Transition Working Group be formed, chaired
         by Bob Gilligan and TBA
   16.2 Transition - Long Term
      recommend that the Transition and Coexistence Including Testing
         Working Group be chartered
   17. Other Address Families
      recommend that recommendations about the use of non-IPv6 addresses
         in IPv6 environments and IPv6 addresses in non-IPv6
         environments be developed
   18. Impact on Other IETF Standards
      recommend the IESG commission a review of all standards track RFCs
      recommend the IESG charge current IETF working groups with the
         task of understanding the impact of IPng on their proposals
         and, where appropriate, revise the documents to include support
         for IPng
      recommend the IESG charter new working groups where required to
         revise other standards RFCs
   20. APIs
      recommend that Informational RFCs be developed or solicited for a
         few of the common APIs

   21. Future of the IPng Area and Working Groups
      recommend that the IPng Area and Area Directorate continue until
         main documents are offered as Proposed Standards in late 1994
   22. Security Considerations
      recommend that support for the Authentication Header be required
      recommend that support for a specific authentication algorithm be
         required
      recommend that support for the Privacy Header be required
      recommend that support for a specific privacy algorithm be
         required
      recommend that an "IPng framework for firewalls" be developed

Appendix B - IPng Area Directorate

   J. Allard - Microsoft           <jallard@microsoft.com>
   Steve Bellovin  - AT&T          <smb@research.att.com>
   Jim Bound  - Digital            <bound@zk3.dec.com>
   Ross Callon  - Wellfleet        <rcallon@wellfleet.com>
   Brian Carpenter  - CERN         <brian.carpenter@cern.ch>
   Dave Clark  - MIT               <ddc@lcs.mit.edu >
   John Curran  - NEARNET          <curran@nic.near.net>
   Steve Deering  - Xerox          <deering@parc.xerox.com>
   Dino Farinacci  - Cisco         <dino@cisco.com>
   Paul Francis - NTT              <francis@slab.ntt.jp>
   Eric Fleischmann  - Boeing      <ericf@atc.boeing.com>
   Mark Knopper - Ameritech        <mak@aads.com>
   Greg Minshall  - Novell         <minshall@wc.novell.com>
   Rob Ullmann - Lotus             <ariel@world.std.com>
   Lixia Zhang  - Xerox            <lixia@parc.xerox.com>

   Daniel Karrenberg of RIPE joined the Directorate when it was formed
   but had to withdraw due to the demands of his day job.

   Since the Toronto IETF meeting Paul Francis has resigned from the
   Directorate to pursue other interests.  Robert Hinden of Sun
   Microsystems and Yakov Rekhter of IBM joined.

Appendix C - Documents Referred to the IPng Working Groups

   [Deering94b] Deering, S., "Simple Internet Protocol Plus (SIPP) Spec.
      (128 bit ver)", Work in Progress.

   [Francis94] Francis, P., "SIPP Addressing Architecture", Work in
      Progress.

   [Rekhter94] Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast
      Address Allocation", Work in Progress.

   [Gillig94a] Gilligan, R., "Simple SIPP Transition (SST) Overview",
      Work in Progress.

   [Gillig94b] Gilligan, R., Govindan, R., Thomson, S., and J. Bound,
      "SIPP Program Interfaces for BSD Systems", Work in Progress.

   [Atkins94a] Atkinson, R., "SIPP Security Architecture", Work in
      Progress.

   [Atkins94b] Atkinson, R., "SIPP Authentication Header", Work in
      Progress.

   [Ford94b] Ford, P., Li, T., and Y. Rekhter, "SDRP Routing Header for
      SIPP-16", Work in Progress.

   [Hinden94c] Hinden, R., "IP Next Generation Overview", Work in
      Progress.

Appendix D - IPng Proposal Overviews

   [Ford94a] Ford, P., and M. Knopper, "TUBA as IPng: A White Paper",
      Work in Progress.

   [Hinden94a] Hinden, R., "Simple Internet Protocol Plus White Paper",
      RFC 1710, Sun Microsystems, October 1994.

   [McGovern94] McGovern, M., and R. Ullmann, "CATNIP: Common
      Architecture for the Internet", RFC 1707, Sunspot Graphics, Lotus
      Development Corp., October 1994.

Appendix E - RFC 1550 White Papers

   [Adam94] Adamson, B., "Tactical Radio Frequency Communication
      Requirements for IPng", RFC 1677, NRL, August 1994.

   [Bello94a] Bellovin, S., "On Many Addresses per Host", RFC 1681, AT&T
      Bell Laboratories, August 1994.

   [Bello94b] Bellovin, S., "Security Concerns for IPng", RFC 1675, AT&T
      Bell Laboratories, August 1994.

   [Bound94] Bound, J., "IPng BSD Host Implementation Analysis", RFC
      1682, Digital Equipment Corporation, August 1994.

   [Brazd94] Brazdziunas, C., "IPng Support for ATM Services", RFC 1680,
      Bellcore, August 1994.

   [Britt94] Britton, E., and J. Tavs, "IPng Requirements of Large
      Corporate Networks", RFC 1678, IBM, August 1994.

   [Brownl94] Brownlee, J., "Accounting Requirements for IPng", RFC
      1672, University of Auckland, August 1994.

   [Carpen94a] Carpenter, B., "IPng White Paper on Transition and Other
      Considerations", RFC 1671, CERN, August 1994.

   [Chiappa94] Chiappa, N., "IPng Technical Requirements Of the Nimrod
      Routing and Addressing Architecture", RFC 1753, December 1994.

   [Clark94] Clark, R., Ammar, M., and K. Calvert, "Multiprotocol
      Interoperability In IPng", RFC 1683, Georgia Institute of
      Technology, August 1994.

   [Curran94] Curran, J., "Market Viability as a IPng Criteria", RFC
      1669, BBN, August 1994.

   [Estrin94a] Estrin, D., Li, T., and Y. Rekhter, "Unified Routing
      Requirements for IPng", RFC 1668, USC, cisco Systems, IBM, August
      1994.

   [Fleisch94] Fleischman, E., "A Large Corporate User's View of IPng",
      RFC 1687, Boeing Computer Services, August 1994.

   [Green94] Green, D., Irey, P., Marlow, D., and K. O'Donoghue, "HPN
      Working Group Input to the IPng Requirements Solicitation", RFC
      1679, NSWC-DD, August 1994.

   [Ghisel94] Ghiselli, A., Salomoni, D., and C. Vistoli, "INFN
      Requirements for an IPng", RFC 1676, INFN/CNAF, August 1994.

   [Heager94] Heagerty, D., "Input to IPng Engineering Considerations",
      RFC 1670, CERN, August 1994.

   [Simpson94] Simpson, W. "IPng Mobility Considerations", RFC 1688,
      Daydreamer, August 1994.

   [Skelton94] Skelton, R., "Electric Power Research Institute Comments
      on IPng", RFC 1673, EPRI, August 1994.

   [Syming94] Symington, S., Wood, D., and J. Pullen, "Modeling and
      Simulation Requirements for IPng", RFC 1667, MITRE, George Mason
      University, August 1994.

   [Taylor94] Taylor, M., "A Cellular Industry View of IPng", RFC 1674,
      CDPD Consortium, August 1994.

   [Vecchi94] Vecchi, M., "IPng Requirements: A Cable Television
      Industry Viewpoint", RFC 1686, Time Warner Cable, August 1994.

Appendix F - Additional References

   [Almqu92] Almquist, P., "Minutes of the Selection Criteria BOF",
      Washington DC IETF, November 1992, (ietf/nov92/select-minutes-
      92nov.txt).

   [Berkow94] Berkowitz, H., "IPng and Related Plug-and-Play Issues and
      Requirements", Work in Progress, September 1994.

   [Bos94] Bos, E. J., "Minutes of the Address Lifetime Expectations BOF
      (ALE)", Seattle IETF, March 1994, (ietf/ale/ale-minutes-
      94mar.txt).

   [Big] Archives of the big-internet mailing list, on munnari.oz.au in
      big-internet/list-archives.

   [Bradner93] Bradner, S., and A. Mankin, "IP: Next Generation (IPng)
      White Paper Solicitation", RFC 1550, Harvard University, NRL,
      December 1993.

   [Callon87] Callon, R., "A Proposal for a Next Generation Internet
      Protocol", Proposal to X3S3, December 1987.

   [Callon92a] Callon, R., "CNAT", Work in Progress.

   [Callon92b] Callon, R., "Simple CLNP", Work in Progress.

   [Callon92c] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A
      Simple Proposal for Internet Addressing and Routing", RFC 1347,
      DEC, June 1992.

   [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision
      Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt,
      August 1993.

   [Carpen94b] Carpenter, B, and J. Bound, "Recommendations for OSI NSAP
      usage in IPv6", Work in Progress.

   [Chiappa91]  Chiappa, J., "A New IP Routing and Addressing
      Architecture", Work in Progress.

   [Clark91] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby,
      "Towards the Future Internet Architecture", RFC 1287, MIT, BBN,
      CNRI, ISI, UC Davis, December 1991.

   [Deering92] Deering, S., "The Simple Internet Protocol", Big-Internet
      mailing list, 22 Sept. 1992.

   [Deering94a] Deering, S., and P. Francis, Message to sipp mailing
      list, 31 May 1994.

   [Estrin94b] Estrin, D., Zappala, D., Li, T., Rekhter, Y., and K.
      Varadhan, "Source Demand Routing: Packet Format and Forwarding
      Specification (Version 1)" Work in Progress.

   [Fuller93] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
      Inter-Domain Routing (CIDR): an Address Assignment and Aggregation
      Strategy", RFC 1519, BARRNet, cisco Systems, MERIT, OARnet,
      September 1993.

   [Gillig94c] Gilligan, B., "IPng Transition (ngtrans)", Work in
      Progress.

   [Gross92] Gross, P., and P. Almquist, "IESG Deliberations on Routing
      and Addressing", RFC 1380, ANS, Stanford University, November
      1992.

   [Gross94] Gross, P. "A Direction for IPng", RFC 1719, MCI, December
      1994.

   [Hinden92a] Hinden, R., "New Scheme for Internet Routing and
      Addressing (ENCAPS)", Work in Progress.

   [Hinden94b] Hinden, R., Deering, S., and P. Francis, "Simple Internet
      Protocol Plus", Working Group Charter, April 1994.

   [Hinden92b] Hinden, R., and D. Crocker, "A Proposal for IP Address
      Encapsulation (IPAE): A Compatible version of IP with Large
      Addresses", Work in Progress.

   [Huston94] Huston, G., and A. Bansal, draft charter for the
      "Transition and Coexistence Including Testing (TACIT) Working
      Group, June 1994.

   [Huitema93] Huitema, C., "IAB Recommendations for an Intermediate
      Strategy to Address the Issue of Scaling", RFC 1481, INRIA, July
      1993.

   [Huitema94] Huitema, C., "The H ratio for address assignment
      efficiency", RFC 1715, INRIA, October 1994.

   [IAB92] Internet Architecture Board, "IP Version 7", Work in
      Progress.

   [IAB94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
      of IAB Workshop on Security in the Internet Architecture -
      February 8-10, 1994", RFC 1636, USC/Informaiton Sciences
      Institute, MIT Laboratory for Computer Science, Trusted
      Information Systems, Inc., INRIA, IAB Chair, June 1994.

   [Kasten92] Kastenholz, F, and C. Partridge, "IPv7 Technical
      Criteria", Work in Progress.

   [Kasten94] Partridge, C., and F. Kastenholz, "Technical Criteria for
      Choosing IP: The Next Generation (IPng)", RFC 1726, BBN Systems
      and Technologies, FTP Software, December 1994.

   [Knopper94a] Knopper, M., and P. Ford, "TCP/UDP Over CLNP-Addressed
      Networks (TUBA)", Working Group Charter, January 1994.

   [Knopper94b] Knopper, M., and D. Piscitello, "Minutes of the BigTen
      IPng Retreat, May 19 & 20 1994".

   [Leiner93] Leiner, B., and Y. Rekhter, "The MultiProtocol Internet",
      RFC 1560, USRA, IBM, December 1993.

   [Mankin94] Mankin, A., and S. Bradner, message to big-internet, tuba,
      sipp, catnip and ietf mailing lists, 7 July 1994.

   [Mills84] Mills, D. "Exterior Gateway Protocol Formal Specification",
      RFC 904, UDEL, April 1984.

   [Mogul90] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
      DECWRL, Stanford University, November 1990.

   [Nat94] National Research Council, "Realizing the Information Future:
      The Internet and Beyond", National Academy Press, 1994.

   [Piscit94] Piscitello, D., "FTP Operation Over Big Address Records
      (FOOBAR)", RFC 1639, Core Competence, June 1994.

   [Provan91] Provan, D., "Transmitting IP Traffic over ARCNET
      Networks", RFC 1051, Novell, February 1991.

   [Postel94] Postel, J., Editor, "Internet Official Protocol
      Standards", RFC 1720, USC/Information Sciences Institute, November
      1994.

   [Solens93a] Solensky, F., and T. Li, "Charter for the Address
      Lifetime Expectations Working Group", FTP Software, Cisco Systems,
      November 1993.

   [Solens93b] Solensky, F., "Minutes of the Address Lifetime
      Expectations BOF (ALE)", Houston IETF, November 1993,
      (ietf/ale/ale-minutes-93nov.txt).

   [Solens94] Solensky, F., "Minutes of the Address Lifetime
      Expectations BOF (ALE)", Toronto IETF, July 1994, (ietf/ale/ale-
      minutes-94jul.txt).

   [Sukonnik94] Sukonnik, V., "Common Architecture for Next-Generation
      IP (catnip), Working Group Charter, April 1994.

   [Tsuchiya92] Tsuchiya, P., "The 'P' Internet Protocol", Work in
      Progress.

   [Ullmann93] Ullmann, R., "TP/IX: The Next Internet", RFC 1475,
      Process Software Corporation, June 1993.

Appendix G - Acknowledgments

   Reaching this stage of the recommendation would not have been even
   vaguely possible without the efforts of many people.  In particular,
   the work of IPng Directorate (listed in Appendix B), Frank Kastenholz
   and Craig Partridge (the authors of the Criteria document) along with
   Jon Crowcroft (who co-chaired the ngreq BOF) was critical.  The work
   and cooperation of the chairs, members and document authors of the
   three IPng proposal working groups, the ALE working group and the
   TACIT working group laid the groundwork upon which this
   recommendation sits.

   We would also like to thank the many people who took the time to
   respond to RFC1550 and who provided the broad understanding of the
   many requirements of data networking that any proposal for an IPng
   must address.

   The members of the IESG, the IAB, and the always active participants
   in the various mailing lists provided us with many insights into the
   issues we faced.

   Many other individuals gave us sometimes spirited but always useful
   counsel during this process.  They include (in no particular order)
   Radia Perlman, Noel Chiappa, Peter Ford, Dave Crocker, Tony Li, Dave
   Piscitello, Vint Cerf and Dan Lynch.

   Thanks to David Williams and Cheryl Chapman who took on the
   occasionally impossible task of ensuring that what is written here
   resembles English to some degree.

   To all of the many people mentioned above and those we have skipped
   in our forgetfulness, thank you for making this task doable.