As per Relevance of the word transport, we have this rfc below:
Network Working Group J.
Request for Comments: 1682 Digital Equipment
Category: Informational August 1994
IPng BSD Host Implementation
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document was submitted to the IETF IPng area in response to
1550. Publication of this document does not imply acceptance by
IPng area of any ideas expressed within. Comments should
submitted to the big-internet@munnari.oz.au mailing list
This IPng white paper, IPng BSD Host Implementation Analysis
was submitted to the IPng Directorate to provide a BSD host point
reference to assist with the engineering considerations during
IETF process to select an IPng proposal. The University
California Berkeley Software Distribution (BSD) TCP/IP (4.3 + 4.4)
system implementation on a host is used as a point of reference
the paper
This document only reflects the author's personal analysis based
research and implementation experience for IPng, and does
represent any product or future product from any host vendor.
should it be construed that it is promoting any specific IPng at
time
The author would like to acknowledge the many host
discussions and inherent knowledge gained from discussions with
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
would also like to acknowledge like discussions from outside
company with Bob Hinden (SUN), Bob Gilligan (SUN), Dave
(SGI), Dave Piscitello (Core Competence), Tracy Mallory (3Comm),
Ullmann (Lotus), Greg Minshall (Novell), J Allard (Microsoft),
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
would also like to thank Digital Equipment Corporation for
opportunity to work on IPng within the IETF as part of his job
1.
A host in the context of this white paper is a system that
an operating system supporting a network subsystem as one of
parts, and an interprocess communications facility to access
network subsystem. These hosts are often referenced as
Workstation, Server, PC, Super Computer, Mainframe, or an
System (Realtime Devices).
IPng will require changes to a hosts network software architecture
Those changes should be as transparent as possible to the
IPv4 applications executing on hosts
After discussing the network software architecture for a BSD host
paper will discuss the perceived network software alterations
extended capabilities, transition software, and a
consideration for IPng hosts
The inclusive OR of all IPng proposals was used to develop
engineering considerations discussed in this paper
2. Network Software
The BSD host network software architecture consists essentially
three components: the interprocess communications facility,
network communications subsystem, and the network
supported. These three components are tightly coupled and must
integrated in a way that affords high performance for
applications that are dependent on these components to
efficiently. A BSD host implementation view of the TCP/IP
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
The interprocess communications (IPC) facilities includes
critical parts
1. The IPC mechanism to the network communications subsystem
2. The ability to access a network protocol set within
subsystem
3. The structures supporting the network
subsystem
Bound [Page 3]
RFC 1682 IPng BSD Host Implementation Analysis August 1994
The IPC facility has two implementation parts. The part in
space and the part in kernel space within the operating system.
is often not differentiated and why in the previous
architecture diagram you will see sockets in both user and
space. An IPC supports in user space an application
interface (API) which application developers use to access
network communications features of the host. These APIs
corresponding functions in the kernel space which execute
functions requested by the user space requests through the APIs
The sockets paradigm on a BSD host defines the data structure of
network address within a selected protocol family (
domain) in the network subsystem. This data structure consists of
address family, a port for the protocol selected, and a
address
The IPC facility on a host is dependent upon its interface to
BIND DNS application which is the defacto method when using TCP/IP
retrieve network addresses
Other interfaces that may be required by applications to properly
up the network connection within the IPC facility include
setting/getting options for the protocols used, obtaining/
information about networks, protocols, and network services,
sending/transmitting datagrams
2.2 Network Communications
The network communications subsystem consists of the
generic parts as depicted in the previous network
diagram: transport layer, network layer, link dependent layer,
data link layer. These may not be implemented as true
layers on a BSD host, but they are referenced in this white paper
that manner for purposes of discussion
The transport layer supports the application interface into
network communications subsystem and sets up the parametric pieces
initiate and accept connections. The transport layer performs
functions through requests to the lower layers of the
communications subsystem. The transport layer also supports
queues and protocol control blocks for specific network connections
The network layer supports the modules to build and extend
network layer datagram, the control protocol datagrams, and
routing abstraction on the host. This layer of the
communications subsystem on a BSD host is often extended to
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
interface for the network communications subsystem to map
addresses to physical addresses, and build the necessary cache
this information is available to the host network software
On a BSD host the network layer and link dependent layer
provide system discovery for hosts and routers
The data link layer supports the modules that define the
for communicating with the hardware media used by the host on
local network
2.3 Network
The TCP/IP protocol suite as defined by the IETF RFC
are the set of network protocols used by this white paper
reference
3. Network Software
The IPng network software alterations to a BSD host perceived at
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
Internet style applications in this white paper are the set
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
of the network addresses used to support connections across
network. Opaque in this context means that the application
the network address for the connection and then binds that address
a socket. The application then uses the reference defined for
socket to receive and transmit data across a network
An application that embeds an IPv4 network address within
datagram has made an underlying assumption that the format of
address is permanent. This will cause a great problem when
causes addresses to change. Thus far only one Internet
application has been determined to cause this problem and that is
Bound [Page 5]
RFC 1682 IPng BSD Host Implementation Analysis August 1994
[1,2].
3.2 Transport Interfaces and Network
The transport interface and network API enhancements that must
place on a BSD host because of IPng are alterations that affect
size of the network address used by the socket data structure
Depending on how this is implemented on the host, supporting
IPv4 and IPng could require existing IPv4 applications to
recompiled. In the worst case it could require modifications to
existing IPv4 applications software that accesses the
communications subsystem
There will have to be enhancements to the network APIs that
application uses to retrieve BIND DNS records to
between IPv4 and IPng address requests
The network API enhancements and how they are implemented will
the capability of any IPng proposal on a BSD host to be able
interoperate between an IPv4 only, an IPng only, and an IPng-IPv
host system
Depending on the IPng proposal selected the network options
services, and management objects will have to be extended at
transport interface so those features can be accessed by
software
3.3 Socket Layer and
The socket layer and structures will require changes to support
IPng proposals network address. In addition new or removed
and services will need to be incorporated into the socket
within the network communications subsystem
3.4 Transport
The transport layer will need to be modified to support any new
removed services proposed by an IPng solution set. The
layer will become more overloaded to support the binding of
the IPv4 or IPng network layer components to differentiate
services and structures available to a host application.
overload will also take place to support functionality removed in
network layer and moved to the transport layer if proposed by an
solution
It will also take some design thought to implement IPng so
hundreds of man years invested in performance improvements in
host transport layer are maintained. This must be analyzed in
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
The network layer components for IPng will require the
alterations on a host. In addition a host will be required
maintain an integrated network layer below the transport
software to support either the IPng or IPv4 network layer
associated components
Depending on the IPng selected the host alterations to the
layer components will range from complete replacement with
protocols to extensions to existing IPv4 network layer protocols
support IPng
All IPng proposals will affect the BSD host routing abstraction
maintain host software that supports interior and exterior routing
Depending on the proposal selected those changes can cause either
complete new paradigm or an update to the existing IPv4 paradigm
System discovery of nodes on the local subnetwork or across
internetwork path in all IPng proposals will require changes to
BSD host software network layer component
3.6 Link dependent
The link dependent layer on a host will need to accommodate new
addresses and the system discovery models of any IPng proposal
4. Extended Capabilities with
Extended capabilities that could be implemented by BSD hosts
listed below. Many of these capabilities exist today with IPv4,
may require changes with the implementation of IPng. Some of
will be new capabilities
4.1 Autoconfiguration and
Today hosts can provide autoconfiguration with DHCP using IPv
addresses. IPng hosts will be faced with having to provide
for existing IPv4 addresses and the new IPng addresses. In
the boot-strap protocol BOOTP used to boot minimal BSD
configurations (e.g., diskless nodes) will need to be supported
IPng hosts
Bound [Page 7]
RFC 1682 IPng BSD Host Implementation Analysis August 1994
4.2 PATH MTU
PATH MTU discovery appears to be something each proposal
considering. Alterations to the existing implementation of PATH
are perceived because changes are expected in system discovery
4.3
Each proposal has depicted alterations to Multicast that will
present BSD host implementations of IPv4 Multicast. In addition
appears that the IPv4 unicast broadcast will be replaced by
multicast broadcast
4.4 Flow Specification and
This will be an extended capability proposed by all IPngs'.
4.5 System
Each proposal has depicted a new model for IPng system discovery of
host
4.6 Translation and
The routing abstraction in a BSD host will have to deal with
affect of any translation or encapsulation of network
datagrams, if they are required by an IPng
4.7 Network Layer
It is perceived that network layer security will be required at
network layer component of IPng and this will have to be
by a BSD host
4.8 Socket Address
The network kernel socket address structure will change because
IPng
4.9 Network
The network APIs for a BSD host will have to be enhanced to
IPng. In addition any new options available to the
because of the IPng network service will have to be added as
option to the APIs
Bound [Page 8]
RFC 1682 IPng BSD Host Implementation Analysis August 1994
4.10 Network
Network management for IPng will have to support new network
as defined by the IPng proposal. In addition the data structures
the BSD host network kernel used as information to display
topology will be altered by a new network layer datagram
associated components
5. Transition
Transition software in this white paper references the
software alterations on a host to support both IPv4 and IPng
applications and the hosts operating system network kernel. It
the subject of another set of papers to identify the
software required by network managers to transition their users
IPv4 to IPng
Transition software on a host will be required to
compatibility between IPv4 and IPng, and to manage both the
IPv4 and IPng environments as follows
1. BIND DNS record updates and handling by the application
2. SNMP management interface and monitoring of host
structures
3. APIs supporting IPv4 and IPng differentiation for
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
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
will have to deal with in its implementation of IPng. The
network architecture diagram depicted previously will
software enhancements to each label in the diagram
It is very important that each IPng proposal provide a
for a transition plan from IPv4 to IPng and their technical
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
have to be recompiled when a host has implemented both an IPv4 and
IPng network layer and associated components
It is very desirable that when a host implements both an IPv4 and
IPng network layer and associated components that there is
performance degradation on the host compared to the performance of
existing IPv4 only host
It should not be a requirement by IPng that a host must support
an IPv4 and an IPng network layer
6. A Deployment
Complete and extensive technical specifications must be available
any IPng proposal, and a selection of any proposal must
multiple implementations. The IPng Directorate should review
specifications for completeness
It is important that the IPng Directorate determine how long the
IPv4 address plan can extend the life of IPv4 addresses on
Internet. This variable can affect the time we have to deploy
and the proposed transition plans
[1] Gilligan, B., et. al., "IPAE: The SIPP Interoperability
Transition Mechanism", Work in Progress
[2] Piscitello, D., "FTP Operation Over Big Address
(FOOBAR)", RFC 1639, Core Competence, Inc., June 1994.
Security
Security issues are discussed in Section 4.7.
Author's
Jim
Digital Equipment
110 Spitbrook Road ZK3-3/U14
Nashua, NH 03062-2698
Phone: +1 603 881 0400
EMail: bound@zk3.dec.
Bound [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
