Internet Draft R. L. Ullmann
Process Software Corporation
August 12, 1992
TCP/IP: Internet Version 7
1 Status of this Memo
This memo describes some ideas for the next version of the Internet
protocols.
It is not even experimental, just so much blue sky at this time.
It is cast as a protocol description to provide the rigor of a formal
description, not to indicate that the details are in some way
immutable. The author feels that he has read too many descriptions of
possible methods (in various areas, not just network communications)
that consist mostly of hand-waving.
The first version of this memo, describing a possible Internet Version
7 protocol 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.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts).
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a "working draft"
or "work in progress."
Please check the I-D abstract listing contained in each Internet Draft
directory to learn the current status of this or any other Internet
Draft.
This draft expires on or before February 12, 1993.
Ullmann DRAFT: expires February 12, 1993 [page 1]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
2 Contents
1 Status of this Memo . . . . . . . . . . . . . . . . 1
2 Contents . . . . . . . . . . . . . . . . . . . . . . 2
3 Introduction . . . . . . . . . . . . . . . . . . . . 4
3.1 Objectives . . . . . . . . . . . . . . . . . . . . 4
3.2 Philosophy . . . . . . . . . . . . . . . . . . . . 4
4 Internet numbers . . . . . . . . . . . . . . . . . . 5
4.1 Is 64 Bits Enough? . . . . . . . . . . . . . . . . 5
4.2 The version 7 IP address . . . . . . . . . . . . . 5
4.3 AD numbers . . . . . . . . . . . . . . . . . . . . 6
4.4 Mapping of version 4 numbers . . . . . . . . . . . 6
5 IP: Internet datagram protocol . . . . . . . . . . . 7
5.1 IP datagram header format . . . . . . . . . . . . 8
5.1.1 version . . . . . . . . . . . . . . . . . . . . . 8
5.1.2 header length . . . . . . . . . . . . . . . . . . 8
5.1.3 time to live . . . . . . . . . . . . . . . . . . . 8
5.1.4 total datagram length . . . . . . . . . . . . . . 8
5.1.5 destination . . . . . . . . . . . . . . . . . . . 9
5.1.6 source . . . . . . . . . . . . . . . . . . . . . . 9
5.1.7 protocol . . . . . . . . . . . . . . . . . . . . . 9
5.1.8 checksum . . . . . . . . . . . . . . . . . . . . . 9
5.1.9 options . . . . . . . . . . . . . . . . . . . . . 9
5.2 Option Format . . . . . . . . . . . . . . . . . . 9
5.2.1 Class (C) . . . . . . . . . . . . . . . . . . . . 9
5.2.2 Copy on fragmentation (F) . . . . . . . . . . . 10
5.2.3 Type . . . . . . . . . . . . . . . . . . . . . . 10
5.2.4 Length . . . . . . . . . . . . . . . . . . . . . 10
5.2.5 option data . . . . . . . . . . . . . . . . . . 10
5.3 IP options . . . . . . . . . . . . . . . . . . . 10
5.3.1 Null . . . . . . . . . . . . . . . . . . . . . . 10
5.3.2 Fragment . . . . . . . . . . . . . . . . . . . . 11
5.3.3 Last Fragment . . . . . . . . . . . . . . . . . 11
5.3.4 Don't Fragment . . . . . . . . . . . . . . . . . 12
5.3.5 Don't Convert . . . . . . . . . . . . . . . . . 12
6 TCP: Transport protocol . . . . . . . . . . . . . 12
6.1 TCP segment header format . . . . . . . . . . . 12
6.1.1 data offset . . . . . . . . . . . . . . . . . . 13
6.1.2 MBZ . . . . . . . . . . . . . . . . . . . . . . 13
6.1.3 Flags . . . . . . . . . . . . . . . . . . . . . 13
6.1.4 checksum . . . . . . . . . . . . . . . . . . . . 13
6.1.5 Source port . . . . . . . . . . . . . . . . . . 13
6.1.6 Destination port. . . . . . . . . . . . . . . . 13
6.1.7 Sequence . . . . . . . . . . . . . . . . . . . . 13
6.1.8 Acknowledgement . . . . . . . . . . . . . . . . 13
6.1.9 Window . . . . . . . . . . . . . . . . . . . . . 13
6.1.10 Options . . . . . . . . . . . . . . . . . . . . 14
6.2 Port numbers . . . . . . . . . . . . . . . . . . 14
6.3 TCP options . . . . . . . . . . . . . . . . . . 14
6.3.1 Null . . . . . . . . . . . . . . . . . . . . . . 14
6.3.2 Maximum Segment Size . . . . . . . . . . . . . . 14
6.3.3 Urgent Pointer . . . . . . . . . . . . . . . . . 14
6.3.4 32 Bit rollover . . . . . . . . . . . . . . . . 14
7 UDP: User Datagram protocol . . . . . . . . . . . 15
7.1 UDP header format . . . . . . . . . . . . . . . 15
Ullmann DRAFT: expires February 12, 1993 [page 2]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
7.1.1 data offset . . . . . . . . . . . . . . . . . . 15
7.1.2 MBZ . . . . . . . . . . . . . . . . . . . . . . 15
7.1.3 checksum . . . . . . . . . . . . . . . . . . . . 15
7.1.4 Source port . . . . . . . . . . . . . . . . . . 15
7.1.5 Destination port. . . . . . . . . . . . . . . . 15
7.1.6 Options . . . . . . . . . . . . . . . . . . . . 15
8 Notes on the domain system . . . . . . . . . . . . 16
8.1 A records . . . . . . . . . . . . . . . . . . . 16
8.2 PTR zone . . . . . . . . . . . . . . . . . . . . 16
9 Conversion between version 4 and version 7 . . . . 16
9.1 Version 4 IP address extension option . . . . . 17
9.1.1 Option format . . . . . . . . . . . . . . . . . 17
9.2 Fragmented datagrams . . . . . . . . . . . . . . 17
9.3 Design considerations . . . . . . . . . . . . . 17
9.4 Conversion from IPv4 to IPv7 . . . . . . . . . . 18
9.5 Conversion from IPv7 to IPv4 . . . . . . . . . . 18
9.6 Conversion from TCPv4 to TCPv7 . . . . . . . . . 20
9.7 Conversion from TCPv7 to TCPv4 . . . . . . . . . 20
10 Implementation plan . . . . . . . . . . . . . . . 21
10.1 Short Term: . . . . . . . . . . . . . . . . . . 21
10.2 In the transition . . . . . . . . . . . . . . . 22
10.3 Long term . . . . . . . . . . . . . . . . . . . 22
11 References . . . . . . . . . . . . . . . . . . . . 23
12 Author's Address . . . . . . . . . . . . . . . . . 23
Ullmann DRAFT: expires February 12, 1993 [page 3]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
3 Introduction
3.1 Objectives
The following are some of the objectives of the design. They are
presented in no particular order.
1. Use what has been learned from the IP version 4 protocol,
fixing things that are troublesome, and not fixing that which
is not broken.
2. Retain the essential "look and feel" of the Internet protocol
suite. It has been very successful, and one doesn't argue
with success.
3. 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.
4. 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.
5. Likewise, we must not impose the new version, telling sites
they must convert NOW to stay connected. People resist
imposed solutions. It is better to seduce.
6. To that end: It must be possible for a router (acting as an
internetwork layer gateway) to convert datagrams in both
directions without retained state, so that version 4 and the
new version hosts can interoperate.
7. All existing applications must continue to work during the
transition, and continue to work after the transition with
only minor modifications.
3.2 Philosophy
Protocols should become simpler as they evolve.
Ullmann DRAFT: expires February 12, 1993 [page 4]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
4 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 now (1989), but both will in time become
more serious:
1. The division into network, and then subnet, is insufficient.
Almost all sites need a network assignment large enough to
subnet; while at the top of the hierarchy, there is a need to
assign administrative domains.
2. The 32 bit limit causes more and more aggravation, attempting
to bit-pack to accomplish the desired network structure.
4.1 Is 64 Bits Enough?
Consider: (thought experiment) 32 bits presently numbers "all" of the
computers in the world, and another 32 bits could be used to number
all of the bytes of on-line storage on each computer. (Most have a
lot less than 4 gigabytes on-line, the ones that have more could be
notionally assigned more than one address.)
So: 64 bits is enough to number every byte of online storage in
existence today, in a hierarchical structured numbering plan.
Another way of looking at 64 bits: it is more than 2 billion
addresses for each person on the planet. Even if I have
microprocessors in my shirt buttons I'm not going to have that many.
32 bits, on the other hand, was never going to be sufficient: there
are more than 2^32 people.
Making the address 64 bits implies (at least ...) a new IP header
format, which is called here "IP version 7"; there isn't anything
magic about the number 7, I made it up. (4 and 5 are used, 6 is the
next available number; but I liked 7. Some other people have also
discussed the next version as "IP version 7".)
4.2 The version 7 IP address
The Version 7 IP 64 bit address looks like:
+-------+-------+-------+-------+-------+-------+-------+-------+
| Admin Domain | Network | Host |
+-------+-------+-------+-------+-------+-------+-------+-------+
Note: the boundary between "network" and "host" is no more fixed than
it is today; each (sub)network will have its own mask. Just as the
mask today can be anywhere from FF00 0000 (8/24) to FFFF FFFC (30/2),
the mask for the 64 bit address can reasonably be FFFF FF00 0000 0000
(24/40) to FFFF FFFF FFFF FFFC (62/2).
Ullmann DRAFT: expires February 12, 1993 [page 5]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
The AD (Administrative domain), identifies an administration which may
be a service provider, a national administration, or a large
multi-organization (i.e. a government). The idea is that there
should not be more than a few hundred of these at first, and
eventually thousands or tens of thousands at most. (But note that we
do not introduce a hard limit of 2^16 here; this estimate may be off
by a few orders of magnitude.)
Most individual organizations would not be ADs. In the short term,
ADs are known to the "core routing"; it pays to keep the number
smallish, a few thousand given current routing technology. In the
long term, this is not necessary. Big administrations (i.e. with
tens of millions of networks) get small blocks where needed, or
additional single AD numbers when needed.
While the AD may be used for last resort routing (with a 24/40 mask),
it is primarily only an administrative device. Most routing will be
done on the entire 48 bit AD+network number, or sub and super-sets of
those numbers. (I.e. masks between about 32/32 and 56/8.)
Some ADs (e.g. NSF) may make permanent assignments; others (such as a
telephone company defining a network number for each subscriber line)
may tie the assignment to such a subscription. But in no case does
this require traffic to be routed via the AD.
4.3 AD numbers
AD numbers are allocated out of the same numbering space as network
numbers. This means that an version 4 address can be distinguished
from the first 32 bits of a version 7 address. This is useful to help
prevent the inadvertant use of the first half of the longer address by
a version 4 host. (Note: this should not be coded into software:
the point is that there will be no route available; the "wrong"
address will be unreachable. If it was coded in, that software would
break when the entire 24 bit space is used for ADs.)
ADs are allocated in the range 96.0.0 to 126.255.255, using the top
1/4 of the version 4 class A space. It is probably best to allocate
the first component downwards from 126, so that the boundary between
class A and AD can be moved if desired later. This initial allocation
provides for 2031616 ADs, many more than there should be even in full
deployment.
Eventually, both AD and network will use the full 24 bit space
available to them.
4.4 Mapping of version 4 numbers
Initially, all existing Internet numbers are defined as belonging to
the NSF/Internet AD, number 126.0.0.
Ullmann DRAFT: expires February 12, 1993 [page 6]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
The mapping from/to version 4 IP addresses:
+-------+-------+-------+-------+-------+-------+-------+-------+
| Admin Domain | Network | Host |
+-------+-------+-------+-------+-------+-------+-------+-------+
[ fixed at 7E 00 00 ] [ 1st 24 bits of V4 IP] [1] [last 8]
So, for example, 192.42.95.15 (V4) becomes 126.0.0.192.42.95.1.15.
And the "standard" loopback I/F address becomes 126.0.0.127.0.0.1.1 (I
can see explaining that in 2015 to someone born in 1995.)
The present protocol multicast (126.0.0.224.x.y.1.z) and loopback
addresses are permanently allocated in the NSF AD.
5 IP: Internet datagram protocol
The Internet datagram protocol is revised to expand some fields (most
notably the addresses), while removing and relegating to options all
fields not universally useful (imperative) in every datagram in every
environment.
This results in some simplification, a length less than twice the size
of IPv4 even though most fields are doubled in size, and an expanded
space for options.
There is also a change in the option philosophy from IPv4: it
specified that implementation of options was not optional, what was
optional was the existence of options in any given datagram. This is
changed in IPv7: no option need be implemented to be fully
conformant. However, implementations must understand the option
classes; and a future Host Requirements specification for hosts and
routers used in the "connected Internet" may require some options in
its profile, e.g. Fragment would probably be required.
Digression: In IPv4, options are often "considered harmful"; it is
the considered opnion of the present author that this is because they
are rarely needed, and not designed to be processed rapidly on most
architectures, and this leads to little or no attempt to improve
performance in implementations, while at the same time enormous effort
is dedicated to optimization of the no-option case. IPv7 is expected
to be different on both counts.
Fields are always aligned on their own size; the 64 bit fields on 64
bit intervals from the start of the datagram.
Options are all 32 bit aligned, and the null option can be used to
push a subsequent option (or the transport layer header) into 64 bit
or 64+32 off-phase alignment as desired.
Ullmann DRAFT: expires February 12, 1993 [page 7]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
5.1 IP datagram header format
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| header length | time to live |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| total datagram length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ destination address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ source address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A description of each field follows.
5.1.1 version
This document describes version 7 of the protocol.
5.1.2 header length
The header length is a 12 bit count of the number of 32 bit words in
the IPv7 header. This allows a header to be (theoretically at least)
up to 16380 bytes in length.
5.1.3 time to live
The time to live is a 16 bit count, in tenth seconds. Each hop is
required to decrement TTL by at least one.
This definition should allow continuation of the useful (even though
not entirely valid) interpretation of TTL as a hop count, while we
move to faster networks and routers. (The most familiar use is by
"traceroute", which really ought to be directly implemented by one or
more ICMP messages.)
5.1.4 total datagram length
The 32 bit length of the entire datagram in octets. A datagram can
therefore be up to 4294967295 bytes in overall length. Particular
networks will normally impose lower limits.
Ullmann DRAFT: expires February 12, 1993 [page 8]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
5.1.5 destination
The 64 bit IPv7 destination address.
5.1.6 source
The 64 bit IPv7 source address.
5.1.7 protocol
The upper layer protocol, e.g. TCP is 6. The present code space for
this layer of demultiplexing is about half full. Expanding it to 16
bits, allowing 65535 registered "transport" layers seems prudent.
5.1.8 checksum
The checksum is a 16 bit checksum of the entire IP header, using the
familiar algorithm used in IPv4.
5.1.9 options
Options may follow. They are variable length, and always 32 bit
aligned, as discussed previously.
5.2 Option Format
Each option begins with a 32 bit header:
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C |F| type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option data ... | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A description of each field:
5.2.1 Class (C)
This field tells implementations what to do with datagrams containing
options they do not understand. No implementation is required to
implement (i.e. understand) any given option by the TCP/IP
specification itself.
Classes:
0 use or forward and include this option unmodified
1 use this datagram, but do not forward it
2 discard, or forward and include this option unmodified
3 discard this datagram
Ullmann DRAFT: expires February 12, 1993 [page 9]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
A host receiving a datagram addressed to itself will use it if there
are no unknown options of class 2 or 3. A router receiving a datagram
not addressed to it will forward the datagram if and only if there are
no unknown options of class 1 or 3. (The astute reader will note that
the bits can also be seen as having individual interpretations, one
allowing use even if unknown, one allowing forwarding if unknown.)
Note that classes 0 and 2 are imperative: if the datagram is
forwarded, the unknown option must be included.
Class and type are entirely orthogonal, different implementations
might use different classes for the same option, except where
restricted by the option definition.
Also note that for options that are known (implemented by) the host or
router, the class has no meaning; the option definition totally
determines the behavior. (Although it should be noted that the option
might explicitly define a class dependent behavior.)
5.2.2 Copy on fragmentation (F)
If the F bit is set, this option must be copied into all fragments
when a datagram is fragmented. If the F bit is reset (zero), the
option must only be copied into the first (zero-offset) fragment.
5.2.3 Type
The type field identifies the particular option, types being
registered as well known values in the internet. A few of the options
with their types are described below.
5.2.4 Length
Length of the option data, in bytes.
5.2.5 option data
Variable length specified by the length field, plus 0-3 bytes of zeros
to pad to a 32 bit boundary. Fields within the option data that are
64 bits long are normally placed on the assumption that the option
header is off-phase aligned, the usual case when the option is the
only one present, and immediately follows the IP header.
5.3 IP options
The following sections describe the options defined to emulate IPv4
features, or necessary in the basic structure of the protocol.
5.3.1 Null
The null option, type 0, provides for a space filler in the option
area. The data may be of any size, including 0 bytes (perhaps the
most useful case.)
Ullmann DRAFT: expires February 12, 1993 [page 10]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
It may be used to change alignment of the following options or to
replace an option being deleted, by setting type to 0 and class to 0,
leaving the length and content of the data unmodified. (Note that
this implies that options must not contain "secret" data, relying on
class 3 to prevent the data from leaving the domain of routers that
understand the option.)
Null is normally class 0, and need not be implemented to serve its
function.
5.3.2 Fragment
Fragment (type 1) indicates that the datagram is part of a complete IP
datagram. It is always class 2.
The data consists of (one of) the 64 bit IP address(es) of the router
doing the fragmentation, a 64 bit datagram ID generated by that
router, and a 32 bit fragment offset. The IDs should be generated so
as to be very likely unique over a period of time larger than the MSL.
(The TCP ISN generator might be used to initialize the ID generator in
a router.)
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C |F| type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ fragmenting router IP address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ datagram ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If a datagram must be refragmented, the original 128 bit address+ID is
preserved, so that the datagram can be reassembled from any sufficient
set of the resulting fragments.
A router implementing Fragment (doing fragmentation) must recognize
the Don't Fragment option.
5.3.3 Last Fragment
Last Fragment (type 2) has the same format as Fragment, but implies
that this datagram is the last fragment needed to reassemble the
original datagram.
Ullmann DRAFT: expires February 12, 1993 [page 11]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
Note that an implementation can reasonably add arriving datagrams with
Fragment to a cache, and then attempt a reassembly when a datagram
with Last Fragment arrives (and the the total length is known); this
will work well when datagrams are not reordered in the network.
5.3.4 Don't Fragment
This option (type 3, class 0) indicates that the datagram may not be
fragmented. If it can not be forwarded without fragmentation, it is
discarded, and the appropriate ICMP message sent. (Unless, of course,
the datagram is an ICMP message.)
5.3.5 Don't Convert
The Don't Convert option prohibits conversion from IPv7 to IPv4
protocol, requiring instead that the datagram be discarded and an ICMP
message sent (conversion failed/don't convert set). It is type 4,
usually class 0, and must be implemented by any router implementing
conversion.
6 TCP: Transport protocol
The 64 bit fields (sequence and acknowledgement) in the TCP header are
off-phase aligned, in anticipation of the usual case of the TCP header
following the 7 32-bit word IP header.
6.1 TCP segment header format
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data offset | MBZ |A|P|R|S|F| checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ sequence number +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ acknowledgement number +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| window |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ullmann DRAFT: expires February 12, 1993 [page 12]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
A description of each field:
6.1.1 data offset
An 8 bit count of the number of 32 bit words in the TCP header,
including any options.
6.1.2 MBZ
Reserved bits, must be zero, and must be ignored.
6.1.3 Flags
These are the protocol state flags, use exactly as in TCPv4, except
that there is no urgent data flag.
6.1.4 checksum
This is a 16 bit checksum of the segment.
6.1.5 Source port
The source port number, a 32 bit identifier. See the section on port
numbers below.
6.1.6 Destination port.
The 32 bit destination port number.
6.1.7 Sequence
A 64 bit sequence number, the sequence number of the first octet of
user data in the segment.
The ISN (Initial Sequence Number) generator used in TCPv4 is used in
TCPv7, with the 32 bit value loaded into both the high and low 32 bits
of the TCPv7 sequence number. This provides reasonable behavior when
the 32 bit rollover option is used (see below) for TCPv4
interoperation.
6.1.8 Acknowledgement
The 64 bit acknowledgement number, acknowledging receipt of octets up
to but not including the octet identified. Valid if the A flag is
set, if A is reset (0), this field should be zero, and must be
ignored.
6.1.9 Window
The 32 bit offered window.
Ullmann DRAFT: expires February 12, 1993 [page 13]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
6.1.10 Options
TCP options, some of which are documented below.
6.2 Port numbers
Port numbers are divided into several ranges: (all numbers are
decimal)
0 reserved
1-32767 Internet registered ("well-known") protocols
32768-98303 reserved, to allow TCPv7-TCPv4 conversion
98304 up dynamic assignment
It must also be remembered that hosts are free to dynamically assign
for active connections any port not actually in use by that host;
hosts must not reject connections because the "client" port is below
some limit, in the registered range.
6.3 TCP options
6.3.1 Null
The null option (type = 0), is to be ignored.
6.3.2 Maximum Segment Size
Maximum segment size (type = 1) specifies the largest segment that the
other TCP should send, in terms of the number of data octets. When
sent on a SYN segment, it is mandatory; if sent on any other segment
it is advisory.
Data is one 32 bit word specifying the size in octets.
6.3.3 Urgent Pointer
The urgent pointer (type = 2) emulates the urgent field in TCPv4. Its
presence is equivalent to the U flag being set. The data is a 64 bit
sequence number identifying the urgent octet. (Not an offset, as in
v4.)
6.3.4 32 Bit rollover
The 32 bit rollover option (type = 3) indicates that only the low
order 32 bits of the sequence and acknowledgement packets are
significant in the packet.
This is necessary because a converting internet layer gateway has no
retained state, and cannot properly set the high order bits. This
option must be implemented by version 7 hosts that want to
interoperate with version 4 hosts.
Ullmann DRAFT: expires February 12, 1993 [page 14]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
7 UDP: User Datagram protocol
7.1 UDP header format
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data offset | MBZ | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A description of each field:
7.1.1 data offset
An 8 bit count of the number of 32 bit words in the UDP header,
including any options.
7.1.2 MBZ
Reserved bits, must be zero, and must be ignored.
7.1.3 checksum
This is a 16 bit checksum of the datagram.
7.1.4 Source port
The source port number, a 32 bit identifier. See the section on TCP
port numbers above.
7.1.5 Destination port.
The 32 bit destination port number.
7.1.6 Options
UDP options, none are presently defined.
Ullmann DRAFT: expires February 12, 1993 [page 15]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
8 Notes on the domain system
8.1 A records
Address records will be added to the IN (Internet) zone with IPv7
addresses for all hosts as the transition proceeds. Eventually the
IPv4 addresses will be removed. As mentioned above, the AD space is
initially assigned so that the first 4 octets of a v7 address cannot
be confused with a v4 address (or, rather, the confusion will be to no
effect.)
For example:
DELTA.Process.COM. A 192.42.95.68
A 126.0.0.192.42.95.1.68
8.2 PTR zone
The inverse (PTR) zone is .#, with the IPv7 address (reversed). I.e.
just like .IN-ADDR.ARPA, but with .# instead.
This respects the difference in actual authority: the NSF/DDN NIC is
the authority for the entire space rooted in .IN-ADDR.ARPA. in the v4
Internet, while in the new Internet it holds the authority only for
the AD 0.0.126.#. (Plus, of course, any other ADs assigned to it over
time.)
9 Conversion between version 4 and version 7
As noted in the description of datagram format, it is possible to
provide a mostly-transparent bridge between version 4 and version 7.
This discusses only TCP at the session/transport layer; details for
UDP and others are similar. Most protocols at this layer will
probably need no translation; however it will probably be necessary to
specify exactly which will have translations done.
New protocols at the session/transport layer defined over IPv7 should
have protocol numbers greater than 255, and will not be translated to
IPv4.
Most of the translations should consist of copying various fields,
verifying fixed values in the datagram being translated, and setting
fixed values in the datagram being produced. In general, the checksum
must be verified first, and then a new checksum computed for the
generated datagram.
Ullmann DRAFT: expires February 12, 1993 [page 16]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
9.1 Version 4 IP address extension option
A new option is defined for IP version 4, to carry the extended
addresses of IPv7. This will be particularily useful in the initial
testing of IPv7, during a time when most of the fabric of the internet
is IPv4. An IPv7 host will be able to connect to another IPv7 host
anywhere in the internet even though most of the paths and routers are
IPv4, and still use the full addressing. This will continue to work
until non-unique IPv4 network numbers are assigned, by which time most
of the infrastructure should be IPv7.
9.1.1 Option format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type (tba) | length = 10 | source IPv7 AD number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | src 7th octet | destination IPv7 AD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number ... | dst 7th octet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The source and destination are in IPv4 order (source first), for
consistancy. The type code is tba, to be assigned.
9.2 Fragmented datagrams
Datagrams that have been fragmented must be reassembled be the
converting host or router before conversion. Where the conversion is
being done by the destination host (i.e. the case of a v7 host
receiving v4 datagrams), this is similar to the present fragmentation
model.
When it is being done by an intermediate router (acting as an
internetwork layer gateway) the router should use all of source,
destination, and datagram ID for identification of fragments; note
that destination is used implicitly in the usual reassembly at the
destination. When reassembling an IPv7 datagram, the 128 bit fragment
ID is used as usual.
9.3 Design considerations
The conversion is designed to be fairly efficient in implementation,
especially on RISC architectures, assuming they can either do a
conditional move (or store), or do a short forward branch without
losing the instruction cache. The other conditional branches in the
body of the code are usually not-taken out to the failure/discard
case.
Handling options does involve a loop and a dispatch (case) operation.
The options in IPv4 are more difficult to handle, not being designed
for speed on a 32 bit aligned RISCish architecture, but they do not
occur often, except perhaps the address extension option.
Ullmann DRAFT: expires February 12, 1993 [page 17]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
For CISC machines, the same considerations will lead to fairly
efficient code.
9.4 Conversion from IPv4 to IPv7
Individual steps in the conversion; the order is in most cases not
significant.
1. Verify checksum.
2. Verify fragment offset is 0, MF flag is 0.
3. Verify version is 4.
4. Multiply TTL by 10, extend to 16 bits. If a multiply is too
expensive, shift left 3 bits (multiply by 8).
5. Set first 3 octets of destination to AD (i.e. 126.0.0), copy
first three octets from v4 address, set next octet to 1, copy
last octet. (This can be done with shift/mask/or operations
on most architectures.)
6. Do the same translation on source address.
7. Copy protocol, set high 8 bits to zero.
8. If DF flag set, add Don't Fragment option.
9. If Address Extension option present, copy ADs and subnet
extension numbers into destination and source.
10. If (RFC791) Security option is present, discard datagram.
(No conversion available.)
11. [source route options]
12. Compute new IP header length.
13. Convert session/transport layer (TCP) header and data.
14. Compute new overall datagram length.
15. Calculate IPv7 checksum.
9.5 Conversion from IPv7 to IPv4
The steps to convert IPv7 to IPv4 follow. Note that the converting
router or host is partly in the role of destination host; it checks
both bits of class in IP options, and (as in the other direction) must
reassemble fragmented datagrams.
Ullmann DRAFT: expires February 12, 1993 [page 18]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
1. Verify checksum.
2. Verify version is 7
3. Set type-of-service to 0 (there may be an option defined,
that will be handled later).
4. If length is greater than (about) 65000, fail.
5. Generate an ID (using an ISN based sequence generator,
possibly also based on destination or source or both).
6. Set flags and fragment field to 0.
7. Divide TTL by 10, if zero, fail (send ICMP Time Exceeded).
If divide is too expensive, shift right 4 bits (divide by
16).
8. If next layer protocol is greater than 255, fail. Else copy.
9. Copy first 3 octets and 8th octet of destination to
destination address.
10. Same for source address.
11. Generate v4 address extension option. (If enabled, this
probably should be a router configuration option; should
default to on.)
12. Process v7 options. If any unknown options of class not 0
found, fail.
13. If Don't Fragment option found, set DF flag.
14. If Don't Convert option found, fail.
15. [source routes]
16. Compute new IP header length. This may fail (too large),
fail conversion if so.
17. Convert session/transport layer (e.g. TCP).
18. Compute new overall datagram length. If greater than 65535,
fail.
19. Compute IPv4 checksum.
Ullmann DRAFT: expires February 12, 1993 [page 19]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
9.6 Conversion from TCPv4 to TCPv7
1. Verify v4 checksum.
2. Copy flags (except for Urgent).
3. If source port is less than 32768 (a sign condition test will
suffice on most architectures), copy it. If equal or
greater, add 65536.
4. Same operation on destination port.
5. Copy sequence to low 32 bits, set high to 0.
6. Copy acknowledgement to low 32 bits, set high to 0.
7. Copy window. (The TCPv4 performance extension window-scale
cannot be used, as it would require state; we use the basic
window offered.)
8. Add 32 bit rollover option.
9. Convert maximum segment size option if present.
10. Compute data offset and copy data.
11. Compute new checksum.
12. return to IP layer conversion.
9.7 Conversion from TCPv7 to TCPv4
1. Verify v7 checksum.
2. If source port is greater than 65535, subtract 65536. If
result is still greater than 65535, fail. (Send ICMP
conversion failed/port conversion out of range. The sending
host may then reset its port number generator to 98304.)
3. Same translation for destination port.
4. Copy low 32 bits of sequence number.
5. (If A bit set), copy low 32 bits of acknowledgement.
6. Copy flags.
7. If window is greater than 61440, set it to 24576. If less,
copy it unchanged.
Ullmann DRAFT: expires February 12, 1993 [page 20]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
8. Process options. If 32 Bit Rollover is not present, and A
flag is set, fail.
9. If Urgent is present, compute offset. If in segment, set U
flag and offset field. If not, ignore.
10. Convert Maximum Segment Size option. If greater than 16384,
set to 16384.
11. Compute new data offset.
12. Compute v4 checksum.
13. Return to IP layer conversion.
10 Implementation plan
There are two major phases to the implementation:
1. Short term, in which most hosts operate the version 4
protocol
2. Long term, in which most hosts operate the version 7 protocol
It is, in my opinion, important to design the long term, and then plan
the short term to get there. (There is also the Very Short Term, in
which we will work around the class assignments to keep from running
out of B nets, e.g. using methods like CIDR and C .)
10.1 Short Term:
ADs and Net numbers are assigned from the same numbering space. I.e.
ADs are assigned within a block of addresses reserved out of the V4 IP
space. (I assume the block is something like 96.0.0.0 to 126.0.0.0
here.)
Net numbers are universally unique, and orthogonal to ADs.
The v7 inverse zone is created. AD numbers are assigned, and all
existing v4 network assignments are "re-authorized" within their new
ADs. (By default, any existing v4 net is authorized within the
126.0.0 AD.)
Some v7 addresses begin to be added to the DNS.
All hosts run v4. Routers begin to know a bit about v7.
Ullmann DRAFT: expires February 12, 1993 [page 21]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
10.2 In the transition
The transition starts when IPv7 is defined, and never really quite
ends.
Routers can convert from v4 to v7 and back.
IPv7 hosts know how to convert incoming IPv4 datagrams, and know how
to convert outgoing datagrams for local hosts that do not know IPv7.
These are identifiable as those that do not respond to an ARP for the
v7 address.
Routers convert addresses to v7 by adding local AD and a 1 in byte 7;
they convert to v4 by extracting bytes 4 to 6 and 8, and checking that
byte 7 is 1. When the IPv4 address extension option is present, the
conversion uses it.
DNS A records are added with 64 bit addresses for V7 hosts. A V4 host
erroneously using the first 32 bits will find that address unreachable
(in AD range, no actual hosts), and use the other address(es).
Hosts run either v4 or v7 with conversion.
Routers that do v7 know the AD for each local net.
The 7th byte is always 1, except within nets that are all v7, but any
host with a different byte will be unreachable from v4.
10.3 Long term
(After Time T, say 1 July 1994)
All "core" routing is IPv7.
Net numbers are only unique within an AD. A particular net is in
exactly one AD. Networks begin to be assigned non-uniquely, except as
qualified by the AD. The AD only qualifies the net, and provides a
default route; it does not dictate a routing. AD 126.0.0 is just
another AD number that belongs to NSF. (The DDN may well have
acquired a separate AD number by this time.)
Routers use as much of the combined AD+Network as they are able to.
Methods such as BGP will be able to handle 100s of thousands of
network routes, including routes via the "wrong" AD to multi-homed
organizations. Routers using the DNS can discover routes for
individual hosts.
Most hosts run v7. Version 7 hosts ignore DNS A records with only 32
bits. Version 4 hosts can only reach hosts within the local AD.
Ullmann DRAFT: expires February 12, 1993 [page 22]
Internet Draft TCP/IP: Internet Version 7 August 12, 1992
11 References
[ISO3166] International Organization for Standardization. Codes
for the Representation of Names of Countries. ISO
3166, ISO, 1988.
[ISO4217] International Organization for Standardization. Codes
for the representation of currencies and funds. ISO
4217, ISO, 1981.
[RFC791] Jon Postel, editor. Internet Protocol. DARPA Internet
Program Protocol Specification. RFC 791 ISI/USC.
September, 1981.
[RFC793] Jon Postel, editor. Transmission Control Protocol.
DARPA Internet Program Protocol Specification. RFC 793
ISI/USC. September, 1981.
[RFC1058] C. Hedrick. Routing Information Protocol. RFC 1058,
Internet, June, 1988.
[RFC1034] P. Mockapetris. Domain names - concepts and facilities.
RFC 1034, ISI, November, 1987.
[RFC1035] P. Mockapetris. Domain names - implementation and
specification. RFC 1035, ISI, November, 1987.
[RFC1287] D. Clark, L. Chapin, V. Cerf, R. Braden, R. Hobby.
Towards the Future Internet Architecture. December,
1991.
[RFC1338] V. Fuller, T. Li, J. Yu, K. Varadhan. Supernetting: an
Address Assignment and Aggregation Strategy. June,
1992.
12 Author's Address
Robert Ullmann
Process Software Corporation
959 Concord Street
Framingham, MA 01701
USA
Phone: +1 508 879 6994 x226
Email: Ariel@Process.COM
This draft expires on or before February 12, 1993.
