doc: Add RFC documents

1 files changed, 451 insertions, 0 deletions

diff --git a/doc/rfc/rfc1671.txt b/doc/rfc/rfc1671.txt
new file mode 100644
index 0000000..ab77a10
--- /dev/null
+++ b/doc/rfc/rfc1671.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                       B. Carpenter
+Request for Comments: 1671                                          CERN
+Category: Informational                                      August 1994
+
+
+        IPng White Paper on Transition and Other Considerations
+
+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.
+
+Summary
+
+   This white paper outlines some general requirements for IPng in
+   selected areas. It identifies the following requirements for stepwise
+   transition:
+
+   A) Interworking at every stage and every layer.
+   B) Header translation considered harmful
+   C) Coexistence.
+   D) IPv4 to IPng address mapping.
+   E) Dual stack hosts.
+   F) DNS.
+   G) Smart dual-stack code.
+   H) Smart management tools.
+
+   Some remarks about phsysical and logical multicast follow, and it is
+   suggested that a model of how IPng will run over ATM is needed.
+
+   Finally, the paper suggests that the requirements for policy routing,
+   accounting, and security firewalls will in turn require all IPng
+   packets to carry a trace of the type of transaction involved as well
+   as of their source and destination.
+
+Transition and deployment
+
+   It is clear that the transition will take years and that every site
+   will have to decide its own staged transition plan. Only the very
+   smallest sites could envisage a single step ("flag day") transition,
+
+
+
+Carpenter                                                       [Page 1]
+
+RFC 1671          IPng White Paper on Transition, etc.       August 1994
+
+
+   presumably under pressure from their Internet service providers.
+   Furthermore, once the IPng decision is taken, the next decade (or
+   more) of activity in the Internet and in all private networks using
+   the Internet suite will be strongly affected by the process of IPng
+   deployment. User sites will look at the decision whether to change
+   from IPv4 in the same way as they have looked in the past at changes
+   of programming language or operating system. It may not be a foregone
+   conclusion that what they change to is IPng.  Their main concern will
+   be to minimise the cost of the change and the risk of lost
+   production.
+
+   This concern immediately defines strong constraints on the model for
+   transition and deployment of IPng. Some of these constraints are
+   listed below, with a short explanation of each one.
+
+   Terminology: an "IPv4 host" is a host that runs exactly what it runs
+   today, with no maintenance releases and no configuration changes. An
+   "IPng host" is a host that has a new version of IP, and has been
+   reconfigured.  Similarly for routers.
+
+   A) Interworking at every stage and every layer.
+
+   This is the major constraint. Vendors of computer systems, routers,
+   and applications software will certainly not coordinate their product
+   release dates. Users will go on running their old equipment and
+   software.  Therefore, any combination of IPv4 and IPng hosts and
+   routers must be able to interwork (i.e., participate in UDP and TCP
+   sessions). An IPv4 packet must be  able to find its way from any IPv4
+   host, to any other IPv4 or IPng host, or vice versa, through a
+   mixture of IPv4 and IPng routers, with no (zero, null) modifications
+   to the IPv4 hosts. IPv4 routers must need no modifications to
+   interwork with IPng routers.  Additionally, an application package
+   which is "aware" of IPv4 but still "unaware" of IPng must be able to
+   run on a computer system which is running IPv4, but communicating
+   with an IPng host.  For example an old PC in Europe should be able to
+   access a NIC server in the USA, even if the NIC server is running
+   IPng and the transatlantic routing mechanisms are only partly
+   converted.  Or a Class C network in one department of a company
+   should retain full access to corporate servers which are running
+   IPng, even though nothing whatever has been changed inside the Class
+   C network.
+
+   (This does NOT require an IPv4-only application to run on an IPng
+   host; thus we accept that some hosts cannot be upgraded until all
+   their applications are IPng-compatible. In other words we accept that
+   the API may change to some extent. However, even this relaxation is
+   debatable and some vendors may want to strictly preserve the IPv4 API
+   on an IPng host.)
+
+
+
+Carpenter                                                       [Page 2]
+
+RFC 1671          IPng White Paper on Transition, etc.       August 1994
+
+
+   B) Header translation considered harmful.
+
+   This author believes that any transition scenario which REQUIRES
+   dynamic header translation between IPv4 and IPng packets will create
+   almost insurmountable practical difficulties:
+
+
+     B1) It is taken for granted for the purposes of this paper that
+         IPng functionality will be a superset of IPv4 functionality.
+         However, successful translation between protocols requires
+         that the functionalities of the two protocols which are to be
+         translated are effectively identical. To achieve this,
+         applications will need to know when they are interworking,
+         via the IPng API and a translator somewhere in the network,
+         with an IPv4 host, so as to use only IPv4 functionality. This
+         is an unrealistic constraint.
+
+     B2) Administration of translators will be quite impracticable for
+         large sites, unless the translation mechanism is completely
+         blind and automatic. Specifically, any translation mechanism
+         that requires special tags to be maintained manually for each
+         host in tables (such as DNS tables or router tables) to
+         indicate the need for translation will be impossible to
+         administer. On a site with thousands of hosts running many
+         versions and releases of several operating systems, hosts
+         move forwards and even backwards between software releases in
+         such a way that continuously tracking the required state of
+         such tags will be impossible. Multiplied across the whole
+         Internet, this will lead to chaos, complex failure modes, and
+         difficult diagnosis. In particular, it will make the
+         constraint of paragraph B1) impossible to respect.
+
+         In practice, the knowledge that translation is needed should
+         never leak out of the site concerned if chaos is to be
+         avoided, and yet without such knowledge applications cannot
+         limit themselves to IPv4 functionality when necessary.
+
+   To avoid confusion, note that header translation, as discussed here,
+   is not the same thing as address translation (NAT). This paper does
+   not discuss NAT.
+
+   This paper does not tackle performance issues in detail, but clearly
+   another disadvantage of translation is the consequent overhead.
+
+   C) Coexistence.
+
+   The Internet infrastructure (whether global or private) must allow
+   coexistence of IPv4 and IPng in the same routers and on the same
+
+
+
+Carpenter                                                       [Page 3]
+
+RFC 1671          IPng White Paper on Transition, etc.       August 1994
+
+
+   physical paths.
+
+   This is a necessity, in order that the network infrastructure can be
+   updated to IPng without requiring hosts to be updated in lock step
+   and without requiring translators.
+
+   Note that this requirement does NOT impose a decision about a common
+   or separate (ships-in-the-night) approach to routing.  Nor does it
+   exclude encapsulation as a coexistence mechanism.
+
+   D) IPv4 to IPng address mapping.
+
+   Human beings will have to understand what is happening during
+   transition. Although auto-configuration of IPng addresses may be a
+   desirable end point, management of the transition will be greatly
+   simplified if there is an optional simple mapping, on a given site,
+   between IPv4 and IPng addresses.
+
+   Therefore, the IPng address space should include a mapping for IPv4
+   addresses, such that (if a site or service provider wants to do this)
+   the IPv4 address of a system can be transformed mechanically into its
+   IPng address, most likely by adding a prefix.  The prefix does not
+   have to be the same for every site; it is likely to be at least
+   service-provider specific.
+
+   This does not imply that such address mapping will be used for
+   dynamic translation (although it could be) or to embed IPv4 routing
+   within IPng routing (although it could be). Its main purpose is to
+   simplify transition planning for network operators.
+
+   By the way, this requirement does not actually assume that IPv4
+   addresses are globally unique.
+
+   Neither does it help much in setting up the relationship, if any,
+   between IPv4 and IPng routing domains and hierarchies. There is no
+   reason to suppose these will be in 1:1 correspondence.
+
+   E) Dual stack hosts.
+
+   Stepwise transition without translation is hard to imagine unless a
+   large proportion of hosts are simultaneously capable of running IPng
+   and IPv4.  If A needs to talk to B (an IPng host) and to C (an IPv4
+   host) then either A or B must be able to run both IPv4 and IPng. In
+   other words, all hosts running IPng must still be able to run IPv4.
+   IPng-only hosts are not allowed during transition.
+
+   This requirement does not imply that IPng hosts really have two
+   completely separate IP implementations (dual stacks and dual APIs),
+
+
+
+Carpenter                                                       [Page 4]
+
+RFC 1671          IPng White Paper on Transition, etc.       August 1994
+
+
+   but just that they behave as if they did.  It is compatible with
+   encapsulation (i.e., one of the two stacks encapsulates packets for
+   the other).
+
+   Obviously, management of dual stack hosts will be simplified by the
+   address mapping just mentioned. Only the site prefix has to be
+   configured (manually or dynamically) in addition to the IPv4 address.
+
+   In a dual stack host the IPng API and the IPv4 API will be logically
+   distinguishable even if they are implemented as a single entity.
+   Applications will know from the API whether they are using IPng or
+   IPv4.
+
+   F) DNS.
+
+   The dual stack requirement implies that DNS has to reply with both an
+   IPv4 and IPng address for IPng hosts, or with a single reply that
+   encodes both.
+
+   If a host is attributed an IPng address in DNS, but is not actually
+   running IPng yet, it will appear as a black hole in IPng space - see
+   the next point.
+
+   G) Smart dual-stack code.
+
+   The dual-stack code may get two addresses back from DNS; which does
+   it use?  During the many years of transition the Internet will
+   contain black holes. For example, somewhere on the way from IPng host
+   A to IPng host B there will sometimes (unpredictably) be IPv4-only
+   routers which discard IPng packets.  Also, the state of the DNS does
+   not necessarily correspond to reality. A host for which DNS claims to
+   know an IPng address may in fact not be running IPng at a particular
+   moment; thus an IPng packet to that host will be discarded on
+   delivery.  Knowing that a host has both IPv4 and IPng addresses gives
+   no information about black holes. A solution to this must be proposed
+   and it must not depend on manually maintained information.  (If this
+   is not solved, the dual stack approach is no better than the packet
+   translation approach.)
+
+   H) Smart management tools.
+
+   A whole set of management tools is going to be needed during the
+   transition. Why is my IPng route different from my IPv4 route?  If
+   there is translation, where does it happen?  Where are the black
+   holes? (Cosmologists would like the same tool :-) Is that host REALLY
+   IPng-capable today?...
+
+
+
+
+
+Carpenter                                                       [Page 5]
+
+RFC 1671          IPng White Paper on Transition, etc.       August 1994
+
+
+Multicasts high and low
+
+   It is taken for granted that multicast applications must be supported
+   by IPng. One obvious architectural rule is that no multicast packet
+   should ever travel twice over the same wire, whether it is a LAN or
+   WAN wire. Failure to observe this would mean that the maximum number
+   of simultaneous multicast transactions would be halved.
+
+   A negative feature of IPv4 on LANs is the cavalier use of physical
+   broadcast packets by protcols such as ARP (and various non-IETF
+   copycats).  On large LANs this leads to a number of undesirable
+   consequences (often caused by poor products or poor users, not by the
+   protcol design itself).  The obvious architectural rule is that
+   physical broadcast should be replaced by unicast (or at worst,
+   multicast) whenever possible.
+
+ATM
+
+   The networking industry is investing heavily in ATM. No IPng proposal
+   will be plausible (in the sense of gaining management approval)
+   unless it is "ATM compatible", i.e., there is a clear model of how it
+   will run over an ATM network. Although a fully detailed document such
+   as RFC 1577 is not needed immediately, it must be shown that the
+   basic model works.
+
+   Similar remarks could be made about X.25, Frame Relay, SMDS etc. but
+   ATM is the case with the highest management hype ratio today.
+
+Policy routing and accounting
+
+   Unfortunately, this cannot be ignored, however much one would like
+   to.  Funding agencies want traffic to flow over the lines funded to
+   carry it, and they want to know afterwards how much traffic there
+   was.  Accounting information can also be used for network planning
+   and for back-charging.
+
+   It is therefore necessary that IPng and its routing procedures allow
+   traffic to be routed in a way that depends on its source and
+   destination in detail. (As an example, traffic from the Physics
+   department of MIT might be required to travel a different route to
+   CERN than traffic from any other department.)
+
+   A simple approach to this requirement is to insist that IPng must
+   support provider-based addressing and routing.
+
+   Accounting of traffic is required at the same level of detail (or
+   more, for example how much of the traffic is ftp and how much is
+   www?).
+
+
+
+Carpenter                                                       [Page 6]
+
+RFC 1671          IPng White Paper on Transition, etc.       August 1994
+
+
+   Both of these requirements will cost time or money and may impact
+   more than just the IP layer, but IPng should not duck them.
+
+Security Considerations
+
+   Corporate network operators, and campus network operators who have
+   been hacked a few times, take this more seriously than many protocol
+   experts.  Indeed many corporate network operators would see improved
+   security as a more compelling argument for transition to IPng than
+   anything else.
+
+   Since IPng will presumably be a datagram protocol, limiting what can
+   be done in terms of end-to-end security, IPng must allow more
+   effective firewalls in routers than IPv4.  In particular efficient
+   traffic barring based on source and destination addresses and types
+   of transaction is needed.
+
+   It seems likely that the same features needed to allow policy routing
+   and detailed accounting would be needed for improved firewall
+   security.  It is outside the scope of this document to discuss these
+   features in detail, but it seems unlikely that they are limited to
+   implementation details in the border routers.  Packets will have to
+   carry some authenticated trace of the (source, destination,
+   transaction) triplet in order to check for unwanted traffic, to allow
+   policy-based source routing, and/or to allow detailed accounting.
+   Presumably any IPng will carry source and destination identifiers in
+   some format in every packet, but identifying the type of transaction,
+   or even the individual transaction, is an extra requirement.
+
+Disclaimer and Acknowledgements
+
+   This is a personal view and does not necessarily represent that of my
+   employer.
+
+   CERN has been through three network transitions in recent years (IPv4
+   renumbering managed by John Gamble, AppleTalk Phase I to Phase II
+   transition managed by Mike Gerard, and DECnet Phase IV to DECnet/OSI
+   routing transition managed by Denise Heagerty).  I could not have
+   written this document without having learnt from them. I have also
+   benefitted greatly from discussions with or the writings of many
+   people, especially various members of the IPng Directorate. Several
+   Directorate members gave comments that helped clarify this paper, as
+   did Bruce L Hutfless of Boeing.  However the opinions are mine and
+   are not shared by all Directorate members.
+
+
+
+
+
+
+
+Carpenter                                                       [Page 7]
+
+RFC 1671          IPng White Paper on Transition, etc.       August 1994
+
+
+Author's Address
+
+   Brian E. Carpenter
+   Group Leader, Communications Systems
+   Computing and Networks Division
+   CERN
+   European Laboratory for Particle Physics
+   1211 Geneva 23, Switzerland
+
+   Phone:  +41 22 767-4967
+   Fax:    +41 22 767-7155
+   Telex:  419000 cer ch
+   EMail: brian@dxcoms.cern.ch
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Carpenter                                                       [Page 8]
+