1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc1669.txt b/doc/rfc/rfc1669.txt
new file mode 100644
index 0000000..f5b0aba
--- /dev/null
+++ b/doc/rfc/rfc1669.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                          J. Curran
+Request for Comments: 1669                                           BBN
+Category: Informational                                      August 1994
+
+
+                  Market Viability as a IPng Criteria
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This document was submitted to the IETF IPng area in response to RFC
+   1550. Publication of this document does not imply acceptance by the
+   IPng area of any ideas expressed within.  Comments should be
+   submitted to the big-internet@munnari.oz.au mailing list.
+
+Introduction
+
+   In an open marketplace, adoption of new technology is driven by
+   consumer demand.  New technologies that wish to succeed in the
+   marketplace must provide new capabilities or reduced costs to gain
+   consumer confidence.  Internetworking technologies can be
+   particularly difficult to deploy and must provide a correspondingly
+   high return on investment.  In order to determine market viability of
+   new internetworking technology, it's necessary to compare the
+   required deployment effort against the potential benefits as seen by
+   the customer.  "Viability in the Marketplace" is an important
+   requirement for any IPng candidate and this paper is an attempt to
+   summarize some important factors in determing market viability of
+   IPng proposals.
+
+"Pushing" Internetworking Technology
+
+   It has been asserted by some that the adoption of a single IPng
+   protocol by the computing industry would generate general acceptance
+   in the networking industry.  There is ample evidence to support this
+   view; for example, some of the today's more prevalent networking
+   protocols gained initial market acceptance through bundling with
+   computer operating systems (e.g. IP via UNIX, DECNET via VMS, etc.)
+   It should be noted, however, that this approach to technology
+   deployment is by no means assured, and some of today's most popular
+   internetworking software (Novell, etc.) have thrived despite
+   alternatives bundled by computing manufacturers.   Given that IPng
+   will have to compete against an well established and mature
+
+
+
+Curran                                                          [Page 1]
+
+RFC 1669          IPng White Paper on Market Viability       August 1994
+
+
+   internetworking protocol (IP version 4), promotion of an IPng
+   solution by computer system manufacturers should be recognized as
+   highly desirable but not sufficient on its own to ensure IPng
+   acceptance in the marketplace.
+
+Can IPng compete against IPv4?
+
+   Given the large installed base of IPv4 systems, computer system
+   manufacturers will need to continue to provide IPv4 capabilities for
+   the foreseeable future.  With both IPng and IPv4 support in their new
+   systems, users will be facing a difficult choice between using IPv4
+   and IPng for internetworking.  Existing IPv4 users will migrate to
+   IPng for one of three possible reasons:
+
+New functionality not found in IPv4
+
+   IPng needs to provide functionality equivalent to that currently
+   provided by IPv4.  It remains to be seen whether additional
+   functionality (such as resource reservation, mobility,
+   autoconfiguration, autoregistration, or security) will be included in
+   the base specification of any IPng candidate.  In order to provide
+   motivation to migrate to IPng, it will be necessary for IPng
+   proposals to offer capabilities beyond those already provided IPv4.
+
+Reduced costs by using IPng
+
+   It is quite unlikely that migration to IPng will result in cost
+   savings in any organization.  Migration to IPng will certainly result
+   in an increased need for training and engineering, and hence
+   increased costs.
+
+To gain connectivity to otherwise unreachable IPng hosts
+
+   For existing sites with valid IPv4 network assignments, connectivity
+   is not affected until address depletion occurs.  Systems with
+   globally-unique IPv4 addresses will have complete connectivity to any
+   systems since backwards-compatible communication is required of new
+   IPng hosts.
+
+   From the perspective of an existing IPv4 site, IPng provides little
+   tangible benefit until IPv4 address depletion occurs and
+   organizations reachable only via IPng appear.  Given the absence of
+   benefits from migration,  it is uncertain whether a significant base
+   of IPng sites will be occur prior to IPv4 address depletion.
+
+   Sites which are not yet running IP have little motivation to deploy
+   IPng for the immediate future.  As long as IPv4 network assignments
+   are available, new sites have an choice to use IPv4 which provides
+
+
+
+Curran                                                          [Page 2]
+
+RFC 1669          IPng White Paper on Market Viability       August 1994
+
+
+   the sufficient internetworking capabilities (measured in
+   functionality, cost, and connectivity) for many organizations today.
+   Given the parity in IPng and IPv4 capabilities, IPv4 (as a more
+   mature internetworking protocol) is the more probable choice for
+   organizations just now selecting an internetworking protocol.
+
+   Once IPv4 address assignments are no longer available, sites wishing
+   to participate in the global Internet will have a very difficult
+   decision in selection of an internetworking protocol.   The current
+   suite of IPng proposals cannot provide complete internetworking
+   between IPng-only sites and IPv4-only sites since (by definition)
+   there will be insufficient space to map all IPng addresses into the
+   IPv4 address space.  As none of the proposals currently call for
+   dynamic network address translation (NAT), it is inevitable that
+   IPng-only sites will have access to a partial set of IPv4 sites at
+   any given moment.
+
+   Internetworking services which do not allow complete access to the
+   global Internet (IPv4 and IPng in the post-IPv4-address-depletion
+   world) are clearly not as valuable as services which offer complete
+   Internet access.  Sites which are unable to obtain IPv4 network
+   assignments will be seeking Internet services which can provide
+   complete Internet service.   Additionally, some sites will have
+   "privately numbered" IPv4 networks and will desire similar Internet
+   services which provide transparent access to the entire Internet. The
+   development of network address translation devices and subsequent
+   services is highly likely under these market conditions.
+
+Summary
+
+   No internetworking vendor (whether host, router, or service vendor)
+   can afford to deploy and support products and services which are not
+   desired in the marketplace.  Given the potential proliferation of
+   network address translation devices, it is not clear that IPng will
+   secure sufficient following to attain market viability.  In the past,
+   we have seen internetworking protocols fail in the marketplace
+   despite vendor deployment and IPng cannot succeed if it is not
+   deployed by organizations.  As currently envisioned, IPng may not be
+   ambitious enough in the delivery of new capabilities to compete
+   against IPv4 and the inevitable arrival of network address
+   translation devices.  In order to meet the requirement for "viability
+   in the marketplace', IPng needs to deliver clearly improved
+   functionality over IPv4 while offering some form transparent access
+   between the IPv4 and IPng communities once IPv4 address depletion has
+   occurred.
+
+
+
+
+
+
+Curran                                                          [Page 3]
+
+RFC 1669          IPng White Paper on Market Viability       August 1994
+
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address
+
+   John Curran
+   BBN Technology Services, Inc.
+   10 Moulton Street
+   Cambridge MA 02138
+
+   EMail: jcurran@near.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Curran                                                          [Page 4]
+