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.
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
* 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,
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
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
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
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
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
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 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
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.
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
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
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
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
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
10 Ware St.
Cambridge, MA 02138
Phone: +1 617 495 3864
USC/Information Sciences Institute
4350 North Fairfax Drive, Suite 400
Arlington, VA 22303
Phone: +1 703-807-0132
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
efforts to renumber significant portions of the Internet are not
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
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
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
recommend the IESG charter new working groups where required to
revise other standards RFCs
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
recommend that support for the Privacy Header be required
recommend that support for a specific privacy algorithm be
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
[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
[Atkins94b] Atkinson, R., "SIPP Authentication Header", Work in
[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
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
[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-
[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-
[Big] Archives of the big-internet mailing list, on munnari.oz.au in
[Bradner93] Bradner, S., and A. Mankin, "IP: Next Generation (IPng)
White Paper Solicitation", RFC 1550, Harvard University, NRL,
[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,
[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,
[Gillig94c] Gilligan, B., "IPng Transition (ngtrans)", Work in
[Gross92] Gross, P., and P. Almquist, "IESG Deliberations on Routing
and Addressing", RFC 1380, ANS, Stanford University, November
[Gross94] Gross, P. "A Direction for IPng", RFC 1719, MCI, December
[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
[Huitema94] Huitema, C., "The H ratio for address assignment
efficiency", RFC 1715, INRIA, October 1994.
[IAB92] Internet Architecture Board, "IP Version 7", Work in
[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
[Solens93a] Solensky, F., and T. Li, "Charter for the Address
Lifetime Expectations Working Group", FTP Software, Cisco Systems,
[Solens93b] Solensky, F., "Minutes of the Address Lifetime
Expectations BOF (ALE)", Houston IETF, November 1993,
[Solens94] Solensky, F., "Minutes of the Address Lifetime
Expectations BOF (ALE)", Toronto IETF, July 1994, (ietf/ale/ale-
[Sukonnik94] Sukonnik, V., "Common Architecture for Next-Generation
IP (catnip), Working Group Charter, April 1994.
[Tsuchiya92] Tsuchiya, P., "The 'P' Internet Protocol", Work in
[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
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
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.