doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc1682.txt b/doc/rfc/rfc1682.txt
new file mode 100644
index 0000000..56777dc
--- /dev/null
+++ b/doc/rfc/rfc1682.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                           J. Bound
+Request for Comments: 1682                 Digital Equipment Corporation
+Category: Informational                                      August 1994
+
+
+                 IPng BSD Host Implementation Analysis
+
+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.
+
+Overview
+
+   This IPng white paper, IPng BSD Host Implementation Analysis,
+   was submitted to the IPng Directorate to provide a BSD host point of
+   reference to assist with the engineering considerations during the
+   IETF process to select an IPng proposal.  The University of
+   California Berkeley Software Distribution (BSD) TCP/IP (4.3 + 4.4)
+   system implementation on a host is used as a point of reference for
+   the paper.
+
+   This document only reflects the author's personal analysis based on
+   research and implementation experience for IPng, and does not
+   represent any product or future product from any host vendor.  Nor
+   should it be construed that it is promoting any specific IPng at this
+   time.
+
+Acknowledgments
+
+   The author would like to acknowledge the many host implementation
+   discussions and inherent knowledge gained from discussions with the
+   following persons within Digital over the past year: Peter Grehan,
+   Eric Rosen, Dave Oran, Jeff Mogul, Bill Duane, Tony Lauck, Bill Hawe,
+   Jesse Walker, John Dustin, Alex Conta, and Fred Glover.  The author
+   would also like to acknowledge like discussions from outside his
+   company with Bob Hinden (SUN), Bob Gilligan (SUN), Dave Crocker
+   (SGI), Dave Piscitello (Core Competence), Tracy Mallory (3Comm), Rob
+   Ullmann (Lotus), Greg Minshall (Novell), J Allard (Microsoft), Ramesh
+   Govinden (Bellcore), Sue Thompson (Bellcore), John Curran (NEARnet),
+
+
+
+Bound                                                           [Page 1]
+
+RFC 1682         IPng BSD Host Implementation Analysis       August 1994
+
+
+   Christian Huitema (INRIA), and Werner Volgels (INESC).  The author
+   would also like to thank Digital Equipment Corporation for the
+   opportunity to work on IPng within the IETF as part of his job.
+
+1. Introduction
+
+   A host in the context of this white paper is a system that contains
+   an operating system supporting a network subsystem as one of its
+   parts, and an interprocess communications facility to access that
+   network subsystem.  These hosts are often referenced as a
+   Workstation, Server, PC, Super Computer, Mainframe, or an Embedded
+   System (Realtime Devices).
+
+   IPng will require changes to a hosts network software architecture.
+   Those changes should be as transparent as possible to the existing
+   IPv4 applications executing on hosts.
+
+   After discussing the network software architecture for a BSD host the
+   paper will discuss the perceived network software alterations,
+   extended capabilities, transition software, and a deployment
+   consideration for IPng hosts.
+
+   The inclusive OR of all IPng proposals was used to develop the
+   engineering considerations discussed in this paper.
+
+2. Network Software Architecture
+
+   The BSD host network software architecture consists essentially of
+   three components: the interprocess communications facility, the
+   network communications subsystem, and the network protocols
+   supported. These three components are tightly coupled and must be
+   integrated in a way that affords high performance for the
+   applications that are dependent on these components to interoperate
+   efficiently.  A BSD host implementation view of the TCP/IP protocol
+   suite is depicted in the following network architecture diagram.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bound                                                           [Page 2]
+
+RFC 1682         IPng BSD Host Implementation Analysis       August 1994
+
+
+   +-----------------------------------------------------------------+
+   |                        Application Layer                        |
+   |                                                                 |
+   |                Socket and Network Library APIs                  |
+   |                                                                 |
+   |  BIND DNS                                                       |
+   |  SNMP Management                                                |
+   |                          User Space                             |
+   +-----------------------------------------------------------------+
+   |                         Kernel Space          AF_INET           |
+   |                                        Communications Domain    |
+   |  Socket Layer                                                   |
+   |                                                                 |
+   |                     Transport Layer TCP & UDP                   |
+   |                                               Queues/Control    |
+   |                                                 Blocks          |
+   |                        Network Layer                            |
+   |              +-----------------------------------+              |
+   |              | IPv4 Modules  Discovery Multicast |              |
+   |              |                ICMP       IGMP    |              |
+   |              |                   Routing         |   Routing    |
+   |              |                RIP        EGP     |   Tables     |
+   |              |                OSPF       BGP     |              |
+   |              |                I-IS-IS    IDRP    |              |
+   |              +-----------------------------------+              |
+   |                     Link Dependent Layer                        |
+   |              +-----------------------------------+              |
+   |              | ARP, RARP, InARP, NCPs, Addr Tbls |              |
+   |              +-----------------------------------+              |
+   |  Discovery & Interface                                          |
+   |      Cache                                                      |
+   |                     Data Link Layer                             |
+   |              +-----------------------------------+              |
+   |              | Ethernet, FDDI, ATM, HIPPI, PPP   |              |
+   |              +-----------------------------------+              |
+   +-----------------------------------------------------------------+
+
+2.1 Interprocess Communications Facility
+
+   The interprocess communications (IPC) facilities includes three
+   critical parts:
+
+      1.  The IPC mechanism to the network communications subsystem.
+      2.  The ability to access a network protocol set within that
+          subsystem.
+      3.  The structures supporting the network communications
+          subsystem.
+
+
+
+
+Bound                                                           [Page 3]
+
+RFC 1682         IPng BSD Host Implementation Analysis       August 1994
+
+
+   The IPC facility has two implementation parts.  The part in user
+   space and the part in kernel space within the operating system. This
+   is often not differentiated and why in the previous network
+   architecture diagram you will see sockets in both user and kernel
+   space.  An IPC supports in user space an application program
+   interface (API) which application developers use to access the
+   network communications features of the host. These APIs have
+   corresponding functions in the kernel space which execute the
+   functions requested by the user space requests through the APIs.
+
+   The sockets paradigm on a BSD host defines the data structure of the
+   network address within a selected protocol family (communications
+   domain) in the network subsystem.  This data structure consists of an
+   address family, a port for the protocol selected, and a network
+   address.
+
+   The IPC facility on a host is dependent upon its interface to the
+   BIND DNS application which is the defacto method when using TCP/IP to
+   retrieve network addresses.
+
+   Other interfaces that may be required by applications to properly set
+   up the network connection within the IPC facility include:
+   setting/getting options for the protocols used, obtaining/accessing
+   information about networks, protocols, and network services, and
+   sending/transmitting datagrams.
+
+2.2 Network Communications Subsystem
+
+   The network communications subsystem consists of the following
+   generic parts as depicted in the previous network architecture
+   diagram: transport layer, network layer, link dependent layer, and
+   data link layer.  These may not be implemented as true distinct
+   layers on a BSD host, but they are referenced in this white paper in
+   that manner for purposes of discussion.
+
+   The transport layer supports the application interface into the
+   network communications subsystem and sets up the parametric pieces to
+   initiate and accept connections.  The transport layer performs these
+   functions through requests to the lower layers of the network
+   communications subsystem.  The transport layer also supports the
+   queues and protocol control blocks for specific network connections.
+
+   The network layer supports the modules to build and extend the
+   network layer datagram, the control protocol datagrams, and the
+   routing abstraction on the host.  This layer of the network
+   communications subsystem on a BSD host is often extended to provide
+   both interior and exterior routing functionality.
+
+
+
+
+Bound                                                           [Page 4]
+
+RFC 1682         IPng BSD Host Implementation Analysis       August 1994
+
+
+   The link dependent layer supports the modules that provide an
+   interface for the network communications subsystem to map network
+   addresses to physical addresses, and build the necessary cache so
+   this information is available to the host network software.
+
+   On a BSD host the network layer and link dependent layer together
+   provide system discovery for hosts and routers.
+
+   The data link layer supports the modules that define the structures
+   for communicating with the hardware media used by the host on the
+   local network.
+
+2.3 Network Protocols
+
+   The TCP/IP protocol suite as defined by the IETF RFC specifications
+   are the set of network protocols used by this white paper for
+   reference.
+
+3. Network Software Alterations
+
+   The IPng network software alterations to a BSD host perceived at this
+   time are as follows:
+
+      1.  Applications Embedding IPv4 Addresses.
+      2.  Transport Interfaces and Network APIs.
+      3.  Socket Layer and Structures.
+      4.  Transport Layer.
+      5.  Network Layer Components.
+      6.  Link dependent Layer.
+
+3.1 Applications Embedding IPv4 Addresses
+
+   Internet style applications in this white paper are the set of
+   protocols defined for an end user using TCP/IP to exchange messages,
+   transfer files, and establish remote login sessions.
+
+   Applications use the sockets network APIs to maintain an opaque view
+   of the network addresses used to support connections across a
+   network. Opaque in this context means that the application determines
+   the network address for the connection and then binds that address to
+   a socket.  The application then uses the reference defined for that
+   socket to receive and transmit data across a network.
+
+   An application that embeds an IPv4 network address within its
+   datagram has made an underlying assumption that the format of that
+   address is permanent.  This will cause a great problem when IPng
+   causes addresses to change.  Thus far only one Internet style
+   application has been determined to cause this problem and that is FTP
+
+
+
+Bound                                                           [Page 5]
+
+RFC 1682         IPng BSD Host Implementation Analysis       August 1994
+
+
+   [1,2].
+
+3.2 Transport Interfaces and Network APIs
+
+   The transport interface and network API enhancements that must take
+   place on a BSD host because of IPng are alterations that affect the
+   size of the network address used by the socket data structure.
+   Depending on how this is implemented on the host, supporting both
+   IPv4 and IPng could require existing IPv4 applications to be
+   recompiled.  In the worst case it could require modifications to the
+   existing IPv4 applications software that accesses the network
+   communications subsystem.
+
+   There will have to be enhancements to the network APIs that an
+   application uses to retrieve BIND DNS records to differentiate
+   between IPv4 and IPng address requests.
+
+   The network API enhancements and how they are implemented will affect
+   the capability of any IPng proposal on a BSD host to be able to
+   interoperate between an IPv4 only, an IPng only, and an IPng-IPv4
+   host system.
+
+   Depending on the IPng proposal selected the network options,
+   services, and management objects will have to be extended at the
+   transport interface so those features can be accessed by applications
+   software.
+
+3.3 Socket Layer and Structures
+
+   The socket layer and structures will require changes to support any
+   IPng proposals network address.  In addition new or removed options
+   and services will need to be incorporated into the socket abstraction
+   within the network communications subsystem.
+
+3.4 Transport Layer
+
+   The transport layer will need to be modified to support any new or
+   removed services proposed by an IPng solution set.  The transport
+   layer will become more overloaded to support the binding of either
+   the IPv4 or IPng network layer components to differentiate the
+   services and structures available to a host application.  The
+   overload will also take place to support functionality removed in the
+   network layer and moved to the transport layer if proposed by an IPng
+   solution.
+
+   It will also take some design thought to implement IPng so the
+   hundreds of man years invested in performance improvements in the
+   host transport layer are maintained.   This must be analyzed in depth
+
+
+
+Bound                                                           [Page 6]
+
+RFC 1682         IPng BSD Host Implementation Analysis       August 1994
+
+
+   and should be part of the operational testing of any IPng proposal.
+
+3.5 Network Layer Components
+
+   The network layer components for IPng will require the greatest
+   alterations on a host.  In addition a host will be required to
+   maintain an integrated network layer below the transport layer
+   software to support either the IPng or IPv4 network layer and
+   associated components.
+
+   Depending on the IPng selected the host alterations to the network
+   layer components will range from complete replacement with new
+   protocols to extensions to existing IPv4 network layer protocols to
+   support IPng.
+
+   All IPng proposals will affect the BSD host routing abstraction to
+   maintain host software that supports interior and exterior routing.
+   Depending on the proposal selected those changes can cause either a
+   complete new paradigm or an update to the existing IPv4 paradigm.
+
+   System discovery of nodes on the local subnetwork or across an
+   internetwork path in all IPng proposals will require changes to the
+   BSD host software network layer component.
+
+3.6 Link dependent Layer
+
+   The link dependent layer on a host will need to accommodate new IPng
+   addresses and the system discovery models of any IPng proposal.
+
+4. Extended Capabilities with IPng
+
+   Extended capabilities that could be implemented by BSD hosts are
+   listed below.  Many of these capabilities exist today with IPv4, but
+   may require changes with the implementation of IPng.  Some of them
+   will be new capabilities.
+
+4.1 Autoconfiguration and Autoregistration
+
+   Today hosts can provide autoconfiguration with DHCP using IPv4
+   addresses. IPng hosts will be faced with having to provide support
+   for existing IPv4 addresses and the new IPng addresses.  In addition
+   the boot-strap protocol BOOTP used to boot minimal BSD host
+   configurations (e.g., diskless nodes) will need to be supported by
+   IPng hosts.
+
+
+
+
+
+
+
+Bound                                                           [Page 7]
+
+RFC 1682         IPng BSD Host Implementation Analysis       August 1994
+
+
+4.2 PATH MTU Discovery
+
+   PATH MTU discovery appears to be something each proposal is
+   considering.  Alterations to the existing implementation of PATH MTU
+   are perceived because changes are expected in system discovery.
+
+4.3 Multicast
+
+   Each proposal has depicted alterations to Multicast that will affect
+   present BSD host implementations of IPv4 Multicast.  In addition it
+   appears that the IPv4 unicast broadcast will be replaced by a
+   multicast broadcast.
+
+4.4 Flow Specification and Handling
+
+   This will be an extended capability proposed by all IPngs'.
+
+4.5 System Discovery
+
+   Each proposal has depicted a new model for IPng system discovery of a
+   host.
+
+4.6 Translation and Encapsulation
+
+   The routing abstraction in a BSD host will have to deal with the
+   affect of any translation or encapsulation of network layer
+   datagrams, if they are required by an IPng.
+
+4.7 Network Layer Security
+
+   It is perceived that network layer security will be required at the
+   network layer component of IPng and this will have to be implemented
+   by a BSD host.
+
+4.8 Socket Address Structure
+
+   The network kernel socket address structure will change because of
+   IPng.
+
+4.9 Network APIs
+
+   The network APIs for a BSD host will have to be enhanced to support
+   IPng.  In addition any new options available to the applications
+   because of the IPng network service will have to be added as an
+   option to the APIs.
+
+
+
+
+
+
+Bound                                                           [Page 8]
+
+RFC 1682         IPng BSD Host Implementation Analysis       August 1994
+
+
+4.10 Network Management
+
+   Network management for IPng will have to support new network objects
+   as defined by the IPng proposal.  In addition the data structures in
+   the BSD host network kernel used as information to display network
+   topology will be altered by a new network layer datagram and
+   associated components.
+
+5. Transition Software
+
+   Transition software in this white paper references the network
+   software alterations on a host to support both IPv4 and IPng for
+   applications and the hosts operating system network kernel.  It is
+   the subject of another set of papers to identify the transition
+   software required by network managers to transition their users from
+   IPv4 to IPng.
+
+   Transition software on a host will be required to maintain
+   compatibility between IPv4 and IPng, and to manage both the existing
+   IPv4 and IPng environments as follows:
+
+      1.  BIND DNS record updates and handling by the application.
+      2.  SNMP management interface and monitoring of host network
+          structures.
+      3.  APIs supporting IPv4 and IPng differentiation for the
+          application.
+      4.  Defacto network tools altered (e.g., tcpdump, traceroute,
+          netstat).
+      5.  ARP to new system discovery.
+      6.  BOOTP diskless node support for IPng.
+      7.  DHCP integration with IPng Autoconfiguration.
+      8.  Routing table configuration on the BSD host (e.g., routed,
+          ifconfig).
+      9.  Selection of the network layer (IPv4 or IPng) at the
+          transport layer.
+      10.  New options and services provided by an IPng protocol.
+      11.  IPv4 and IPng routing protocols in the network layer.
+      12.  IPv4 and IPng system discovery in the network layer.
+
+   These are only the highlights of the transition software that a host
+   will have to deal with in its implementation of IPng.  The host
+   network architecture diagram depicted previously will require
+   software enhancements to each label in the diagram.
+
+   It is very important that each IPng proposal provide a specification
+   for a transition plan from IPv4 to IPng and their technical criteria
+   for the interoperation between IPv4 and IPng.
+
+
+
+
+Bound                                                           [Page 9]
+
+RFC 1682         IPng BSD Host Implementation Analysis       August 1994
+
+
+   It should also be a requirement that existing IPv4 applications not
+   have to be recompiled when a host has implemented both an IPv4 and an
+   IPng network layer and associated components.
+
+   It is very desirable that when a host implements both an IPv4 and an
+   IPng network layer and associated components that there is no
+   performance degradation on the host compared to the performance of an
+   existing IPv4 only host.
+
+   It should not be a requirement by IPng that a host must support both
+   an IPv4 and an IPng network layer.
+
+6. A Deployment Consideration
+
+   Complete and extensive technical specifications must be available for
+   any IPng proposal, and a selection of any proposal must accommodate
+   multiple implementations. The IPng Directorate should review proposed
+   specifications for completeness.
+
+   It is important that the IPng Directorate determine how long the CIDR
+   IPv4 address plan can extend the life of IPv4 addresses on the
+   Internet.  This variable can affect the time we have to deploy IPng
+   and the proposed transition plans.
+
+References
+
+   [1] Gilligan, B., et. al., "IPAE: The SIPP Interoperability and
+       Transition Mechanism", Work in Progress.
+
+   [2] Piscitello, D., "FTP Operation Over Big Address Records
+       (FOOBAR)", RFC 1639, Core Competence, Inc., June 1994.
+
+Security Considerations
+
+   Security issues are discussed in Section 4.7.
+
+Author's Address
+
+   Jim Bound
+   Digital Equipment Corporation
+   110 Spitbrook Road ZK3-3/U14
+   Nashua, NH 03062-2698
+
+   Phone: +1 603 881 0400
+   EMail: bound@zk3.dec.com
+
+
+
+
+
+
+Bound                                                          [Page 10]
+