Six Virtual Inches to the Left: The Problem with IPng
RFC 1705
|
Document |
Type |
|
RFC - Informational
(October 1994; No errata)
|
|
Authors |
|
Richard Carlson
,
Domenic Ficarella
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
Legacy
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
Legacy state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
IESG |
IESG state |
|
RFC 1705 (Informational)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group: R. Carlson
Request for Comments: 1705 ANL
Category: Informational D. Ficarella
Motorola
October 1994
Six Virtual Inches to the Left:
The Problem with IPng
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 RFC suggests that a new version of TCP (TCPng), and UDP, be
developed and deployed. It proposes that a globally unique address
(TA) be assigned to Transport layer protocol (TCP/UDP). The purpose
of this TA is to uniquely identify an Internet node without
specifying any routing information. A new version of TCP, and UDP,
will need to be developed describing the new header fields and
formats. This new version of TCP would contain support for high
bandwidth-delay networks. Support for multiple network layer
(Internet Protocol) protocols is also possible with this new TCP.
Assigning an address to TCP/UDP would allow for the support of
multiple network layer protocols (IPng's). The TA would identify the
location of an Internet node. The IPng layer would provide routing
information to the Internet. Separating the location and routing
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 Contents
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. Introduction
For more than a decade, network engineers have understood the
benefits of a multi-layer protocol stack. However, during its
development, the Transmission Control Protocol (TCP) was strongly
linked to the Internet Protocol (IP) [Postel, 1981a]. When the TCP/IP
protocol suite was developed, two important ideas were implemented.
The first was that each host would be uniquely identified by a
network layer number (i.e., IP number = 192.0.2.1). The second was to
identify an application with a transport layer port number (i.e., TCP
DNS number = 53). For host-to-host communications, the IP and port
numbers would be concatenated to form a socket (i.e., 192.0.2.1.53).
Show full document text