Documente Academic
Documente Profesional
Documente Cultură
Ullmann
Request for Comments: 1475 Process Software Corporation
June 1993
Abstract
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . 3
1.1 Objectives . . . . . . . . . . . . . . . . . . . . 5
1.2 Philosophy . . . . . . . . . . . . . . . . . . . . 6
2. Internet numbers . . . . . . . . . . . . . . . . . . 6
2.1 Is 64 Bits Enough? . . . . . . . . . . . . . . . . 6
2.2 Why version 7? . . . . . . . . . . . . . . . . . . 7
2.3 The version 7 IP address . . . . . . . . . . . . . 7
2.4 AD numbers . . . . . . . . . . . . . . . . . . . . 8
2.5 Mapping of version 4 numbers . . . . . . . . . . . 8
3. IP: Internet datagram protocol . . . . . . . . . . . 9
3.1 IP datagram header format . . . . . . . . . . . . 10
3.1.1 Version . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Header length . . . . . . . . . . . . . . . . . 10
3.1.3 Time to live . . . . . . . . . . . . . . . . . 10
3.1.4 Total datagram length . . . . . . . . . . . . . 11
3.1.5 Forward route identifier . . . . . . . . . . . 11
3.1.6 Destination . . . . . . . . . . . . . . . . . . 11
3.1.7 Source . . . . . . . . . . . . . . . . . . . . 11
3.1.8 Protocol . . . . . . . . . . . . . . . . . . . 11
3.1.9 Checksum . . . . . . . . . . . . . . . . . . . 11
3.1.10 Options . . . . . . . . . . . . . . . . . . . . 11
Ullmann [Page 1]
RFC 1475 TP/IX June 1993
Ullmann [Page 2]
RFC 1475 TP/IX June 1993
1. Introduction
Ullmann [Page 3]
RFC 1475 TP/IX June 1993
Ullmann [Page 4]
RFC 1475 TP/IX June 1993
1.1 Objectives
o Use what has been learned from the IP version 4 protocol, fixing
things that are troublesome, and not fixing that which is not
broken.
o Not introduce concepts that the Internet has shown do not belong
in the protocol definition. Best example: we do not want to add
any kind of routing information into the addressing, other than
the administrative hierarchy that has sometimes proved useful.
Note that the one feature in version 4 addressing (the class
system) designed to aid routing is now the most serious single
problem.
o Likewise, we must not impose the new version, telling sites they
must convert to stay connected. People resist imposed solutions.
It must not be marketed as something different from IPv4; the
differences must be down-played at every opportunity.
Ullmann [Page 5]
RFC 1475 TP/IX June 1993
1.2 Philosophy
2. Internet numbers
Ullmann [Page 6]
RFC 1475 TP/IX June 1993
Apparently (as reported by Bob Braden) the IAB followed much the same
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 a
proposal that CLNP, or a CLNP-based design, be Internet Version 7.
(And promptly got themselves toasted.) However, close inspection of
the bits shows that CLNP is clearly version 8.
+-------+-------+-------+-------+-------+-------+-------+-------+
| Admin Domain | Network | Host |
+-------+-------+-------+-------+-------+-------+-------+-------+
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 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.
2.4 AD numbers
Eventually, both AD and network will use the full 24 bit space
available to them. Knowledge of the AD range should not be coded
into software. If it was coded in, that software would break when
the entire 24 bit space is used for ADs. (This lesson should have
been learned from CIDR.)
Ullmann [Page 8]
RFC 1475 TP/IX June 1993
+-------+-------+-------+-------+-------+-------+-------+-------+
| Admin Domain | Network | Host |
+-------+-------+-------+-------+-------+-------+-------+-------+
[ fixed at A0 00 00 ] [ 1st 24 bits of V4 IP] [1] [last 8]
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
Ullmann [Page 9]
RFC 1475 TP/IX June 1993
push a subsequent option (or the transport layer header) into 64 bit
or 64+32 off-phase alignment as desired.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1 Version
The scale factor converts the usual version 4 default TTL into a
larger number of hops. This is desireable because the forward route
architecture of version 7 enables the construction of simpler, faster
switches, and this may cause the network diameter to increase.
The identifier from the routing protocol to be used by the next hop
router to find its next hop. (A more complete description is given
below.)
3.1.6 Destination
3.1.7 Source
3.1.8 Protocol
The transport 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.
3.1.9 Checksum
3.1.10 Options
Options may follow. They are variable length, and always 32 bit
aligned, as discussed previously.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Classes:
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.)
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.
3.2.3 Type
3.2.4 Length
3.3 IP options
3.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.)
3.3.2 Fragment
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 TCP
MSL (maximum segment lifetime). (The TCP ISN (initial sequence
number) 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
network.
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.) There is no data present.
diverge.)
3.4.2 Flows
network, and then the datagrams will follow a specific host route to
the mobile host.
The port numbers are also expanded. This alleviates the problem of
going through the entire port number range with a rapid sequence of
transactions in less than the lifetime of datagrams in the network.
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.2 MBZ
4.1.3 Flags
These are the protocol state flags, use exactly as in TCPv4, except
that there is no urgent data flag.
4.1.4 Checksum
The source port number, a 32 bit identifier. See the section on port
numbers below.
4.1.7 Sequence
4.1.8 Acknowledgement
4.1.9 Window
4.1.10 Options
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
hosts must not reject connections because the "client" port is in the
registered range.
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 Null
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.
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.2 MBZ
5.1.3 Checksum
The source port number, a 32 bit identifier. See the section on TCP
port numbers above.
5.1.6 Options
6. ICMP
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 codes
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 IPv7, the nested datagram must include the IP header plus 96 bits
of the remaining datagram (thus including the port numbers within TCP
and UDP), and should include the first 256 bytes of the datagram.
I.e., in most cases where the original datagram was not large, it
will return the entire datagram.
Note: implementations are not expected to, and should not, check the
validity of incoming datagrams just to accomplish this; it simply
means that an error detected during conversion that is known to be an
actual error in the incoming datagram should be reported as such, not
as a conversion failure.
Note that the conversion failed ICMP message may be sent in either
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 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 Unknown/unspecified error
1 Don't Convert option present
2 Unknown mandatory option present
3 Known unsupported option present
4 Unsupported transport protocol
5 Overall length exceeded
6 IP header length exceeded
7 Transport protocol > 255
8 Port conversion out of range
9 Transport header length exceeded
10 32 Bit Rollover missing and ACK set
11 Unknown mandatory transport option present
7.1 A records
For example:
DELTA.Process.COM. A 192.42.95.68
A 192.0.0.192.42.95.1.68
The inverse (PTR) zone is .#, with the IPv7 address (reversed).
I.e., just like .IN-ADDR.ARPA, but with .# instead.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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), for
consistancy. The type code is 147.
If the fragments take different paths through the net, and arrive at
different conversion points, the datagram is lost.
This may also be a useful interim step for vendors not prepared to do
a major rework of an implementation; but it is important not to get
stalled in this step.
o Verify checksum.
o Verify version is 4.
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.
o Verify checksum.
o Verify version is 7
o Copy flags.
ICMP messages are converted by copying the type and code into the new
packet, and copying the other type-specific fields directly.
9. Postscript
10. References
[RFC1287] Clark, D., Chapin, L., Cerf, V., Braden, R., and
R. Hobby, "Towards the Future Internet Architecture", RFC
1287, MIT, BBN, CNRI, ISI, UCDavis, December 1991.
[RFC1347] Callon, R., "TCP and UDP with Bigger Addresses (TUBA),
A Simple Proposal for Internet Addressing and Routing",
RFC 1347, DEC, June 1992.
Robert Ullmann
Process Software Corporation
959 Concord Street
Framingham, MA 01701
USA