rfc1475.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,539 行 · 第 1/5 页
TXT
1,539 行
Network Working Group R. Ullmann
Request for Comments: 1475 Process Software Corporation
June 1993
TP/IX: The Next Internet
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard. Discussion and
suggestions for improvement are requested. Please refer to the
current edition of the "IAB Official Protocol Standards" for the
standardization state and status of this protocol. Distribution of
this memo is unlimited.
Abstract
The first version of this memo, describing a possible next generation
of Internet protocols, was written by the present author in the
summer and fall of 1989, and circulated informally, including to the
IESG, in December 1989. A further informal note on the addressing,
called "Toasternet Part II", was circulated on the IETF mail list
during March of 1992.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . 3
1.1 Objectives . . . . . . . . . . . . . . . . . . . . 5
1.2 Philosophy . . . . . . . . . . . . . . . . . . . . 6
2. Internet numbers . . . . . . . . . . . . . . . . . . 6
2.1 Is 64 Bits Enough? . . . . . . . . . . . . . . . . 6
2.2 Why version 7? . . . . . . . . . . . . . . . . . . 7
2.3 The version 7 IP address . . . . . . . . . . . . . 7
2.4 AD numbers . . . . . . . . . . . . . . . . . . . . 8
2.5 Mapping of version 4 numbers . . . . . . . . . . . 8
3. IP: Internet datagram protocol . . . . . . . . . . . 9
3.1 IP datagram header format . . . . . . . . . . . . 10
3.1.1 Version . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Header length . . . . . . . . . . . . . . . . . 10
3.1.3 Time to live . . . . . . . . . . . . . . . . . 10
3.1.4 Total datagram length . . . . . . . . . . . . . 11
3.1.5 Forward route identifier . . . . . . . . . . . 11
3.1.6 Destination . . . . . . . . . . . . . . . . . . 11
3.1.7 Source . . . . . . . . . . . . . . . . . . . . 11
3.1.8 Protocol . . . . . . . . . . . . . . . . . . . 11
3.1.9 Checksum . . . . . . . . . . . . . . . . . . . 11
3.1.10 Options . . . . . . . . . . . . . . . . . . . . 11
Ullmann [Page 1]
RFC 1475 TP/IX June 1993
3.2 Option Format . . . . . . . . . . . . . . . . . . 12
3.2.1 Class (C) . . . . . . . . . . . . . . . . . . . 12
3.2.2 Copy on fragmentation (F) . . . . . . . . . . . 13
3.2.3 Type . . . . . . . . . . . . . . . . . . . . . 13
3.2.4 Length . . . . . . . . . . . . . . . . . . . . 13
3.2.5 Option data . . . . . . . . . . . . . . . . . . 13
3.3 IP options . . . . . . . . . . . . . . . . . . . 13
3.3.1 Null . . . . . . . . . . . . . . . . . . . . . 13
3.3.2 Fragment . . . . . . . . . . . . . . . . . . . 14
3.3.3 Last Fragment . . . . . . . . . . . . . . . . . 14
3.3.4 Don't Fragment . . . . . . . . . . . . . . . . 15
3.3.5 Don't Convert . . . . . . . . . . . . . . . . . 15
3.4 Forward route identifier . . . . . . . . . . . . 15
3.4.1 Procedure description . . . . . . . . . . . . . 15
3.4.2 Flows . . . . . . . . . . . . . . . . . . . . . 17
3.4.3 Mobile hosts . . . . . . . . . . . . . . . . . 17
4. TCP: Transport protocol . . . . . . . . . . . . . 18
4.1 TCP segment header format . . . . . . . . . . . . 18
4.1.1 Data offset . . . . . . . . . . . . . . . . . . 19
4.1.2 MBZ . . . . . . . . . . . . . . . . . . . . . . 19
4.1.3 Flags . . . . . . . . . . . . . . . . . . . . . 19
4.1.4 Checksum . . . . . . . . . . . . . . . . . . . 19
4.1.5 Source port . . . . . . . . . . . . . . . . . . 20
4.1.6 Destination port . . . . . . . . . . . . . . . 20
4.1.7 Sequence . . . . . . . . . . . . . . . . . . . 20
4.1.8 Acknowledgement . . . . . . . . . . . . . . . . 20
4.1.9 Window . . . . . . . . . . . . . . . . . . . . 20
4.1.10 Options . . . . . . . . . . . . . . . . . . . . 20
4.2 Port numbers . . . . . . . . . . . . . . . . . . 20
4.3 TCP options . . . . . . . . . . . . . . . . . . . 21
4.3.1 Option Format . . . . . . . . . . . . . . . . . 21
4.3.2 Null . . . . . . . . . . . . . . . . . . . . . 21
4.3.3 Maximum Segment Size . . . . . . . . . . . . . 21
4.3.4 Urgent Pointer . . . . . . . . . . . . . . . . 21
4.3.5 32 Bit rollover . . . . . . . . . . . . . . . . 21
5. UDP: User Datagram protocol . . . . . . . . . . . 22
5.1 UDP header format . . . . . . . . . . . . . . . . 22
5.1.1 Data offset . . . . . . . . . . . . . . . . . . 22
5.1.2 MBZ . . . . . . . . . . . . . . . . . . . . . . 22
5.1.3 Checksum . . . . . . . . . . . . . . . . . . . 22
5.1.4 Source port . . . . . . . . . . . . . . . . . . 22
5.1.5 Destination port . . . . . . . . . . . . . . . 22
5.1.6 Options . . . . . . . . . . . . . . . . . . . . 23
6. ICMP . . . . . . . . . . . . . . . . . . . . . . . 23
6.1 ICMP header format . . . . . . . . . . . . . . . 23
6.2 Conversion failed ICMP message . . . . . . . . . 23
7. Notes on the domain system . . . . . . . . . . . . 25
7.1 A records . . . . . . . . . . . . . . . . . . . . 25
Ullmann [Page 2]
RFC 1475 TP/IX June 1993
7.2 PTR zone . . . . . . . . . . . . . . . . . . . . 25
8. Conversion between version 4 and version 7 . . . . 25
8.1 Version 4 IP address extension option . . . . . . 26
8.1.1 Option format . . . . . . . . . . . . . . . . . . 26
8.2 Fragmented datagrams . . . . . . . . . . . . . . . 26
8.3 Where does the conversion happen? . . . . . . . . 27
8.4 Hybrid IPv4 systems . . . . . . . . . . . . . . . 28
8.5 Maximum segment size in TCP . . . . . . . . . . . 28
8.6 Forwarding and redirects . . . . . . . . . . . . . 28
8.7 Design considerations . . . . . . . . . . . . . . 28
8.8 Conversion from IPv4 to IPv7 . . . . . . . . . . . 29
8.9 Conversion from IPv7 to IPv4 . . . . . . . . . . . 30
8.10 Conversion from TCPv4 to TCPv7 . . . . . . . . . . 31
8.11 Conversion from TCPv7 to TCPv4 . . . . . . . . . . 32
8.12 ICMP conversion . . . . . . . . . . . . . . . . . 33
9. Postscript . . . . . . . . . . . . . . . . . . . . 33
10. References . . . . . . . . . . . . . . . . . . . . 34
11. Security Considerations . . . . . . . . . . . . . 35
12. Author's Address . . . . . . . . . . . . . . . . . 35
1. Introduction
This memo presents the specification for version 7 of the Internet
Protocol, as well as version 7 of the TCP and the user datagram
protocol. Version 7 has been designed to address several major
problems that have arisen as version 4 has evolved and been deployed,
and to make a major step forward in the datagram switching and
forwarding architecture of the Internet.
The major problems are threefold. First, the address space of
version 4 is now seen to be too small. While it was viewed as being
almost impossibly large when version 4 was designed, two things have
occurred to create a problem. The first is a success crisis: the
internet protocols have been more widely used and accepted than their
designers anticipated. Also, technology has moved forward, putting
microprocessors into devices not anticipated except as future dreams
a decade ago.
The second major problem is a perceived routing explosion. The
present routing architecture of the internet calls for routing each
organization's network independently. It is becoming increasingly
clear that this does not scale to a universal internet. While it is
possible to route several billion networks in a flat, structureless
domain, it is not desireable.
There is also the political administrative issue of assigning network
numbers to organizations. The version 4 administrative system calls
for organizations to request network assignments from a single
Ullmann [Page 3]
RFC 1475 TP/IX June 1993
authority. While to some extent this has been alleviated by
reserving blocks to delegated assignments, the address space is not
large enough to do this in the necessary general case, with large
blocks allocated to (e.g.) national authority.
The third problem is the increasing bandwidth of the networks and of
the applications possible on the network. The TCP, while having
proven useful on an unprecedented range of network speeds, is now the
limiting factor at the highest speeds, due to restrictions of window
size, sequence-space, and port numbers. These limitations can all be
addressed by increasing the sizes of the relevant fields. See
[RFC1323].
There is also an opportunity to move the technology forward, and take
advantage of a combination of the best features of the hop-by-hop
connectionless forwarding of version 4 (and CLNP) as well as the
pre-established paths of version 5 (and, e.g., the OSI CONS).
Internet Version 7 includes four major areas of improvement, while at
the same time retaining interoperation with version 4 with a small
amount of conversion knowledge imposed on version 7 hosts and
routers.
o It increases the address fields to 64 bits, with sufficient
space for visible future expansion of the internet.
o It adds a numbering layer for administrations, above the
organization or network layer, as well as providing more
space for subnetting within organizations.
o It increases the range of speeds and network path delays over
which the TCP will operate satisfactorily, as well as the
number of transactions in bounded time that can be served by
a host.
o Finally, it provides a forward route identifier in each
datagram, to support extremely fast path, circuit, or
flow-based forwarding, or any desired combination, while
preserving hop-by-hop connectivity.
The result is not just a movement sideways, deploying a new network
layer protocol to patch current problems. It is a significant step
forward for network layer technology,
Ullmann [Page 4]
RFC 1475 TP/IX June 1993
1.1 Objectives
The following are some of the objectives of the design.
o Use what has been learned from the IP version 4 protocol, fixing
things that are troublesome, and not fixing that which is not
broken.
o Retain the essential "look and feel" of the Internet protocol
suite. It has been very successful, and one doesn't argue with
success.
o Not introduce concepts that the Internet has shown do not belong
in the protocol definition. Best example: we do not want to add
any kind of routing information into the addressing, other than
the administrative hierarchy that has sometimes proved useful.
Note that the one feature in version 4 addressing (the class
system) designed to aid routing is now the most serious single
problem.
o Allow current hosts to interoperate, if not universally, at least
within an organization or larger area for the indefinite future.
There will be version 4 hosts for 10-15 years into the future,
the Internet must remain on good terms with them.
o Likewise, we must not impose the new version, telling sites they
must convert to stay connected. People resist imposed solutions.
It must not be marketed as something different from IPv4; the
differences must be down-played at every opportunity.
o The design must allow individual hosts and routers to be upgraded
effectively at random, with no transition plan constraints.
o The design must not require renumbering the Internet. The
administrative work already accomplished is immense, if it is to
be done again it will be in assigning NSAPs.
o It must allow IPv4 hosts to interoperate without any reduction in
function, without any modification to their software or
configuration. (Universal connectivity will be lost by IPv4
hosts, but they must be able to continue operating within their
organization at least.)
o It must permit network layer state-free translation of datagrams
between IPv4 and IPv7; this is important to the previous point,
and essential to early testing and transitional deployment.
o It must be a competent alternative to CLNP.
Ullmann [Page 5]
RFC 1475 TP/IX June 1993
o It must not involve changing the semantics of the network layer
service in any way that invalidates the huge amount of work that
has gone into understanding how TCP (for example) functions in
the net, and the implementation of that understanding.
o It must be defined Real Soon; the window of opportunity is almost
closed. It will take vendors 3 years to deploy from the time the
standard is rock-solid concrete.
I believe all of these are accomplishable in a consistent, well-
engineered solution, and all are essential to the survival of the
Internet.
1.2 Philosophy
Protocols should become simpler as they evolve.
2. Internet numbers
The version 4 numbering system has proven to be very flexible,
(mostly) expandable, and simple. In short: it works. There are two
problems, neither serious when this specification was first developed
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?