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: firstname.lastname@example.org Allison Mankin USC/Information Sciences Institute 4350 North Fairfax Drive, Suite 400 Arlington, VA 22303 Phone: +1 703-807-0132 EMail: email@example.com
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 <firstname.lastname@example.org> Steve Bellovin - AT&T <email@example.com> Jim Bound - Digital <firstname.lastname@example.org> Ross Callon - Wellfleet <email@example.com> Brian Carpenter - CERN <firstname.lastname@example.org> Dave Clark - MIT <email@example.com > John Curran - NEARNET <firstname.lastname@example.org> Steve Deering - Xerox <email@example.com> Dino Farinacci - Cisco <firstname.lastname@example.org> Paul Francis - NTT <email@example.com> Eric Fleischmann - Boeing <firstname.lastname@example.org> Mark Knopper - Ameritech <email@example.com> Greg Minshall - Novell <firstname.lastname@example.org> Rob Ullmann - Lotus <email@example.com> Lixia Zhang - Xerox <firstname.lastname@example.org> 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.