As per Relevance of the word datagram, we have this rfc below:
Network Working Group R.
Request for Comments: 1475 Process Software
June 1993
TP/IX: The Next
Status of this
This memo defines an Experimental Protocol for the
community. It does not specify an Internet standard. Discussion
suggestions for improvement are requested. Please refer to
current edition of the "IAB Official Protocol Standards" for
standardization state and status of this protocol. Distribution
this memo is unlimited
The first version of this memo, describing a possible next
of Internet protocols, was written by the present author in
summer and fall of 1989, and circulated informally, including to
IESG, in December 1989. A further informal note on the addressing
called "Toasternet Part II", was circulated on the IETF mail
during March of 1992.
Table of
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.
This memo presents the specification for version 7 of the
Protocol, as well as version 7 of the TCP and the user
protocol. Version 7 has been designed to address several
problems that have arisen as version 4 has evolved and been deployed
and to make a major step forward in the datagram switching
forwarding architecture of the Internet
The major problems are threefold. First, the address space
version 4 is now seen to be too small. While it was viewed as
almost impossibly large when version 4 was designed, two things
occurred to create a problem. The first is a success crisis:
internet protocols have been more widely used and accepted than
designers anticipated. Also, technology has moved forward,
microprocessors into devices not anticipated except as future
a decade ago
The second major problem is a perceived routing explosion.
present routing architecture of the internet calls for routing
organization's network independently. It is becoming
clear that this does not scale to a universal internet. While it
possible to route several billion networks in a flat,
domain, it is not desireable
There is also the political administrative issue of assigning
numbers to organizations. The version 4 administrative system
for organizations to request network assignments from a
Ullmann [Page 3]
RFC 1475 TP/IX June 1993
authority. While to some extent this has been alleviated
reserving blocks to delegated assignments, the address space is
large enough to do this in the necessary general case, with
blocks allocated to (e.g.) national authority
The third problem is the increasing bandwidth of the networks and
the applications possible on the network. The TCP, while
proven useful on an unprecedented range of network speeds, is now
limiting factor at the highest speeds, due to restrictions of
size, sequence-space, and port numbers. These limitations can all
addressed by increasing the sizes of the relevant fields.
[RFC1323].
There is also an opportunity to move the technology forward, and
advantage of a combination of the best features of the hop-by-
connectionless forwarding of version 4 (and CLNP) as well as
pre-established paths of version 5 (and, e.g., the OSI CONS).
Internet Version 7 includes four major areas of improvement, while
the same time retaining interoperation with version 4 with a
amount of conversion knowledge imposed on version 7 hosts
routers
o It increases the address fields to 64 bits, with
space for visible future expansion of the internet
o It adds a numbering layer for administrations, above
organization or network layer, as well as providing
space for subnetting within organizations
o It increases the range of speeds and network path delays
which the TCP will operate satisfactorily, as well as
number of transactions in bounded time that can be served
a host
o Finally, it provides a forward route identifier in
datagram, to support extremely fast path, circuit,
flow-based forwarding, or any desired combination,
preserving hop-by-hop connectivity
The result is not just a movement sideways, deploying a new
layer protocol to patch current problems. It is a significant
forward for network layer technology
Ullmann [Page 4]
RFC 1475 TP/IX June 1993
1.1
The following are some of the objectives of the design
o Use what has been learned from the IP version 4 protocol,
things that are troublesome, and not fixing that which is
broken
o Retain the essential "look and feel" of the Internet
suite. It has been very successful, and one doesn't argue
success
o Not introduce concepts that the Internet has shown do not
in the protocol definition. Best example: we do not want to
any kind of routing information into the addressing, other
the administrative hierarchy that has sometimes proved useful
Note that the one feature in version 4 addressing (the
system) designed to aid routing is now the most serious
problem
o Allow current hosts to interoperate, if not universally, at
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
must convert to stay connected. People resist imposed solutions
It must not be marketed as something different from IPv4;
differences must be down-played at every opportunity
o The design must allow individual hosts and routers to be
effectively at random, with no transition plan constraints
o The design must not require renumbering the Internet.
administrative work already accomplished is immense, if it is
be done again it will be in assigning NSAPs
o It must allow IPv4 hosts to interoperate without any reduction
function, without any modification to their software
configuration. (Universal connectivity will be lost by IPv
hosts, but they must be able to continue operating within
organization at least.)
o It must permit network layer state-free translation of
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
service in any way that invalidates the huge amount of work
has gone into understanding how TCP (for example) functions
the net, and the implementation of that understanding
o It must be defined Real Soon; the window of opportunity is
closed. It will take vendors 3 years to deploy from the time
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
Internet
1.2
Protocols should become simpler as they evolve
2. Internet
The version 4 numbering system has proven to be very flexible
(mostly) expandable, and simple. In short: it works. There are
problems, neither serious when this specification was first
in 1988 and 1989, but have as expected become more serious
o The division into network, and then subnet, is insufficient
Almost all sites need a network assignment large enough
subnet. At the top of the hierarchy, there is a need
assign administrative domains
o As bit-packing is done to accomplish the desired
structure, the 32 bit limit causes more and more aggravation
2.1 Is 64 Bits Enough
Consider: (thought experiment) 32 bits presently numbers "all"
the computers in the world, and another 32 bits could be used
number all of the bytes of on-line storage on each computer. (
have a lot less than 4 gigabytes on-line, the ones that have
could be notionally assigned more than one address.)
So: 64 bits is enough to number every byte of online storage
existence today, in a hierarchical structured numbering plan
Another way of looking at 64 bits: it is more than 2
addresses for each person on the planet. Even if I
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:
are more than 2^32 people
Ullmann [Page 6]
RFC 1475 TP/IX June 1993
2.2 Why version 7?
It was clearly recognized at the start of this project in 1988
making the address 64 bits implies a new IP header format, which
called either "TP/IX" or "IP version 7"; there wasn't anything
about the number 7, I made it up. Version 4 is the familiar
version of IP. Version 5 is the experimental ST (Stream) protocol
ST-II, a newer version of ST, uses the same version number,
I was not aware of until recently; I suspected it might have
allocated 6. Besides, I liked 7.
Apparently (as reported by Bob Braden) the IAB followed much the
logic, and may have had the idea planted by the mention of version 7
in the "Toasternet Part II" memo. The IAB in June 1992 floated
proposal that CLNP, or a CLNP-based design, be Internet Version 7.
(And promptly got themselves toasted.) However, close inspection
the bits shows that CLNP is clearly version 8.
2.3 The version 7 IP
The Version 7 IP 64 bit address looks like
+-------+-------+-------+-------+-------+-------+-------+-------+
| Admin Domain | Network | Host |
+-------+-------+-------+-------+-------+-------+-------+-------+
Note: the boundary between "network" and "host" is no more
than it is today; each (sub)network will have its own mask. Just
the mask today can be anywhere from FF00 0000 (8/24) to FFFF
(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).
The AD (Administrative Domain), identifies an administration
may be a service provider, a national administration, or a
multi-organization (e.g. a government). The idea is that
should not be more than a few hundred of these at first,
eventually thousands or tens of thousands at most. (But note that
do not introduce a hard limit of 2^16 here; this estimate may be
by a few orders of magnitude.) Since only 1/4th of the address
is initially used (first two bits are 01), the remainder can then
allocated in the future with more information available
Most individual organizations would not be ADs. In the short term
ADs are known to the "core routing"; it pays to keep the
smallish, a few thousand given current routing technology. In
long term, this is not necessary. Big administrations (i.e.,
tens of millions of networks) get small blocks where needed,
additional single AD numbers when needed
Ullmann [Page 7]
RFC 1475 TP/IX June 1993
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
done on the entire 48 bit AD+network number, or sub and super-sets
those numbers. (I.e., masks between about 32/32 and 56/8.)
Some ADs (e.g., NSF) may make permanent assignments; others (such
a telephone company defining a network number for each
line) may tie the assignment to such a subscription. But in no
does this require traffic to be routed via the AD
2.4 AD
AD numbers are allocated out of the same numbering space as
numbers. This means that a version 4 address can be
from the first 32 bits of a version 7 address. This is useful
help prevent the inadvertent use of the first half of the
address by a version 4 host
There is a non-trivial amount of software that assumes that an "int
is the same size and shape as an IP address, and does things
"ipaddr = *(int *)ptr". This usage has always been incorrect,
does occur with disturbing frequency. As IPv7 8 byte
appear in the application layers, this software will find
addresses unreachable; this is preferable to interacting with
random host
One possible method would be to allocate ADs in the range 96.0.0
192.255.255, using the top 1/4 of the version 4 class A space. It
probably best to allocate the first component downwards from 192,
that the boundary between class A and AD can be moved if
later. This initial allocation provides for 2031616 ADs, many
than there should be even in full deployment
Eventually, both AD and network will use the full 24 bit
available to them. Knowledge of the AD range should not be
into software. If it was coded in, that software would break
the entire 24 bit space is used for ADs. (This lesson should
been learned from CIDR.)
2.5 Mapping of version 4
Initially, all existing Internet numbers are defined as belonging
the NSF/Internet AD, number 192.0.0.
Ullmann [Page 8]
RFC 1475 TP/IX June 1993
The mapping from/to version 4 IP addresses
+-------+-------+-------+-------+-------+-------+-------+-------+
| Admin Domain | Network | Host |
+-------+-------+-------+-------+-------+-------+-------+-------+
[ fixed at A0 00 00 ] [ 1st 24 bits of V4 IP] [1] [last 8]
So, for example, 192.42.95.15 (V4) becomes 192.0.0.192.42.95.1.15.
And the "standard" loopback interface address
192.0.0.127.0.0.1.1 (I can see explaining that in 2015 to
born in 1995.)
The present protocol multicast (192.0.0.224.x.y.1.z) and
addresses are permanently allocated in the NSF AD
3. IP: Internet datagram
The Internet datagram protocol is revised to expand some fields (
notably the addresses), while removing and relegating to options
fields not universally useful (imperative) in every datagram in
environment
This results in some simplification, a length less than twice
size of IPv4 even though most fields are doubled in size, and
expanded space for options
There is also a change in the option philosophy from IPv4:
specified that implementation of options was not optional, what
optional was the existence of options in any given datagram. This
changed in IPv7: no option need be implemented to be
conformant. However, implementations must understand the
classes; and a future Host Requirements specification for hosts
routers used in the "connected Internet" may require some options
its profile, e.g., Fragment would probably be required
Digression: In IPv4, options are often "considered harmful". It
the opinion of the present author that this is because they
rarely needed, and not designed to be processed rapidly on
architectures. This leads to little or no attempt to
performance in implementations, while at the same time
effort is dedicated to optimization of the no-option case. IPv7
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
Ullmann [Page 9]
RFC 1475 TP/IX June 1993
push a subsequent option (or the transport layer header) into 64
or 64+32 off-phase alignment as desired
3.1 IP datagram 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| header length | time to live |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| total datagram length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ forward route identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ destination address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ source address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A description of each field follows
3.1.1
This document describes version 7 of the protocol
3.1.2 Header
The header length is a 12 bit count of the number of 32 bit words
the IPv7 header. This allows a header to be (theoretically at least
up to 16380 bytes in length
3.1.3 Time to
The time to live is a 16 bit count, nominally in 1/16 seconds.
hop is required to decrement TTL by at least one
This definition should allow continuation of the useful (even
not entirely valid) interpretation of TTL as a hop count, while
Ullmann [Page 10]
RFC 1475 TP/IX June 1993
move to faster networks and routers. (The most familiar use is
"traceroute", which really ought to be directly implemented by one
more ICMP messages.)
The scale factor converts the usual version 4 default TTL into
larger number of hops. This is desireable because the forward
architecture of version 7 enables the construction of simpler,
switches, and this may cause the network diameter to increase
3.1.4 Total datagram
The 32 bit length of the entire datagram in octets. A datagram
therefore be up to 4294967295 bytes in overall length.
networks will normally impose lower limits
3.1.5 Forward route
The identifier from the routing protocol to be used by the next
router to find its next hop. (A more complete description is
below.)
3.1.6
The 64 bit IPv7 destination address
3.1.7
The 64 bit IPv7 source address
3.1.8
The transport layer protocol, e.g., TCP is 6. The present code
for this layer of demultiplexing is about half full. Expanding it
16 bits, allowing 65535 registered "transport" layers seems prudent
3.1.9
The checksum is a 16 bit checksum of the entire IP header, using
familiar algorithm used in IPv4.
3.1.10
Options may follow. They are variable length, and always 32
aligned, as discussed previously
Ullmann [Page 11]
RFC 1475 TP/IX June 1993
3.2 Option
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
3.2.1 Class (C
This field tells implementations what to do with datagrams
options they do not understand. No implementation is required
implement (i.e., understand) any given option by the TCP/
specification itself
Classes
0 use or forward and include this option
1 use this datagram, but do not forward the
2 discard, or forward and include this option
3 discard this
A host receiving a datagram addressed to itself will use it if
are no unknown options of class 2 or 3. A router receiving
datagram not addressed to it will forward the datagram if and only
there are no unknown options of class 1 or 3. (The astute
will note that the bits can also be seen as having
interpretations, one allowing use even if unknown, one
forwarding if unknown.)
Note that classes 0 and 2 are imperative: if the datagram
forwarded, the unknown option must be included
Class and type are entirely orthogonal, different
might use different classes for the same option, except
restricted by the option definition
Also note that for options that are known (implemented by) the
or router, the class has no meaning; the option definition
determines the behavior. (Although it should be noted that
option might explicitly define a class dependent behavior.)
Ullmann [Page 12]
RFC 1475 TP/IX June 1993
3.2.2 Copy on fragmentation (F
If the F bit is set, this option must be copied into all
when a datagram is fragmented. If the F bit is reset (zero),
option must only be copied into the first (zero-offset) fragment
3.2.3
The type field identifies the particular option, types
registered as well known values in the internet. A few of
options with their types are described below
3.2.4
Length of the option data, in bytes
3.2.5 Option
Variable length specified by the length field, plus 0-3 bytes
zeros to pad to a 32 bit boundary. Fields within the option
that are 64 bits long are normally placed on the assumption that
option header is off-phase aligned, the usual case when the option
the only one present, and immediately follows the IP header
3.3 IP
The following sections describe the options defined to emulate IPv
features, or necessary in the basic structure of the protocol
3.3.1
The null option, type 0, provides for a space filler in the
area. The data may be of any size, including 0 bytes (perhaps
most useful case.)
It may be used to change alignment of the following options or
replace an option being deleted, by setting type to 0 and class to 0,
leaving the length and content of the data unmodified. (Note
this implies that options must not contain "secret" data, relying
class 3 to prevent the data from leaving the domain of routers
understand the option.)
Null is normally class 0, and need not be implemented to serve
function
Ullmann [Page 13]
RFC 1475 TP/IX June 1993
3.3.2
Fragment (type 1) indicates that the datagram is part of a
IP datagram. It is always class 2.
The data consists of (one of) the 64 bit IP address(es) of the
doing the fragmentation, a 64 bit datagram ID generated by
router, and a 32 bit fragment offset. The IDs should be generated
as to be very likely unique over a period of time larger than the
MSL (maximum segment lifetime). (The TCP ISN (initial
number) generator might be used to initialize the ID generator in
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+
is preserved, so that the datagram can be reassembled from
sufficient set of the resulting fragments. The 64 bits fields
positioned so that they are aligned in the usual case of the
option following the IP header
A router implementing Fragment (doing fragmentation) must
the Don't Fragment option
3.3.3 Last
Last Fragment (type 2) has the same format as Fragment, but
that this datagram is the last fragment needed to reassemble
original datagram
Note that an implementation can reasonably add arriving
with Fragment to a cache, and then attempt a reassembly when
datagram with Last Fragment arrives (and the the total length
known); this will work well when datagrams are not reordered in
Ullmann [Page 14]
RFC 1475 TP/IX June 1993
network
3.3.4 Don't
This option (type 3, class 0) indicates that the datagram may not
fragmented. If it can not be forwarded without fragmentation, it
discarded, and the appropriate ICMP message sent. (Unless,
course, the datagram is an ICMP message.) There is no data present
3.3.5 Don't
The Don't Convert option prohibits conversion from IPv7 to IPv
protocol, requiring instead that the datagram be discarded and
ICMP message sent (conversion failed/don't convert set). It is
4, usually class 0, and must be implemented by any
implementing conversion. A host is under no such constraint;
any protocol specification, only the "bits on the wire" can
specified, the host receiving the datagram may convert it as part
its procedure. There is no data present in this option
3.4 Forward route
Each IP datagram carries a 64 bit field, called "forward
identifier", that is updated (if the information is available)
each hop. This field's value is derived from the routing
(e.g., RAP [RFC1476]). It is used to expedite routing decisions
preserving knowledge where possible between consecutive routers.
can also be used to make datagrams stay within reserved flows
mobile-host tunnels where required
3.4.1 Procedure
Consider 3 routers, A, B, and C. Traffic is passing through them
between two other hosts (or networks), X and Y, packets are
XABCY and YCBAX. Consider only one direction: routing info
from C to A, to provide a route from A to C. The same thing will
happening in the other direction
An explanation of the notation
R(r,d,i,h) A route that means: "from router r, to go
final destination d, replace the forward
identifier in the packet with i, and take
hop h."
Ri(r,d) An opaque (outside of router r) identifier, that
be used by r to find R(r,d,...).
Ullmann [Page 15]
RFC 1475 TP/IX June 1993
Flowi(r,rt) An opaque (outside of router r) identifier,
router r can use to find a flow or tunnel with
the datagram is associated, and from that the
rt on which the flow or tunnel is built, as well
the Flowi() for the subsequent hop
Ri(Dgram) The forward route identifier in a datagram
Router C announces a route R(C,Y,0,Y) to router B. It includes in
an identifier Ri(C,Y) internal to C, that will allow C to find
route rapidly. (A table index, or an actual memory address.)
Router B creates a route R(B,Y,Ri(C,Y),C) via router C, it
it to A, including an identifier Ri(B,Y), internal to B, and used
A as an opaque object
Router A creates a route R(A,Y,Ri(B,Y),B) via router B. It has
one to announce it to
Now: X originates a datagram addressed to Y. It has no
information, and sets Ri(Dgram) to zero. It forwards the datagram
router A (X's default gateway).
A finds no valid Ri(Dgram), and looks up the destination (Y) in
routing tables. It finds R(A,Y,Ri(B,Y),B), sets Ri(Dgram) <-
Ri(B,Y), and forwards the datagram to B
Router B looks at Ri(Dgram) which directly identifies the next
route R(B,Ri(C,Y),C), sets Ri(Dgram) <- Ri(C,Y) and forwards it
router C
Router C looks at Ri(Dgram) which directly locates R(C,0,Y),
Ri(Dgram) <- 0 and forwards to Y
Y recognizes its own address in Dest(Dgram), ignores Ri(Dgram).
Of course, the routers will validate the Ri's received,
if they are memory addresses (e.g., M(a) < Ri < M(b), Ri mod N == 0),
and probably check that the route in fact describes the
of the datagram. If the Ri is invalid, the router must use
ordinary method of finding a route (i.e., what it would have done
Ri was 0), and silently ignore the invalid Ri
When a route has been aggregated at some router, implicitly
explicitly, it will find that the incoming Ri(Dgram) at most
identify the aggregation, and it must make a decision; the
datagram then contains the Ri for the specific route. (Note this
happen well upstream of the point at which the routes
Ullmann [Page 16]
RFC 1475 TP/IX June 1993
diverge.)
This allows all cooperating routers to make immediate
decisions, without any searching of tables or caches once
datagram has entered the routing domain. If the host participates
the routing, at least to the extent of acquiring the initial
required from the first router, then only routers that have
aggregations need make decisions. (If the routing changes
datagrams in flight, some router will be required to make a
to re-rail each datagram.)
3.4.2
If a "flow" is to be set up, the identifiers are replaced
Flowi(router,route), where each router's structure for the
contains a pointer to the route on which the flow is built
Datagrams can drop out of the flow at some point, and can be
either by the originating host or by a cooperating router near
originator. Since the forward route identifier field is opaque
the sending router, and implicitly meaningful only to the next
router, use for flows (or similar optimizations) need not
otherwise defined by the protocol. (One presumes that a
issuing both Ri's and Flowi's will take care to make sure that it
distinguish them by some private method.)
If a flow has been set up by a restricted target RAP
announcement, it is no different from a route in the implementation
If this announcement originates from the host itself, the Ri
incoming datagrams can be used to determine whether they followed
flow, or to optimize delivery of the datagrams to the next
protocol
3.4.3 Mobile
First, a definition: A "mobile host" is a host that can move around
connecting via different networks at different times,
maintaining open TCP connections. It is distinguished from
"portable host", which is simply a host that can appear in
places in the net, without continuity. A portable host can
implemented by assigning a new address for each location (more
less automatically), and arranging to update the domain system
Supporting truly mobile hosts is the more interesting problem
To implement mobile host support in a general way, either some
of the protocol suite must provide network-wide routing, or
datagrams must be tunnelled from the "home" network of the host
its present location. In the real network, some combination of
is probable: most of the net will forward datagrams toward the
Ullmann [Page 17]
RFC 1475 TP/IX June 1993
network, and then the datagrams will follow a specific host route
the mobile host
The requirement on the routing system is that it must be able
propagate a host route at least to the home network; any
distribution is useful optimization. When a host route is
by RAP as a targeted route, and the routers use the resulting Ri's
the datagram follows an effective tunnel to the mobile host. (Not
real tunnel, in the strict sense; the datagrams are following
actual route at the network protocol layer.)
As explained in RAP [RFC14XX-RAP], a targeted route can be
when desired; in particular, it can be triggered by the
of a TCP connection or by the arrival of datagrams that do not
an Ri indicating that they have followed a (non-tunnel) route
4. TCP: Transport
Internet version 7 expands the sizes of the sequence
acknowledgement fields, the window, and the port numbers. This is
remove limitations in version 4 that begin to restrict throughput
(for example) the bandwidth of FDDI and round trip delay of more
60 milliseconds. At gigabit speeds and delays typical
international links, the version 4 TCP would be a serious limitation
See [RFC1323].
The port numbers are also expanded. This alleviates the problem
going through the entire port number range with a rapid sequence
transactions in less than the lifetime of datagrams in the network
4.1 TCP segment header
The 64 bit fields (sequence and acknowledgement) in the TCP
are off-phase aligned, in anticipation of the usual case of the
header following the 9 32-bit word IP header. If IP options add
to an odd number of 32 bit words, a null option may be added to
the transport header to off-phase alignment
Ullmann [Page 18]
RFC 1475 TP/IX June 1993
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A description of each field
4.1.1 Data
An 8 bit count of the number of 32 bit words in the TCP header
including any options
4.1.2
Reserved bits, must be zero, and must be ignored
4.1.3
These are the protocol state flags, use exactly as in TCPv4,
that there is no urgent data flag
4.1.4
This is a 16 bit checksum of the segment. The pseudo-header used
the checksum consists of the destination address, the source address
the protocol field (constant 6 for TCP), and the 32 bit length of
TCP segment
Ullmann [Page 19]
RFC 1475 TP/IX June 1993
4.1.5 Source
The source port number, a 32 bit identifier. See the section on
numbers below
4.1.6 Destination port
The 32 bit destination port number
4.1.7
A 64 bit sequence number, the sequence number of the first octet
user data in the segment
The ISN (Initial Sequence Number) generator used in TCPv4 is used
TCPv7, with the 32 bit value loaded into both the high and low 32
bits of the TCPv7 sequence number. This provides reasonable
when the 32 bit rollover option is used (see below) for TCPv
interoperation. V7 hosts must implement the full 64 bit
number rollover
4.1.8
The 64 bit acknowledgement number, acknowledging receipt of octets
to but not including the octet identified. Valid if the A flag
set, if A is reset (0), this field should be zero, and must
ignored
4.1.9
The 32 bit offered window
4.1.10
TCP options, some of which are documented below
4.2 Port
Port numbers are divided into several ranges: (all numbers
decimal
0
1-32767 Internet registered ("well-known")
32768-98303 reserved, to allow TCPv7-TCPv4
98304 up dynamic
It must also be remembered that hosts are free to dynamically
for active connections any port not actually in use by that host
Ullmann [Page 20]
RFC 1475 TP/IX June 1993
hosts must not reject connections because the "client" port is in
registered range
4.3 TCP
4.3.1 Option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option data ... | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.2
The null option (type = 0), is to be ignored
4.3.3 Maximum Segment
Maximum segment size (type = 1) specifies the largest segment
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
segment it is advisory
Data is one 32 bit word specifying the size in octets
4.3.4 Urgent
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 last octet of urgent data. (
an offset, as in v4.)
4.3.5 32 Bit
The 32 bit rollover option (type = 3) indicates that only the
order 32 bits of the sequence and acknowledgement packets
significant in the packet
This is necessary because a converting internet layer gateway has
retained state, and cannot properly set the high order bits.
option must be implemented by version 7 hosts that want
interoperate with version 4 hosts
Ullmann [Page 21]
RFC 1475 TP/IX June 1993
5. UDP: User Datagram
The user datagram protocol is also expanded to include larger
numbers, for reasons similar to the TCP
5.1 UDP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data offset | MBZ | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A description of each field
5.1.1 Data
An 8 bit count of the number of 32 bit words in the UDP header
including any options
5.1.2
Reserved bits, must be zero, and must be ignored
5.1.3
This is a 16 bit checksum of the datagram. The pseudo-header used
the checksum consists of the destination address, the source
address, and the protocol field (constant 17 for UDP), and the 32
length of the user datagram
5.1.4 Source
The source port number, a 32 bit identifier. See the section on
port numbers above
5.1.5 Destination port
The 32 bit destination port number
Ullmann [Page 22]
RFC 1475 TP/IX June 1993
5.1.6
UDP options, none are presently defined
6.
The ICMP protocol is very similar to ICMPv4, in some cases
requiring any conversion
The complication is that IP datagrams are nested within
messages, and must be converted. This is discussed later
6.1 ICMP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | code | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type-specific parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type-specific data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type and code are well-known values, defined in [RFC792]. The
have meaning only within a particular type, they are not orthogonal
The next 32 bit word is usually defined for the specific type
sometimes it is unused
For many types, the data consists of a nested IP datagram,
truncated, which is a copy of the datagram causing the event
reported. In IPv4, the nested datagram consists of the IP header
and another 64 bits (at least) of the original datagram
For IPv7, the nested datagram must include the IP header plus 96
of the remaining datagram (thus including the port numbers within
and UDP), and should include the first 256 bytes of the datagram
I.e., in most cases where the original datagram was not large,
will return the entire datagram
6.2 Conversion failed ICMP
The introduction of network layer conversion requires a new
type, to report conversion errors. Note that an invalid
should result in the sending of some other ICMP message (e.g.,
parameter problem) or the silent discarding of the datagram.
message is only sent when a valid datagram cannot be converted
Ullmann [Page 23]
RFC 1475 TP/IX June 1993
Note: implementations are not expected to, and should not, check
validity of incoming datagrams just to accomplish this; it
means that an error detected during conversion that is known to be
actual error in the incoming datagram should be reported as such,
as a conversion failure
Note that the conversion failed ICMP message may be sent in
the IPv4 or IPv7 domain; it is a valid ICMP message type for IPv4.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | code | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pointer to problem area |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| copy of datagram that could not be converted .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type for Conversion Failed is 31.
The codes are
0 Unknown/unspecified
1 Don't Convert option
2 Unknown mandatory option
3 Known unsupported option
4 Unsupported transport
5 Overall length
6 IP header length
7 Transport protocol > 255
8 Port conversion out of
9 Transport header length
10 32 Bit Rollover missing and ACK
11 Unknown mandatory transport option
The use of code 0 should be avoided, any other condition found
implementors should be assigned a new code requested from IANA.
code 0 is used, it is particularily important that the pointer be
properly
The pointer is an offset from the start of the original datagram
the beginning of the offending field
The data is part of the datagram that could not be converted.
must be at least the IP and transport headers, and must include
field pointed to by the previous parameter. For code 4,
transport header is probably not identifiable; the data
Ullmann [Page 24]
RFC 1475 TP/IX June 1993
include 256 bytes of the original datagram
7. Notes on the domain
7.1 A
Address records will be added to the IN (Internet) zone with IPv
addresses for all hosts as IPv7 is deployed. Eventually the IPv
addresses will be removed. As mentioned above, the
(Administrative Domain) space is initially assigned so that the
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 192.0.0.192.42.95.1.68
It is important that the A record be used, to avoid the
consistancy problem that would arise when different records
different remaining TTLs
Note that if an unmodified version of the more popular public
nameserver is a secondary for a zone containing IPv7 addresses,
will erroneously issue RRs with only the first four bytes. (I.e.,
192.0.0.192 in the example.) This is another reason to ensure
the AD numbers are initially reserved out of the IPv4 network
space. Eventually, zones with IPv7 addresses would be expected to
served only by upgraded servers
7.2 PTR
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
the authority for the entire space rooted in .IN-ADDR.ARPA. in
v4 Internet, while in the new Internet it holds the authority
for the AD 0.0.192.#. (Plus, of course, any other ADs assigned to
over time.)
8. Conversion between version 4 and version 7
As noted in the description of datagram format, it is possible
provide a mostly-transparent bridge between version 4 and version 7.
This discusses TCP and ICMP at the session/transport layer; UDP is
subset of the TCP conversion. Most protocols at this layer
Ullmann [Page 25]
RFC 1475 TP/IX June 1993
probably need no translation; however it will probably be
to specify exactly which will have translations done
New protocols at the session/transport layer defined over IPv7
have protocol numbers greater than 255, and will not be translated
IPv4.
Most of the translations should consist of copying various fields
verifying fixed values in the datagram being translated, and
fixed values in the datagram being produced. In general,
checksum must be verified first, and then a new checksum computed
the generated datagram
8.1 Version 4 IP address extension
A new option is defined for IP version 4, to carry the
addresses of IPv7. This will be particularily useful in the
testing of IPv7, during a time when most of the fabric of
internet is IPv4. An IPv7 host will be able to connect to
IPv7 host anywhere in the internet even though most of the paths
routers are IPv4, and still use the full addressing. This
continue to work until non-unique network numbers are assigned,
which time most of the infrastructure should be IPv7.
8.1.1 Option
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type (147) | 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),
consistancy. The type code is 147.
8.2 Fragmented
Datagrams that have been fragmented must be reassembled by
converting host or router before conversion. Where the conversion
being done by the destination host (i.e., the case of a v7
receiving v4 datagrams), this is similar to the present
model
When it is being done by an intermediate router (acting as
internetwork layer gateway) the router should use all of source
destination, and datagram ID for identification of IPv4 fragments
Ullmann [Page 26]
RFC 1475 TP/IX June 1993
note that destination is used implicitly in the usual reassembly
the destination. When reassembling an IPv7 datagram, the 128
fragment ID is used as usual
If the fragments take different paths through the net, and arrive
different conversion points, the datagram is lost
8.3 Where does the conversion happen
The objective of conversion is to be able to upgrade systems,
hosts and routers, in whatever order desired by their owners
Organizations must be able to upgrade any given system
reconfiguration or modification of any other; and IPv4 hosts must
able to interoperate essentially forever. (IPv4 routers
probably be effectively eliminated at some point, except where
exist in their own remote or isolated corners.)
Each TCP/IP v7 system, whether host or router, must be able
recognize adjacent systems in the topology that are (only) v4,
call the appropriate conversion routine just before sending
datagram
Digression: I believe v7 hosts will get much better performance
doing everything internally in v7, and using conversion to
datagrams when necessary. This keeps the usual code path simple
with only a "hook" right after receiving to convert incoming IPv
datagrams, and just before sending to convert to IPv4. Routers
prefer to keep datagrams in their incoming version, at least
after the routing decision is made, and then doing the
only if necessary. In either case, this is an
specific decision
It must be noted that any forwarding system may convert datagrams
IPv7, then back to IPv4, even if that loses information such
unknown options. The reverse is not acceptable: a system
receives an IPv7 datagram should not convert it to IPv4, then back
IPv7 on forwarding
The preferred method for identifying which hosts require
is to ARP first for the IPv7 address, and then again if no
is received, for the IPv4 address. The reservation of ADs out of
v4 network number space is useful again here, protecting hosts
fail to properly use the ARP address length fields
On networks where ARP is not normally used, the method is to
that a remote system is v7. If an IPv7 datagram is received from it
the assumption is confirmed. If, after a short time, no IPv
datagram is received, a v7 ICMP echo is sent. If a reply is
Ullmann [Page 27]
RFC 1475 TP/IX June 1993
(in either version) the assumption is confirmed
If no reply is recieved, the remote system is assumed not
understand IPv7, and datagrams are converted to IPv4 just
transmitting them
Implementations should also provide for explicit configuration
desired
8.4 Hybrid IPv4
In the course of implementing IPv7, especially in
environments such as small terminal servers, it may be useful
implement the IPv4 address extension option directly,
regaining universal connectivity
This may also be a useful interim step for vendors not prepared to
a major rework of an implementation; but it is important not to
stalled in this step
A hybrid IPv4 + address extension system does not have to
the conversion, it places this onus on its neighbors. It may
have an address with the subnet extension (7th byte) not equal to 1.
The implication of hybrid systems is that it is not valid to
that a host with a IPv7 address is a native IPv7 implementation
8.5 Maximum segment size in
It is probably advisable for IPv4 implementations to reduce the
offered by a small amount where possible, to avoid fragmentation
datagrams are converted to IPv7. This arises when IPv4 hosts
communicating through an IPv7 infrastructure, with the same MTU
the local networks of the hosts
8.6 Forwarding and
It may be important for a router to not send ICMP redirects when
finds that it must do a conversion as part of forwarding
datagram. In this case, the hosts involved may not be able
interact directly. The IPv7 host could ignore the redirect, but
results in an unpleasant level of noise as the sequence
recurs
8.7 Design
The conversion is designed to be fairly efficient in implementation
especially on RISC architectures, assuming they can either do
Ullmann [Page 28]
RFC 1475 TP/IX June 1993
conditional move (or store), or do a short forward branch
losing the instruction cache. The other conditional branches in
body of the code are usually not-taken out to the failure/
case
Handling options does involve a loop and a dispatch (case) operation
The options in IPv4 are more difficult to handle, not being
for speed on a 32 bit aligned RISCish architecture, but they do
occur often, except perhaps the address extension option
For CISC machines, the same considerations will lead to
efficient code
The conversion code must be extremely careful to be robust
presented with invalid input; in particular, it may be presented
truncated transport layer headers when called recursively from
ICMP conversion
8.8 Conversion from IPv4 to IPv
Individual steps in the conversion; the order is in most cases
significant
o Verify checksum
o Verify fragment offset is 0, MF flag is 0.
o Verify version is 4.
o Extend TTL to 16 bits, multiply by 16.
o Set forward route identifier to 0.
o Set first 3 octets of destination to AD (i.e., 192.0.0),
first three octets from v4 address, set next octet to 1,
last octet. (This can be done with shift/mask/or
on most architectures.)
o Do the same translation on source address
o Copy protocol, set high 8 bits to zero
o If DF flag set, add Don't Fragment option
o If Address Extension option present, copy ADs and
extension numbers into destination and source
o Convert other options where possible. If an unknown
Ullmann [Page 29]
RFC 1475 TP/IX June 1993
with copy-on-fragment is found, fail. If copy-on-fragment
not set, ignore the option. I.e., the flag is (ab)used as
indicator of whether the option is mandatory
o Compute new IP header length
o Convert session/transport layer (TCP) header and data
o Compute new overall datagram length
o Calculate IPv7 checksum
8.9 Conversion from IPv7 to IPv
The steps to convert IPv7 to IPv4 follow. Note that the
router or host is partly in the role of destination host; it
both bits of class in IP options, and (as in the other direction
must reassemble fragmented datagrams
o Verify checksum
o Verify version is 7
o Set type-of-service to 0 (there may be an option defined
that will be handled later).
o If length is greater than (about) 65563, fail. (That
is not a typographical error. Note that the IPv7+TCPv
headers add up to 28 bytes more than the corresponding v
headers in the usual case.) This check is only to
useless work, the precise check is later
o Generate an ID (using an ISN based sequence generator
possibly also based on destination or source or both).
o Set flags and fragment field to 0.
o Divide TTL by 16, if zero, fail (send ICMP Time Exceeded).
If greater that 255, set to 255.
o If next layer protocol is greater than 255, fail. Else copy
o Copy first 3 octets and 8th octet of destination
destination address
o Same for source address
o Generate v4 address extension option. (If enabled;
Ullmann [Page 30]
RFC 1475 TP/IX June 1993
probably should be a configuration option, should default
on.)
o Process v7 options. If any unknown options of class not 0
found, fail
o If Don't Fragment option found, set DF flag
o If Don't Convert option found, fail
o Convert other options where possible, or fail
o Compute new IP header length. This may fail (too large),
fail conversion if so
o Convert session/transport layer (e.g., TCP).
o Compute new overall datagram length. If greater than 65535,
fail
o Compute IPv4 checksum
8.10 Conversion from TCPv4 to TCPv
o Subtract header words from v4 checksum. (Note that this
actually done with one's complement addition.)
o Copy flags (except for Urgent).
o If source port is less than 32768 (a sign condition test
suffice on most architectures), copy it. If equal
greater, add 65536.
o Same operation on destination port
o Copy sequence to low 32 bits, set high to 0.
o Copy acknowledgement to low 32 bits, set high to 0.
o Copy window. (The TCPv4 performance extension [RFC1323]
window-scale cannot be used, as it would require state;
use the basic window offered.)
o Add 32 bit rollover option
o Convert maximum segment size option if present
o Compute data offset and copy data
Ullmann [Page 31]
RFC 1475 TP/IX June 1993
o Add header words into saved checksum. It is important not
recompute the checksum over the data; it must remain
end-to-end checksum
o Return to IP layer conversion
8.11 Conversion from TCPv7 to TCPv
o Subtract header from v7 checksum
o If source port is greater than 65535, subtract 65536.
result is still greater than 65535, fail. (Send
conversion failed/port conversion out of range. The
host may then reset its port number generator to 98304.)
o Same translation for destination port
o Copy low 32 bits of sequence number
o If A bit set, copy low 32 bits of acknowledgement
o Copy flags
o If window is greater than 61440, set it to 24576. If less
copy it unchanged. (Rationale for the 24K figure: this
been found to be a good default for IPv4 hosts. If the IPv
host is offering a very large window, the IPv4 host
isn't prepared to play at that level.)
o Process options. If 32 Bit Rollover is not present, and
flag is set, fail. (Send ICMP conversion failed/32
Rollover missing.)
o If Urgent is present, compute offset. If in segment, set
flag and offset field. If not, ignore
o Convert Maximum Segment Size option. If greater than 16384,
set to 16384.
o Compute new data offset
o Add header words into v4 checksum
o Return to IP layer conversion
Ullmann [Page 32]
RFC 1475 TP/IX June 1993
8.12 ICMP
ICMP messages are converted by copying the type and code into the
packet, and copying the other type-specific fields directly
If the message contains an encapsulated, and usually truncated,
datagram, the conversion routine is called recursively to
it as far as possible. There are some special considerations
o The encapsulated datagram is less likely to be valid,
that it did generate an error of some kind
o The conversion should attempt to complete all
available, even if some would cause failures in the
case. Note, in particular, that in the course of
a datagram, when a failure occurs, an ICMP
(conversion failed) is sent; this message itself
immediately require conversion. Part of that conversion
involve converting the original datagram
o Conditions such as overall datagram length too large are
checked
o The AD and subnet byte assumed in the nested conversion
not be sensible if the IPv4 address extension option is
present and the datagram has strayed from the expected AD
(Not unlikely, given that we know a priori that some
occured.)
o The conversion must be very sure not to make
recursive call if the nested datagram is an ICMP message
(This should not occur, but obviously may.)
o It is probably impossible to generate a correct
layer checksum in the nested datagram. The conversion
prefer to just zero the checksum field. Likewise,
the original checksum is pointless
It may be best in a given implementation to have a separate code
for the nested conversion, that handles these issues out of
optimized usual path
9.
The present version of TCP/IP has been a success partly by accident
for reasons that weren't really designed in. Perhaps the
significant is the low level of network integration required to
it work
Ullmann [Page 33]
RFC 1475 TP/IX June 1993
We must be careful to retain the successful ingredients, even
we may be unaware of them. Tread lightly, and use all that we
learned, especially about not changing things that work
This document has described a fairly conservative step forward,
clear extensibility for future developments, but without jumping
the abyss
10.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[RFC791] Postel, J., "Internet Protocol - DARPA Internet
Protocol Specification", STD 5, RFC 791, DARPA
September 198