As per Relevance of the word problems, we have this rfc below:
Network Working Group: R.
Request for Comments: 1705
Category: Informational D.
October 1994
Six Virtual Inches to the Left
The Problem with
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 RFC suggests that a new version of TCP (TCPng), and UDP,
developed and deployed. It proposes that a globally unique
(TA) be assigned to Transport layer protocol (TCP/UDP). The
of this TA is to uniquely identify an Internet node
specifying any routing information. A new version of TCP, and UDP
will need to be developed describing the new header fields
formats. This new version of TCP would contain support for
bandwidth-delay networks. Support for multiple network
(Internet Protocol) protocols is also possible with this new TCP
Assigning an address to TCP/UDP would allow for the support
multiple network layer protocols (IPng's). The TA would identify
location of an Internet node. The IPng layer would provide
information to the Internet. Separating the location and
functions will greatly increase the versatility of the Internet
Carlson & Ficarella [Page 1]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
Table of
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Historical perspective . . . . . . . . . . . . . . . . . . . . 3
2.1 OSI and the 7 layer model . . . . . . . . . . . . . . . 3
2.2 Internet Evolution . . . . . . . . . . . . . . . . . . . 4
2.3 The Reasons for Change . . . . . . . . . . . . . . . . . 4
2.3.1 Class-B Address Exhaustion . . . . . . . . . . . 4
2.3.2 Routing Table Growth . . . . . . . . . . . . . . 5
3. The Problems with Change . . . . . . . . . . . . . . . . . . . 5
3.1 TCP/UDP Implementations . . . . . . . . . . . . . . . . 6
3.2 User Applications . . . . . . . . . . . . . . . . . . . 6
3.3 The Entrenched Masses . . . . . . . . . . . . . . . . . 6
4. Making TCP & UDP Protocol Independent . . . . . . . . . . . . 7
4.1 Transport Addressing . . . . . . . . . . . . . . . . . . 7
4.2 TCPng . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3 Mandatory Options . . . . . . . . . . . . . . . . . . . 15
4.4 Optional Options . . . . . . . . . . . . . . . . . . . . 16
4.5 Compatibility Issues . . . . . . . . . . . . . . . . . . 16
4.5.1 Backward Compatibility . . . . . . . . . . . . . 17
4.6 Level 4 Gateways . . . . . . . . . . . . . . . . . . . . 17
4.7 Error Conditions . . . . . . . . . . . . . . . . . . . . 18
5. Advantages and Disadvantages of this approach . . . . . . . . 18
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix C . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix D . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Security Considerations . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1.
For more than a decade, network engineers have understood
benefits of a multi-layer protocol stack. However, during
development, the Transmission Control Protocol (TCP) was
linked to the Internet Protocol (IP) [Postel, 1981a]. When the TCP/
protocol suite was developed, two important ideas were implemented
The first was that each host would be uniquely identified by
network layer number (i.e., IP number = 192.0.2.1). The second was
identify an application with a transport layer port number (i.e.,
DNS number = 53). For host-to-host communications, the IP and
numbers would be concatenated to form a socket (i.e., 192.0.2.1.53).
While this has lead to a very efficient and streamlined TCP layer,
has tightly coupled the TCP and IP layers. So much so, in fact,
it is nearly impossible to run TCP over any network layer except
Carlson & Ficarella [Page 2]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
IP
The motivation for writing this paper resulted from research into
various Internet Protocol Next Generation (IPng) proposals put
by various IETF working groups. Each of the IPng proposals strives
solve the impending IP address exhaustion problem by increasing
size of the address field. They all allude to modifications to
and User Datagram Protocol (UDP) to make them capable of supporting
new network layer IPng protocol. The authors of this paper feel
this points to an inherent TCP/IP design flaw. The flaw is
that the transport (TCP) and network (IP) layers are not
independent. In this paper, we will propose a new TCP and
implementation that will make the transport and protocol
independent and thus allow for any of the IPng protocols to
on the same internet without any further modification to the
layer protocols. TCP, and UDP would become extremely
Application Programming Interfaces (APIs) that operate
over multiple network layer technologies
2. Historical
2.1 OSI and the 7 layer
Present day computer and communication systems have
increasingly heterogeneous in both their software and
complexity, as well as their intended functionality. Prior to
establishment of computer communications industry standards
proprietary standards followed by particular software and
manufacturers prevented communication and information
between different manufacturers products and therefore lead to
"closed systems" [Halsal, 1992] incapable of readily
information. With the proliferation of these types of systems in
mid 1970s, the potential advantages of "open systems"
recognized by the computer industry and a range of standards
to be introduced [Halsal, 1992].
The first and perhaps most important of these standards was
International Standards Organization (ISO) reference model for
Systems Interconnection standard (OSI), describing the
communication subsystem within each computer. The goal of
standard model was to "allow an application process in any
that supports a particular set of standards to communicate
with an application process in any other computer that supports
same standards, irrespective of its origin of manufacture" [Halsal
1992]. The last statement above describes the OSI 7-layer
which has now, in concept, become the fundamental building block
computer networks. Though there are arguably no present
computers and networks completely compliant to all 7 layers of
Carlson & Ficarella [Page 3]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
OSI protocol stack, most protocol stacks do embrace the
concept of independent layers, thus allowing the flexibility
computers operating with dissimilar protocol stacks to
with one another
Take for example, the datalink layers as supported by TCP/IP. TCP/
will run equally well in either the local area network (LAN) or
area network (WAN) environments. Even though the LAN may use
802.3 and the WAN may use T1 serial links. This function was
to present a "standardized set of network functions (i.e., a
network)", to the upper network layer, "regardless of the
details of the lower level implementations" [Meyer, Zobrist, 1990].
2.2 Internet
"The internet architecture, the grand plan behind the TCP/IP
suite" was developed and tested in the late 1970s, [Braden, et al
1991] and but for the addition of subnetting, autonomous systems,
the domain name system in the early 1980s and the more recent
multicasting implementation, stands today essentially unchanged.
with the understood benefits of a multi-layer protocol stack,
steps taken to enhance the internet and its services have been
incremental and narrowly focused
2.3 The Reasons for
The reasons for change from IP to IPng can be described in terms
problems for which the current IP will simply become inadequate
unusable in the near future (~2-4 years). These problems are
exhaustion of IP class B address space, the exhaustion of IP
space in general, and the non-hierarchical nature of
allocation leading to a flat routing space [Dixon, 1993].
2.3.1 Class-B Address
One of the fundamental causes of this problem is the lack of a
of network address appropriate for a mid-sized organization.
class-C address, with a maximum of 254 unique host addresses is
small, while class-B, with a maximum of in excess of 65
unique host addresses is to large [Fuller, et al, 1992]. As
result, class-B addresses get assigned even though nowhere near
number of available addresses will ever get used. This fact,
with a doubling of class-B address allocation on a yearly basis
the Internet Engineering Steering Group (IESG) to conclude
November, 1992 that the class-B address space would be
exhausted within 2 years time. At that point, class-C
would have to be assigned, sometimes in multiples, to
needing more than the 254 possible host addresses from a
Carlson & Ficarella [Page 4]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
class-C address [Almquist, Gross, 1992].
2.3.2 Routing Table
Based on research conducted by the IESG in November 1992,
routing table size explosion problems were identified. Namely, it
determined that current router technology at that point could
a maximum of 16,000 routes, which in turn could support the
for an additional 12 to 18 months (~May, 1994) at the then
annual network growth rate. However, vendor router
capabilities were in the process of being increased to 64,000 routes
which at the two-fold annual network growth rate, could bring us
additional 2 years of lead time, (at best bringing us to May, 1996,
and at worst to November, 1995) assuming the class-B
exhaustion problem mentioned above could be solved in the
[Almquist, Gross, 1992].
As a short term, incremental solution to this routing table
problem, and to aid in the class-B address exhaustion problem
IESG endorsed the CIDR supernetting strategy proposal (see RFC-1338
for full details of this proposal). However, this strategy
estimated to have a viability of approximately 3 years, at
point the internet would run out of all classes of IP addresses
general. Hence, it is clear that even CIDR only offers
relief. However, if implemented immediately, CIDR can afford
Internet community time to develop and deploy an approach
addressing and routing which allows scaling to orders of
larger than the current architecture (IPng).
3. The Problems with
There are many problems, both philosophical and technical,
greatly contribute to the difficulties associated with a large
change such as the one proposed in the conversion from IP to IPng
These problems range from having to rewrite highly utilized
entrenched user applications, such as NFS, RPC, etc, to
having to invest additional capital to purchase hardware
supports the new protocol(s). This proposal solves the
internet problems listed above, while simultaneously limiting
amounts of retraining and re- investing that the user community
have to undertake. The TCP layer will once and for all be changed
support a multiprotocol internet. The net affect is that
administrators will necessarily be trained in the operations
details of this new TCP, the much larger operator and end
community will experience no perceptible change in service
network usage
Carlson & Ficarella [Page 5]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
3.1 TCP/UDP
Both TCP and UDP are highly dependent on the IPv4 network layer for 2
very low level reasons. 1) a TCP/UDP socket is formed
concatenating a network layer address (IP address) and the
layer TCP/UDP port number. 2) included in the TCP/UDP
calculation are the IP layer source and destination
mentioned above which are transferred across the TCP/IP [Postel
1981b] or UDP/IP [Postel, 1980] interfaces as procedure
arguments. It should be noted at this point that the reason for
strong dependence between the transport and network layers in TCP/
or UDP/IP is to insure a globally unique TCP/UDP layer address,
that a unique connection could be identified by a pair of sockets
The authors of this paper propose that the IP address
with TCP and UDP be replaced with a globally unique transport
(TA) concatenated with a transport layer port address. This
offers the capability to still maintain a globally unique address
host unique port number with the added benefit of eliminating
transport and network layer dependence on one another
3.2 User
In addition to TCP and UDP, there are a large number of
entrenched higher level applications that use the IP network
address embedded internally, and would therefore require
for use with the proposed IPng network layer schemes.
applications include, but are not limited to Network File
(NFS), Remote Procedure Call (RPC), and File Transfer Protocol (FTP).
All of these applications should be modified to use the
Domain name to identify the remote node, and not an embedded
protocol dependent IP address
3.3 The Entrenched
Will users voluntarily give up their IPv4 systems to move to IPng
It seems likely that many users will resist the change. They
perceive no benefit and will not install the new software.
the local Internet contact responsible may not be feasible
practical in all cases. Another issue is backward
issues. If a host needs to run IPng and IPv4 to support old hosts
then 1) where is the address savings IPng promised. 2) Why change
the host you are talking to has IPv4 anyway
On the other hand, replacing the existing TCP (TCPv6) with this
version (TCPng) will benefit users in several ways. 1) Users will
able to connect to unmodified TCPv6 hosts. 2) As nodes upgrade
TCPng, new features will be enabled allowing TCP to
effectively over high bandwidth*delay network links. 3)
Carlson & Ficarella [Page 6]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
administrators will be able to incrementally upgrade nodes as
or as local conditions demand. 4) Upgraded nodes may return
IPv4 address and use an IPng address and TCP transporter function
described later, to communicate with IPv4 hosts
4. Making TCP & UDP Protocol
The OSI 7 layer model specifies that each layer be independent of
adjacent layers. What is specified is the interface between layers
This allows layers to be replaced and/or modified without
changes to the other layers. As was pointed out previously, the
and UDP transport layers violate this precept. In the
discussion, when we refer to TCP we mean both the TCP and
protocols. The generic term transport layer and TCP will be
interchangeably
Overcoming TCP's dependence on IP will require changes to
structure of the TCP header. The developers and implementors
also have to change the way they think about TCP and IP. End
will also have to change the way they view the Internet. Gone
be the days when Internet node names and IP addresses can be
interchangeably. The goal of this change is to allow end users
migrate from the current IPv4 network layer to an IPng layer.
this IPng protocol is will be left to the Internet
Board/Internet Engineering Steering Group/Internet Engineering
Force (IAB/IESG/IETF) to decide. By adopting this proposal,
migration will be greatly enhanced
One of the stated goals of the IAB is to promote a single
protocol suite [Leiner, Rekhter, 1993]. While this is a
goal, we should not be blinded by it. The addition of a
layer address (TA) does not invalidate the IAB's stated goals.
merely brings the implementation into compliance with
networking practices. The historical reasons for concatenating
port numbers to IP numbers has long since passed. The
throughput of transmission lines and the negligible effect of
overhead (see appendix A) prove this. The details of assigning
using TA's are discussed in the next few sections
4.1 Transport
A Transport Address (TA) will be assigned to the TCP transport
on each Internet node. The purpose of this address is to allow a
on one node to communicate with a TCP on a remote node. Some of
goals defined in developing this address are
1. Fixed size -- A fixed size will make parsing easier
decoding stations
Carlson & Ficarella [Page 7]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
2. Minimum impact on TCP packet size -- This
will need to be carried each TCP packet
3. Global Uniqueness -- It is desirable (required) to have
globally unique Transport Address
4. Automatic Registration -- To reduce
problems, an automatic registration of the TA
desirable
The TA will be used when an Internet node attempts to
with another Internet node. Conceptually you can view the TA
replacing the IP number in every instance it now appears in
transport layer (i.e., a socket would change from IP#.Port#
TA#.Port#). A connection setup would thus be
1. A user starts an application on Node-A and
service from Node-B. The user identifies Node-B
referencing it's Internet Domain Name
2. The TCP on Node-A makes a Domain Name Service (DNS)
to determine the TA of Node-B
3. Node-A constructs a TCP packet using the header Src = TA
A.port and Dest = TA-B.port and passes this packet down
the network layer
4. The IP on Node-A makes a DNS call to determine the
address of Node-B. The IP will cache this TA/IP pair
later use
5. Node-A constructs an IP packet using the header Src = IP-
and Dest = IP-B and passes this packet down to the
Access layer
6. Delivery of the packet is identical to the delivery of
existing Internet IP packet
7. The IP on Node-B examines the IP Dest address and if
matches it's own, strips off the header and passes
data portion up to the TCP. (Note: the packet may
passed through several IP routers between the source
destination hosts.)
8. The TCP on Node-B examines the header to determine if
Dest TA is it's own, if so it passes the data to
application specified by the port address. If not
determines if it should perform the transporter function
Carlson & Ficarella [Page 8]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
The packet will be forwarded toward the destination or
error message will be returned
The above steps represent a quick synopsis of how user
may pass data between different Internet nodes. The exact
of the network is hidden from the application, allowing the
to be modified and improved as needed. Using the
function, several different network layers may be traversed
moving from source to destination (several examples are provided
appendix D).
One of the underlying assumptions is that the user application
refrain from making assumptions about the network structure.
pointed out in section 3, this is not the case for the
Internet network. User applications that are deployed with this
TCP must be capable of making this assumption. This means that
user application should store the Internet Domain Name in it'
internal structure instead of the IPng network number. The
name is globally unique and provides enough information to the
to find the transport and network layer addresses. The
application must pass the following parameters down to TCP
1. Destination domain name (Text string
2. Pointer to data
3. Quality of service
4.
When the user application writes data to the network, TCP will
a nonzero integer to indicate an error condition, or a zero
to indicate success. When the user application reads data from
network, TCP will deliver a pointer to a data buffer back to
application
TCP will receive the users request and it will make a DNS call
determine the destination nodes TA. If DNS returns a TA, TCP
build a Transmission Control Block (TCB) (see the paragraph below
and call the network layer. Otherwise, TCP will make a DNS
looking for the destination nodes IPv4 address. If an address
returned, TCP will takes the steps listed below in building a TCB
and call the proper network layer. If DNS returns a host
indication, exit back to the user with a "host unknown" error.
should maintain a cache of domain names and addresses in lieu
making repeated DNS calls. This feature is highly recommended,
not required
The state information needed to keep track of a TCP connection
kept in the Transmission Control Block (TCB). Currently
structure has fields for the TCP parameters, source port,
Carlson & Ficarella [Page 9]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
port, window size, sequence number, acknowledgment number, and
TCP options. The network layer source and destination IP numbers
also stored here. Finally, the status of the connection (LISTEN
ESTABLISHED, CLOSING, of the TCP parameters and include the
source and destination Transport addresses. The existing space
the IPv4 addresses will be left in place to allow for
compatibility. The IPv4 fields will be used if the source
communicating directly with an unmodified TCP/IP host
The existing status indicators will remain with their
unchanged. Connection setup will retain the current 3-way handshake
When performing transporter functions, TCP will NOT build a TCB
unless the destination is an unmodified IPv4 host (see appendix D).
The TCP connection remains an end-to-end reliable transport service
regardless of the number of intermediate transporter nodes
TCP will build an old or new header (defined below) placing the
application data in the data field. If TCP is communicating
with an unmodified IPv4 host, the existing TCP header (STD 7,
793) will be used for comparability reasons. If the destination
is an unmodified host, and an intermediate transporter node is
used, this new TCP header must be used with the 'C' bit set to 1.
The destination TA will be set to the IPv4 address, and the
will be delivered to the transporter node. If the destination
is modified with this new TCP, the destination address will be set
the TA and the packet will be delivered, possibly through
transporter, to the remote host
TCP will communicate with it's underlying network layer(s) to
packets to remote hosts. The Internet Assigned Number
(IANA) will assign unique identifiers to each network layer TCP
support. TCP will maintain a cache of TA's and IANA network
numbers, to allow support of multiple network layers. When
wishes to send data, it will consult this cache to determine
network to send the packet to. If the destination TA is not in
cache, TCP will send a request to each of it's network layer(s
asking if they know how to deliver data to this TA. All of
network layers supported by the sending host will be probed, in
order defined by the system administrator, until one responds 'yes
or they all have said 'no'. The first layer to say 'yes' will
used. If no path exists, an error message will be returned to
user application. Once a network layer is identified, TCP
communicate with it by passing the following parameters
1) Destination address (TA or IPv4).
2) A pointer to the data buffer
3) Options
Carlson & Ficarella [Page 10]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
The network layer will use the destination address as an index into
cache to determine the network address to send to. In the entry
not in the cache, it will make a DNS call to determine the
address and a cache entry will be build (see appendix D). It
mandatory that a cache be maintained. If a host is attached
several different networks (i.e., a transporter) each layer
maintain it's own cache
When IP receives a data packet from a remote node, it will strip
the IP header and pass a pointer to the data buffer up to TCP.
will also supply TCP with it's IANA network layer number. TCP
use the source TA and the IANA number to update it's cache
The structure of a TA is to concatenate a unique manufacture
with a manufacturer defined variable to form a unique 64 bit number
The unique manufacture code will be a 24 bit number, possibly
same code as the IEEE 802.3 MAC address code. The remaining 40
will be supplied by the manufacture to uniquely identify the TCP.
is recommended that this field be built by encoding
manufacturer's serial number. An integer serial number will
viewed as an integer number and converted into it's
equivalent, left padded with 00 octets if necessary. If a
number contains Alpha characters, these alpha characters will
converted into octets using the international standard ASCII code
The integer values will then be converted to their
equivalent and the 2 values will be concatenated to form the
identifier. These structure will allow 2^24 (16,777,216)
manufactures to build 2^40 (1,099,511,627,776) transport
entities. Each of these entities may have 1 or more
interfaces using IPv4, IPng, or any other network layer protocol
The current growth of the Internet may indicate that this amount
address space is inadequate. A larger fixed space (i.e., 96 or 128
bits) or a variable length field may be required. The
is that this address must be transmitted in every packet
Carlson & Ficarella [Page 11]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
4.2
The new TCP header is as shown
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination TA +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source TA +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port Number | ver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | QoS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Window Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Sequence Number +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Acknowledgment Number +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data offset |X|X|C|A|P|R|S|F| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Variable length option 1 /
\ : \
/ : /
\ Variable length Option n \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
Destination TA: 64 bits
The Destination Transport Address. The concatenation
the 24 bit IEEE assigned Ethernet address and the 40
representation of the machines serial number for
remote node
Carlson & Ficarella [Page 12]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
Source TA: 64 Bits
The Source Transport Address. The concatenation of
24 bit IEEE assigned Ethernet address and the 40
representation of the machines serial number for
local node
Destination Port Number: 28 Bits
Identifies the specific application on the remote node
Ver: 4 bits
Version number. This is TCPng. RFC 793
references 9 earlier editions of ARPA TCP. The
TCP is version 10.
Source Port Number: 28 Bits
Identifies the specific application on the local node
QoS: 4 bits
The Quality of Service parameter may be set by the
application and passed down to a network layer
supports different levels of service
Window: 32 Bits
The number of data octets beginning with the
indicated in the acknowledgment field which the
of this segment is willing to accept
Sequence Number: 64 Bits
The sequence number of the first data octet in this
(accept when the S bit is present). If S bit is on,
sequence number is the initial sequence number (ISN)
the first data octet is ISN+1. (The ISN is computed
the existing algorithm).
Acknowledgment Number: 64 Bits
If the A bit is set, this field contains the value
the next sequence number the sender of this segment
expecting to receive. Once a connection is established
this is always sent
Data Offset: 8 Bits
This is the number of 32 bit words in the TCP header.
indicates where the data begins. The TCP header is
integral number of 32 bit words long. The minimum value
12 and the maximum is 256. If options are used, they
pad out to a 32 bit boundary
Carlson & Ficarella [Page 13]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
Flags: 8 Bits
The A, P, R, S, and F flags carry the same meaning as
the current version of TCP. They are
1. A = Ack, and acknowledgment field
2. P = Push, the push
3. R = Reset, reset the
4. S = Sync, synchronize sequence
5. F = Fin, No more data from
The C bit, C = Compatibility, is used to indicate that
end of the connection is an unmodified TCP/IP host.
the C bit is set, all header values must conform to
TCPv6 specifications. The source port, destination port
and window size must be 16 bits and the Sequence
Acknowledgment numbers must be 32 bits. These values
stored in the lower half of the proper area with null
pads filling out the rest of the field
The 2 X bits, X = Reserved, are not defined and must
ignored by a receiving TCP
Checksum: 16 Bits
The checksum field has the same meaning as in the
version of TCP. The current 96 bit pseudo header is
used in calculating the checksum. The checksum covers
the information present in this header. The checksum
itself is set to zero for the calculation
Variable Length Options
There are two types of options, mandatory and optional.
TCP must implement all known mandatory options. It
also be capable of ignoring all optional options it
not know about. This will allow new options to
introduced without the fear of damage caused by
options. An option field must end on a 32 bit boundary
If not, null octet pad characters will be appended to
right of the option. The structure of an option is
in figure 2 below
Carlson & Ficarella [Page 14]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option data | pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
4.3 Mandatory
There are three mandatory options defined by this implementation
TCP. Each of these options is implemented using the
pictured in figure 2 above
A description of each field follows
Type: 16
The type field identifies the particular option
Length: 16
The length field represents the size of the
data to follow, in octets
Option Data: Variable
The option data is of variable length specified
the length field, plus 0-3 bytes of zeros to pad to
32-bit boundary
The following are the 3 mandatory options that must be implemented
Null: 8
The null option, (type=0) is represented by the
sequence [00000000], preceded by an additional 8,
padding bits to fill out the full 16-bit type field.
data may be of any size, including 0 bytes. The option
be used to force an option to be ignored
Maximum Segment Size: 8
The maximum segment size option, (type=1) is represented
the bit sequence [00000001] preceded by an additional 8,
zero padding bits to fill out the full 16-bit type field
If this option is present, then it communicates the
receive segment size at the TCP which sends this segment
This potion is mandatory if sent in the initial
request (SYN). If it is sent on any other segment it
advisory. The data is a 32-bit word specifying the
Carlson & Ficarella [Page 15]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
size in octets [Ullmann, 1993].
Urgent Pointer: 8
The urgent pointer, (type=2) is represented by the
sequence [00000010] preceded by an additional 8,
padding bits to fill out the full 16-bit type field.
option emulates the urgent field in TCPv6. The data is
64-bit sequence number identifying the last octet of
data within the segment
4.4 Optional
This version of TCP must be capable of accepting any unknown options
This is to guarantee that when presented with an unrecognized option
TCP will not crash, however it must not reject or ignore any option
4.5 Compatibility
The Internet community has a large installed base of IP users.
resources required to operate this network, both people and machine
is enormous. These resources will need to be preserved. The
time a change like this took place, moving from NCP to TCP,
were a few 100 nodes to deal with [Postel, 1981c]. A small
knit group of engineers managed the network and mandated a one
migration strategy. Today there are millions of nodes and
of administrators. It will be impossible to convert any portion
the Internet to a new protocol without effecting the rest of
community
In the worst case, users will lose communications with their peers
some systems upgrade and others do not. In the current
environment, this will not be tolerated. Any attempt to
replace the current IPv4 protocol with a new IPng protocol that
not address compatibility issues is doomed to failure.
reasoning has recently been realized by Ullmann (CATNIP) and
attempts to use translators to convert from one protocol to
(i.e., CATNIP to IPv4). The problem is what to do when
parameters are encountered. Also CATNIP would need to be
every time a new network layer protocol was developed
This proposal attempts to solve these problems by decoupling
transport and network protocols. By allowing TCP to operate
different network layer protocols, we will create a more
environment. New network layer protocols could be developed
implemented without requiring changes that are visible to the
community. As TCP packets flow from host-to-host they may
several different network layers, allowing users to
without having to worry about how the data is moved across
Carlson & Ficarella [Page 16]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
underlying network
4.5.1 Backward
It may be said that the maturity of a software package can
determined by how much code is required to maintain
with previous versions. With the current growth of the Internet
backward compatibility issues can not be dismissed or added in as
after thought. This version of TCP was designed with
compatibility in mind. When the TCP communicates with an
IPv4 TCP/IP, it takes steps to insure compatibility. First off
sets a bit in the header indicating that the TCP parameters (ack
seq, port numbers, and window size) use the TCPv6 values.
communicating directly with an unmodified host the existing TCP/
header is used. Only existing TCP options may be sent as well
The advantage of this approach is that TCP transporter nodes will
have to make decisions about how to modify packets just
through. It is up to the source node to build a header that
compatible before sending it. This approach will allow any new
to contact and communicate with any unmodified IPv4 host. The
host may have an IPv4 address, or it may send data to a
for delivery. The decision will be made based on the source
destination addresses. During connection setup, the location of
destination node is determined and the proper network layer is
to send data
An existing IPv4 host will be capable of opening a connection to
new TCPng host that is directly connected to the network with an IPv
protocol stack. If the TCPng host only has an IPng stack,
connection attempt will fail. Some existing batch style
(i.e., Simple Mail Transfer Protocol - SMTP) will continue to
with the help of transporters. Interactive sessions (i.e., Telnet
will fail. Thus, our new TCP is backward compatible, but
existing IPv4 hosts are not forward compatible
4.6 Level 4
The ability to allow hosts with differing network layer protocols
communicate will be accomplished by using a transport layer
(called transporter in this paper). The transporter works just
an IP router, receiving TCP packets from one network layer
transporting them over to another. This switching is done
examining the packets source and destination TA's. If a TCP
arrives with a destination TA that differs from this hosts TA,
the transporter functionality is enabled, the packet should
transported to another network layer. In some cases, the
node is a host and not a transporter (i.e., transporter
Carlson & Ficarella [Page 17]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
disabled). In this case the host will discard the packet and
a TCMP (see below) error message
A transporter is not responsible for reading or formatting the
header of packets it receives. The header is simply examined
determine where to deliver the packet. When forwarding, the
is sent to any of the network layers the transporter supports.
exception is that the packet may not be presented back to the
it was received from. It is the responsibility of the network
to destroy undeliverable packets. If a transporter is unable
determine which network the packet should be forwarded to, the
is discarded and a TCMP message is generated and returned to
original source host. Several examples of how transporting works
presented in appendix D
4.7 Error
It is recognized that from time to time certain error conditions
occur at some intermediate transporter that will need to
communicated back to the source host. To accomplish this a
Control Message Protocol (TCMP) service facility will need to
developed. This protocol will model itself after the
Control Message Protocol (ICMP). The operational details
discussed in a separate TCMP document
5. Advantages and Disadvantages of this
This proposal offers the Internet community several advantages
First, TCPng will operate over multiple network layer
stacks. Users will be able to select the stack(s) that meets
needs. The problem of IPv4 address exhaustion will be postponed
sites move from IPv4 to IPng protocol stacks. Future IP3g
stacks may be designed and deployed without major
disruptions. The increased size of the sequence, acknowledge,
window fields will allow applications to run effectively over
bandwidth-delay network links. Lastly, TCPng will allow
to specify certain Quality of Service (QoS) parameters which may
used by some network layer protocols (i.e., Asynchronous
Mode - ATM).
This protocol is not without it's share of design compromises.
these are a large packet header increased in size from 5 to 12
words. The addition of a TA means that network administrators
deal with yet another network number that must be
maintained. Multiple network protocols may add to the complexity
a site's network. Lastly, is the TA address space large enough so
will not have to rebuild TCP
Carlson & Ficarella [Page 18]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
6.
In this paper, we have reviewed the current status of the
society s IPng initiative. We were struck by the enormity of
changes required by those proposals. We felt that a
approach was needed to allow change to occur in a controlled manner
This approach calls for replacing the current TCP protocol with
that does not require a specific IP layer protocol. Once this is
place, various IPng protocols may be developed and deployed as
require them. Communications between IPv4 and IPng hosts will
maintained throughout the transition period. Modified hosts will
able to remove their IPv4 protocol stacks, while
communications with unmodified hosts by using a TCP transporter
The title of this paper "Six Virtual Inches to the Left" comes from
talk the author once heard. In this talk an engineer from
Data Corporation (CDC) told a story of CDC's attempt to build
cryogenically cooled super computer. The idea being that the
consumption of such a computer would be far lower then that of
conventional super computer. As the story goes, everyone
this was a great idea until someone pointed out what the
requirements of the cryo system were. The result was that all
assumed power savings were consumed by the cryo system.
implication being that all the power requirements were not saved
simply moved 6 feet from the CPU to the support equipment. The
being that the entire system should be analyzed instead of just
small piece
[Postel, 1981a] Postel, J., "Transmission Control Protocol -
Internet Program Protocol Specification", STD 7, RFC 793, DARPA
September 1981.
[Halsal, 1992] Data Communications, Computer Networks, and
Systems
[Meyer, Zobrist, 1990] TCP/IP versus OSI, The Battle of
Network Standards, IEEE Potentials
[Braden, et al, 1991] Clark, D., Chapin, L., Cer, V., Braden, R.,
R. Hobby, "Towards the Future Internet Architecture", RFC 1287,
MIT, BBN, CNRI, ISI, UCDavis, December 1991.
[Dixon, 1993] Dixon, T., "Comparison of Proposals for Next Version
IP", RFC 1454, RARE, May 1993.
Carlson & Ficarella [Page 19]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
[Fuller, et al, 1992] Fuller, V., Li, T., Yu, J., and K. Varadhan
"Supernetting: an Address Assignment and Aggregation Strategy",
RFC 1338, BARRNet, cicso, Merit, OARnet, June 1992.
[Almquist, Gross, 1992] Gross, P., and P. Almquist, "
Deliberations on Routing and Addressing", RFC 1380, IESG Chair
IESG Internet AD, November 1992.
[Postel, 1981b] Postel, J., "Transmission Control Protocol -
Internet Program Protocol Specification", STD 7, RFC 793, DARPA
September 1981.
[Postel, 1980] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[Postel, 1981c] Postel, J., "NCP/TCP Transition Plan", RFC 801,
USC/Information Sciences Institute, November 1981.
[Leiner, Rekhter, 1993] Leiner, B., and Y. Rekhter, "
Multi-Protocol Internet" RFC 1560, USRA, IBM, December 1993.
[Ullmann, 1993] Ullmann, R., "TP/IX: The Next Internet", RFC 1475,
Process Software Corporation, June 1993.
Gilligan, Nordmark, and Hinden, "The SIPP Interoperability
Transition Mechanism", IPAE, 1993.
Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay Paths",
RFC 1072, LBL, USC/Information Sciences Institute, October 1988.
Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for
Performance", RFC 1323, LBL, USC/Information Sciences Institute,
Research, May 1992.
Jacobson, V., Braden, R., and L. Zhang, "TCP Extension for High-
Paths", RFC 1185, LBL, USC/Information Sciences Institute, PARC
October 1990.
Leiner, B., and Y. Rekhter, "The Multiprotocol Internet", RFC 1560,
USRA, IBM, December 1993.
O'Malley, S., and L. Peterson, "TCP Extensions Considered Harmful",
RFC 1263, University of Arizona, October 1991.
Westine, A., Smallberg, D., and J. Postel, "Summary of
Surveys", RFC 847, USC/Information Sciences Institute, February 1983.
Carlson & Ficarella [Page 20]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
Appendix
The minimum size of an ethernet frame is 64 bytes. With the
TCP/IP protocol, a minimum size frame is 18 bytes (ethernet header &
trailer) + 20 bytes (IP header) + 20 bytes (TCP header) for a
of 58 bytes. The transmitting station must add 6 null pad
to this frame to make it conform to the 64 byte minimum. This
TCP will increase the size of the TCP header to 48 bytes
Subtracting 26 bytes (the old header and pad characters) we are
with 22 bytes or 176 bits. The time it takes to transmit
additional bits is the impact of this new TCP. The transmission
for several types of media currently used is shown in the
below. You will note that the increased times are all under 20
micro-seconds for anything over T1 speeds. User traffic
vary of course but it is generally agreed that 80% of the
stays at the local site. If this is true then the increased
size has a negligible impact on communications
Media Speed (Mbps) Rate (nsec/bit) time (usec
------ ------------ --------------- ----------
T1 1.544 647.7 144.00
T3 44.736 22.4 3.91
Enet 10.00 100.0 17.60
FDDI 100.00 10.0 1.76
OC-1 51.84 19.3 3.40
OC-3 155.52 6.4 1.13
Appendix
In order to support the TA, new DNS entries will need to be created
It is hoped that this function will be accomplished automatically
When a station is installed, the local DNS server is defined.
power up, the station will contact this server and send it it's
and domain name. A server process will be listening for this type
information, and it will collect the data, run an
check, and install the TA into the DNS server. The following
will be made
node.sub.domain.name IN TA xx.yy.zz.aa.bb.cc.dd.
ee.dd.cc.bb.aa.zz.yy.aa.in-addr.tcp IN PTR node.sub.domain.name
Using these entries, along with the existing DNS A records,
requesting node can determine where the remote node is located.
format xx.yy.zz is the IEEE assigned portion and aa.bb.cc.dd.ee
the encoded machine serial number as described in section 4.1.
Carlson & Ficarella [Page 21]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
Appendix
Proposed UDP
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Destination TA +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source TA +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Port Number | ver |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | QoS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Data /
\ : \
/ : /
\ : \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination TA: 64 bits
The Destination Transport Address. The concatenation
the 24 bit IEEE assigned Ethernet address and the 40
representation of the machines serial number for the
node
Source TA: 64 Bits
The Source Transport Address. The concatenation of the 24
bit IEEE assigned Ethernet address and the 40
representation of the machines serial number for the
node
Destination Port Number: 28 Bits
Identifies the specific application on the remote node
Ver: 4 bits
This parameter the UDP version number in use within
packet
Carlson & Ficarella [Page 22]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
Source Port Number: 28 Bits
Identifies the specific application on the local node
QoS: 4 bits
The Quality of Service parameter may be set by the
application and passed down to a network layer
supports different levels of service
Length: 16
The length parameter represents the length of the data
in octets. This value will be set to zero if no data
sent within this packet
Checksum: 16
The checksum parameter has the same meaning as in
current version of UDP. The current 96 bit pseudo
is NOT used in calculating the checksum. The
covers only the information present in this header.
checksum field itself is set to zero for the calculation
Data:
This is the area in which the data for the datagram will
sent. The length of this data in octets is specified
the length parameter above
Carlson & Ficarella [Page 23]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
Appendix
______ ______
| | | |
| H1 | | H2 |
| | | |
|______| |______|
\ / \
\ / \
========================= / \
" "/ |
" (SIPP) " |
" " |
"=========================" |
|
====================
______ " "
| | " CLNP "
| H4 | " "
| | "===================="
|______| |
\ |
\ |
=================== ___|___
" " | |
" "-------| H3 |
" IPv4 " | |
" " |_______|
"=================="
Example 1: H1 Wishes to Establish Communication with H4 (Refer to
figure above.)
1. A user on host H1 attempts to communicate with a
on host H4 by referencing H4 s fully qualified domain name
2. The TCP on H1 makes a DNS call to determine the
address of H4.
3. The DNS call returns only the IPv4 address since H4
determined to be an IPv4 only host
4. The H1 TCP builds a transmission control block (TCB
setting the C-Bit (compatibility) "ON" since H4 is an IPv
host. Included in the TCB will also be DA = IP-H4, SA =
TA1, DP = 1234, SP = 5000 and any state
Carlson & Ficarella [Page 24]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
describing the connection (port numbers are for
purposes only).
5. The IP on H1 makes a DNS call to determine the
IP address of H4 and correspondingly caches both the
address from the TCP as well as the network IP address
later use
6. The packet is now routed using standard SIPP
to H2 this is the only path H1 has to H4.
7. H2 receives the packet from H1. The TCP on H2
the destination TA of the packet and compares it to
own. In this case it does not match, therefore the
should be forwarded
8. H2 s TCP will interrogate the supported
layer(s) and determines the packet must be forwarded to H3.
9. The TCP must now pass the packet the CLNP
layer. The network layer checks its cache to determine
there is a route specified for DA = IP-H4 already in
cache. If so the cache entry is used, if not an entry
created. H2 then routes the packet to H3 via NA3a,
is the network layer address for IP-H4.
10. H3 receives the packet from H2. The TCP on H3
the destination TA of the packet and compares it to
own. Once again, it does not match
11. H3, realizing that the destination address is an IPv
host, and knowing that it itself is directly connected
the IPv4 network constructs an IPv4 compatible header. H
also constructs a TCB to manage the IPv4 connection
12. The packet is sent down to be routed to the IP
standard IP routing procedures
13. H4 receives the packet at which point the IP on
determines that the destination address is its own and
proceeds to strip off the IP header and pass the packet
to the TCP layer
14. The TCP layer than opens the corresponding IPV4_
port (2311) which forms the first half of the connection
the application
Carlson & Ficarella [Page 25]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
15. H4 will now reply with a connection accept message
sending the packet back to H3.
16. H3 s TCP receives the packet and based on
in the TCB determines the packet should be delivered to H1.
H3 uses the steps outlined above to route the packet
through the network structure
Example 2: H2 Wishes to Establish Communication with H3 (Refer to
figure above.)
1. A user on host H2 attempts to communicate with a
on host H3 by referencing H3 s fully qualified domain name
2. The TCP on H2 makes a DNS call to determine the
address of H3.
3. The DNS call returns the TA address for H3.
4. The H2 TCP builds a transmission control block (TCB
setting the C-Bit (compatibility) "OFF" since H3 is an
host. Included in the TCB will also be DA = TA3, SA = TA2,
DP = 1111, SP = 2222 and any state parameters
the connection (port numbers are for example
only).
5. The IPng on H2 makes a DNS call to determine
network IPng address of H3 and correspondingly caches
the TA address from the TCP as well as the network
address for later use
6. The packet is now routed to H3 over the IPng
on that network
7. H3 receives the packet from H2. The TCP on H3
the destination TA of the packet and compares it to
own. In this case it matches
8. H3 s TCP will construct a TCB and respond with an
accept message
9. H3 s TCP will interrogate the supported
layer(s) to determine the packet must be delivered to H
using NA2b which is specified in its cache
Carlson & Ficarella [Page 26]
RFC 1705 Six Virtual Inches to the Left: IPng Problems October 1994
Security
Security issues are not discussed in this memo
Authors'
Richard
Argonne National
Electronics and Computing
Argonne, IL 60439
Phone: (708) 252-7289
EMail: RACarlson@anl.
Domenic
Phone: (708) 632-4029
EMail: ficarell@cpdmfg.cig.mot.
Carlson & Ficarella [Page 27]
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
