summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1475.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1475.txt')
-rw-r--r--doc/rfc/rfc1475.txt1963
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc1475.txt b/doc/rfc/rfc1475.txt
new file mode 100644
index 0000000..81374c6
--- /dev/null
+++ b/doc/rfc/rfc1475.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Network Working Group R. Ullmann
+Request for Comments: 1475 Process Software Corporation
+ June 1993
+
+
+ TP/IX: The Next Internet
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard. Discussion and
+ suggestions for improvement are requested. Please refer to the
+ current edition of the "IAB Official Protocol Standards" for the
+ standardization state and status of this protocol. Distribution of
+ this memo is unlimited.
+
+Abstract
+
+ The first version of this memo, describing a possible next generation
+ of Internet protocols, was written by the present author in the
+ summer and fall of 1989, and circulated informally, including to the
+ IESG, in December 1989. A further informal note on the addressing,
+ called "Toasternet Part II", was circulated on the IETF mail list
+ during March of 1992.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . 3
+ 1.1 Objectives . . . . . . . . . . . . . . . . . . . . 5
+ 1.2 Philosophy . . . . . . . . . . . . . . . . . . . . 6
+ 2. Internet numbers . . . . . . . . . . . . . . . . . . 6
+ 2.1 Is 64 Bits Enough? . . . . . . . . . . . . . . . . 6
+ 2.2 Why version 7? . . . . . . . . . . . . . . . . . . 7
+ 2.3 The version 7 IP address . . . . . . . . . . . . . 7
+ 2.4 AD numbers . . . . . . . . . . . . . . . . . . . . 8
+ 2.5 Mapping of version 4 numbers . . . . . . . . . . . 8
+ 3. IP: Internet datagram protocol . . . . . . . . . . . 9
+ 3.1 IP datagram header format . . . . . . . . . . . . 10
+ 3.1.1 Version . . . . . . . . . . . . . . . . . . . . 10
+ 3.1.2 Header length . . . . . . . . . . . . . . . . . 10
+ 3.1.3 Time to live . . . . . . . . . . . . . . . . . 10
+ 3.1.4 Total datagram length . . . . . . . . . . . . . 11
+ 3.1.5 Forward route identifier . . . . . . . . . . . 11
+ 3.1.6 Destination . . . . . . . . . . . . . . . . . . 11
+ 3.1.7 Source . . . . . . . . . . . . . . . . . . . . 11
+ 3.1.8 Protocol . . . . . . . . . . . . . . . . . . . 11
+ 3.1.9 Checksum . . . . . . . . . . . . . . . . . . . 11
+ 3.1.10 Options . . . . . . . . . . . . . . . . . . . . 11
+
+
+
+Ullmann [Page 1]
+
+RFC 1475 TP/IX June 1993
+
+
+ 3.2 Option Format . . . . . . . . . . . . . . . . . . 12
+ 3.2.1 Class (C) . . . . . . . . . . . . . . . . . . . 12
+ 3.2.2 Copy on fragmentation (F) . . . . . . . . . . . 13
+ 3.2.3 Type . . . . . . . . . . . . . . . . . . . . . 13
+ 3.2.4 Length . . . . . . . . . . . . . . . . . . . . 13
+ 3.2.5 Option data . . . . . . . . . . . . . . . . . . 13
+ 3.3 IP options . . . . . . . . . . . . . . . . . . . 13
+ 3.3.1 Null . . . . . . . . . . . . . . . . . . . . . 13
+ 3.3.2 Fragment . . . . . . . . . . . . . . . . . . . 14
+ 3.3.3 Last Fragment . . . . . . . . . . . . . . . . . 14
+ 3.3.4 Don't Fragment . . . . . . . . . . . . . . . . 15
+ 3.3.5 Don't Convert . . . . . . . . . . . . . . . . . 15
+ 3.4 Forward route identifier . . . . . . . . . . . . 15
+ 3.4.1 Procedure description . . . . . . . . . . . . . 15
+ 3.4.2 Flows . . . . . . . . . . . . . . . . . . . . . 17
+ 3.4.3 Mobile hosts . . . . . . . . . . . . . . . . . 17
+ 4. TCP: Transport protocol . . . . . . . . . . . . . 18
+ 4.1 TCP segment header format . . . . . . . . . . . . 18
+ 4.1.1 Data offset . . . . . . . . . . . . . . . . . . 19
+ 4.1.2 MBZ . . . . . . . . . . . . . . . . . . . . . . 19
+ 4.1.3 Flags . . . . . . . . . . . . . . . . . . . . . 19
+ 4.1.4 Checksum . . . . . . . . . . . . . . . . . . . 19
+ 4.1.5 Source port . . . . . . . . . . . . . . . . . . 20
+ 4.1.6 Destination port . . . . . . . . . . . . . . . 20
+ 4.1.7 Sequence . . . . . . . . . . . . . . . . . . . 20
+ 4.1.8 Acknowledgement . . . . . . . . . . . . . . . . 20
+ 4.1.9 Window . . . . . . . . . . . . . . . . . . . . 20
+ 4.1.10 Options . . . . . . . . . . . . . . . . . . . . 20
+ 4.2 Port numbers . . . . . . . . . . . . . . . . . . 20
+ 4.3 TCP options . . . . . . . . . . . . . . . . . . . 21
+ 4.3.1 Option Format . . . . . . . . . . . . . . . . . 21
+ 4.3.2 Null . . . . . . . . . . . . . . . . . . . . . 21
+ 4.3.3 Maximum Segment Size . . . . . . . . . . . . . 21
+ 4.3.4 Urgent Pointer . . . . . . . . . . . . . . . . 21
+ 4.3.5 32 Bit rollover . . . . . . . . . . . . . . . . 21
+ 5. UDP: User Datagram protocol . . . . . . . . . . . 22
+ 5.1 UDP header format . . . . . . . . . . . . . . . . 22
+ 5.1.1 Data offset . . . . . . . . . . . . . . . . . . 22
+ 5.1.2 MBZ . . . . . . . . . . . . . . . . . . . . . . 22
+ 5.1.3 Checksum . . . . . . . . . . . . . . . . . . . 22
+ 5.1.4 Source port . . . . . . . . . . . . . . . . . . 22
+ 5.1.5 Destination port . . . . . . . . . . . . . . . 22
+ 5.1.6 Options . . . . . . . . . . . . . . . . . . . . 23
+ 6. ICMP . . . . . . . . . . . . . . . . . . . . . . . 23
+ 6.1 ICMP header format . . . . . . . . . . . . . . . 23
+ 6.2 Conversion failed ICMP message . . . . . . . . . 23
+ 7. Notes on the domain system . . . . . . . . . . . . 25
+ 7.1 A records . . . . . . . . . . . . . . . . . . . . 25
+
+
+
+Ullmann [Page 2]
+
+RFC 1475 TP/IX June 1993
+
+
+ 7.2 PTR zone . . . . . . . . . . . . . . . . . . . . 25
+ 8. Conversion between version 4 and version 7 . . . . 25
+ 8.1 Version 4 IP address extension option . . . . . . 26
+ 8.1.1 Option format . . . . . . . . . . . . . . . . . . 26
+ 8.2 Fragmented datagrams . . . . . . . . . . . . . . . 26
+ 8.3 Where does the conversion happen? . . . . . . . . 27
+ 8.4 Hybrid IPv4 systems . . . . . . . . . . . . . . . 28
+ 8.5 Maximum segment size in TCP . . . . . . . . . . . 28
+ 8.6 Forwarding and redirects . . . . . . . . . . . . . 28
+ 8.7 Design considerations . . . . . . . . . . . . . . 28
+ 8.8 Conversion from IPv4 to IPv7 . . . . . . . . . . . 29
+ 8.9 Conversion from IPv7 to IPv4 . . . . . . . . . . . 30
+ 8.10 Conversion from TCPv4 to TCPv7 . . . . . . . . . . 31
+ 8.11 Conversion from TCPv7 to TCPv4 . . . . . . . . . . 32
+ 8.12 ICMP conversion . . . . . . . . . . . . . . . . . 33
+ 9. Postscript . . . . . . . . . . . . . . . . . . . . 33
+ 10. References . . . . . . . . . . . . . . . . . . . . 34
+ 11. Security Considerations . . . . . . . . . . . . . 35
+ 12. Author's Address . . . . . . . . . . . . . . . . . 35
+
+1. Introduction
+
+ This memo presents the specification for version 7 of the Internet
+ Protocol, as well as version 7 of the TCP and the user datagram
+ protocol. Version 7 has been designed to address several major
+ problems that have arisen as version 4 has evolved and been deployed,
+ and to make a major step forward in the datagram switching and
+ forwarding architecture of the Internet.
+
+ The major problems are threefold. First, the address space of
+ version 4 is now seen to be too small. While it was viewed as being
+ almost impossibly large when version 4 was designed, two things have
+ occurred to create a problem. The first is a success crisis: the
+ internet protocols have been more widely used and accepted than their
+ designers anticipated. Also, technology has moved forward, putting
+ microprocessors into devices not anticipated except as future dreams
+ a decade ago.
+
+ The second major problem is a perceived routing explosion. The
+ present routing architecture of the internet calls for routing each
+ organization's network independently. It is becoming increasingly
+ clear that this does not scale to a universal internet. While it is
+ possible to route several billion networks in a flat, structureless
+ domain, it is not desireable.
+
+ There is also the political administrative issue of assigning network
+ numbers to organizations. The version 4 administrative system calls
+ for organizations to request network assignments from a single
+
+
+
+Ullmann [Page 3]
+
+RFC 1475 TP/IX June 1993
+
+
+ authority. While to some extent this has been alleviated by
+ reserving blocks to delegated assignments, the address space is not
+ large enough to do this in the necessary general case, with large
+ blocks allocated to (e.g.) national authority.
+
+ The third problem is the increasing bandwidth of the networks and of
+ the applications possible on the network. The TCP, while having
+ proven useful on an unprecedented range of network speeds, is now the
+ limiting factor at the highest speeds, due to restrictions of window
+ size, sequence-space, and port numbers. These limitations can all be
+ addressed by increasing the sizes of the relevant fields. See
+ [RFC1323].
+
+ There is also an opportunity to move the technology forward, and take
+ advantage of a combination of the best features of the hop-by-hop
+ connectionless forwarding of version 4 (and CLNP) as well as the
+ pre-established paths of version 5 (and, e.g., the OSI CONS).
+
+ Internet Version 7 includes four major areas of improvement, while at
+ the same time retaining interoperation with version 4 with a small
+ amount of conversion knowledge imposed on version 7 hosts and
+ routers.
+
+ o It increases the address fields to 64 bits, with sufficient
+ space for visible future expansion of the internet.
+
+ o It adds a numbering layer for administrations, above the
+ organization or network layer, as well as providing more
+ space for subnetting within organizations.
+
+ o It increases the range of speeds and network path delays over
+ which the TCP will operate satisfactorily, as well as the
+ number of transactions in bounded time that can be served by
+ a host.
+
+ o Finally, it provides a forward route identifier in each
+ datagram, to support extremely fast path, circuit, or
+ flow-based forwarding, or any desired combination, while
+ preserving hop-by-hop connectivity.
+
+ The result is not just a movement sideways, deploying a new network
+ layer protocol to patch current problems. It is a significant step
+ forward for network layer technology,
+
+
+
+
+
+
+
+
+Ullmann [Page 4]
+
+RFC 1475 TP/IX June 1993
+
+
+1.1 Objectives
+
+ The following are some of the objectives of the design.
+
+ o Use what has been learned from the IP version 4 protocol, fixing
+ things that are troublesome, and not fixing that which is not
+ broken.
+
+ o Retain the essential "look and feel" of the Internet protocol
+ suite. It has been very successful, and one doesn't argue with
+ success.
+
+ o Not introduce concepts that the Internet has shown do not belong
+ in the protocol definition. Best example: we do not want to add
+ any kind of routing information into the addressing, other than
+ the administrative hierarchy that has sometimes proved useful.
+ Note that the one feature in version 4 addressing (the class
+ system) designed to aid routing is now the most serious single
+ problem.
+
+ o Allow current hosts to interoperate, if not universally, at least
+ within an organization or larger area for the indefinite future.
+ There will be version 4 hosts for 10-15 years into the future,
+ the Internet must remain on good terms with them.
+
+ o Likewise, we must not impose the new version, telling sites they
+ must convert to stay connected. People resist imposed solutions.
+ It must not be marketed as something different from IPv4; the
+ differences must be down-played at every opportunity.
+
+ o The design must allow individual hosts and routers to be upgraded
+ effectively at random, with no transition plan constraints.
+
+ o The design must not require renumbering the Internet. The
+ administrative work already accomplished is immense, if it is to
+ be done again it will be in assigning NSAPs.
+
+ o It must allow IPv4 hosts to interoperate without any reduction in
+ function, without any modification to their software or
+ configuration. (Universal connectivity will be lost by IPv4
+ hosts, but they must be able to continue operating within their
+ organization at least.)
+
+ o It must permit network layer state-free translation of datagrams
+ between IPv4 and IPv7; this is important to the previous point,
+ and essential to early testing and transitional deployment.
+
+ o It must be a competent alternative to CLNP.
+
+
+
+Ullmann [Page 5]
+
+RFC 1475 TP/IX June 1993
+
+
+ o It must not involve changing the semantics of the network layer
+ service in any way that invalidates the huge amount of work that
+ has gone into understanding how TCP (for example) functions in
+ the net, and the implementation of that understanding.
+
+ o It must be defined Real Soon; the window of opportunity is almost
+ closed. It will take vendors 3 years to deploy from the time the
+ standard is rock-solid concrete.
+
+ I believe all of these are accomplishable in a consistent, well-
+ engineered solution, and all are essential to the survival of the
+ Internet.
+
+1.2 Philosophy
+
+ Protocols should become simpler as they evolve.
+
+2. Internet numbers
+
+ The version 4 numbering system has proven to be very flexible,
+ (mostly) expandable, and simple. In short: it works. There are two
+ problems, neither serious when this specification was first developed
+ 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 to
+ subnet. At the top of the hierarchy, there is a need to
+ assign administrative domains.
+
+ o As bit-packing is done to accomplish the desired network
+ structure, the 32 bit limit causes more and more aggravation.
+
+2.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.
+
+
+
+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 that
+ making the address 64 bits implies a new IP header format, which was
+ called either "TP/IX" or "IP version 7"; there wasn't anything magic
+ about the number 7, I made it up. Version 4 is the familiar current
+ version of IP. Version 5 is the experimental ST (Stream) protocol.
+ ST-II, a newer version of ST, uses the same version number, something
+ I was not aware of until recently; I suspected it might have been
+ allocated 6. Besides, I liked 7.
+
+ 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.
+
+2.3 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).
+
+ The AD (Administrative Domain), identifies an administration which
+ may be a service provider, a national administration, or a large
+ multi-organization (e.g. 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.) Since only 1/4th of the address space
+ is initially used (first two bits are 01), the remainder can then be
+ 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 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.
+
+
+
+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
+
+ AD numbers are allocated out of the same numbering space as network
+ numbers. This means that a version 4 address can be distinguished
+ from the first 32 bits of a version 7 address. This is useful to
+ help prevent the inadvertent use of the first half of the longer
+ 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 like
+ "ipaddr = *(int *)ptr". This usage has always been incorrect, but
+ does occur with disturbing frequency. As IPv7 8 byte addresses
+ appear in the application layers, this software will find those
+ addresses unreachable; this is preferable to interacting with a
+ random host.
+
+ One possible method would be to allocate ADs in the range 96.0.0 to
+ 192.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 192, 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. 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.)
+
+2.5 Mapping of version 4 numbers
+
+ Initially, all existing Internet numbers are defined as belonging to
+ 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 becomes
+ 192.0.0.127.0.0.1.1 (I can see explaining that in 2015 to someone
+ born in 1995.)
+
+ The present protocol multicast (192.0.0.224.x.y.1.z) and loopback
+ addresses are permanently allocated in the NSF AD.
+
+3. 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 opinion of the present author that this is because they are
+ rarely needed, and not designed to be processed rapidly on most
+ architectures. 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
+
+
+
+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.
+
+3.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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + forward route identifier +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + destination address +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ + source address +
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | protocol | checksum |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | options |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ A description of each field follows.
+
+3.1.1 Version
+
+ This document describes version 7 of the protocol.
+
+3.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.
+
+3.1.3 Time to live
+
+ The time to live is a 16 bit count, nominally in 1/16 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
+
+
+
+Ullmann [Page 10]
+
+RFC 1475 TP/IX June 1993
+
+
+ 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.)
+
+ 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.
+
+3.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.
+
+3.1.5 Forward route identifier
+
+ 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
+
+ The 64 bit IPv7 destination address.
+
+3.1.7 Source
+
+ The 64 bit IPv7 source address.
+
+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
+
+ The checksum is a 16 bit checksum of the entire IP header, using the
+ familiar algorithm used in IPv4.
+
+3.1.10 Options
+
+ Options may follow. They are variable length, and always 32 bit
+ aligned, as discussed previously.
+
+
+
+
+
+
+
+Ullmann [Page 11]
+
+RFC 1475 TP/IX June 1993
+
+
+3.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:
+
+3.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 the datagram
+ 2 discard, or forward and include this option unmodified
+ 3 discard this datagram
+
+ 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.)
+
+
+
+
+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 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
+
+ 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.
+
+3.2.4 Length
+
+ Length of the option data, in bytes.
+
+3.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.
+
+3.3 IP options
+
+ The following sections describe the options defined to emulate IPv4
+ features, or necessary in the basic structure of the protocol.
+
+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.)
+
+ 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.
+
+
+
+
+
+
+
+Ullmann [Page 13]
+
+RFC 1475 TP/IX June 1993
+
+
+3.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 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ 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. The 64 bits fields are
+ positioned so that they are aligned in the usual case of the fragment
+ option following the IP header.
+
+ A router implementing Fragment (doing fragmentation) must recognize
+ the Don't Fragment option.
+
+3.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.
+
+ 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
+
+
+
+Ullmann [Page 14]
+
+RFC 1475 TP/IX June 1993
+
+
+ network.
+
+3.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.) There is no data present.
+
+3.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. A host is under no such constraint; like
+ any protocol specification, only the "bits on the wire" can be
+ specified, the host receiving the datagram may convert it as part of
+ its procedure. There is no data present in this option.
+
+3.4 Forward route identifier
+
+ Each IP datagram carries a 64 bit field, called "forward route
+ identifier", that is updated (if the information is available) at
+ each hop. This field's value is derived from the routing protocol
+ (e.g., RAP [RFC1476]). It is used to expedite routing decisions by
+ preserving knowledge where possible between consecutive routers. It
+ can also be used to make datagrams stay within reserved flows and
+ mobile-host tunnels where required.
+
+3.4.1 Procedure description
+
+ Consider 3 routers, A, B, and C. Traffic is passing through them,
+ between two other hosts (or networks), X and Y, packets are going
+ XABCY and YCBAX. Consider only one direction: routing info flowing
+ from C to A, to provide a route from A to C. The same thing will be
+ happening in the other direction.
+
+ An explanation of the notation:
+
+ R(r,d,i,h) A route that means: "from router r, to go toward
+ final destination d, replace the forward route
+ identifier in the packet with i, and take next
+ hop h."
+
+ Ri(r,d) An opaque (outside of router r) identifier, that can
+ 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, that
+ router r can use to find a flow or tunnel with which
+ the datagram is associated, and from that the route
+ rt on which the flow or tunnel is built, as well as
+ 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 it
+ an identifier Ri(C,Y) internal to C, that will allow C to find the
+ 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 announces
+ it to A, including an identifier Ri(B,Y), internal to B, and used by
+ A as an opaque object.
+
+ Router A creates a route R(A,Y,Ri(B,Y),B) via router B. It has no
+ one to announce it to.
+
+ Now: X originates a datagram addressed to Y. It has no routing
+ information, and sets Ri(Dgram) to zero. It forwards the datagram to
+ router A (X's default gateway).
+
+ A finds no valid Ri(Dgram), and looks up the destination (Y) in its
+ 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 hop
+ route R(B,Ri(C,Y),C), sets Ri(Dgram) <- Ri(C,Y) and forwards it to
+ router C.
+
+ Router C looks at Ri(Dgram) which directly locates R(C,0,Y), sets
+ 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, particularily
+ 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 destination
+ of the datagram. If the Ri is invalid, the router must use the
+ ordinary method of finding a route (i.e., what it would have done if
+ Ri was 0), and silently ignore the invalid Ri.
+
+ When a route has been aggregated at some router, implicitly or
+ explicitly, it will find that the incoming Ri(Dgram) at most can
+ identify the aggregation, and it must make a decision; the forwarded
+ datagram then contains the Ri for the specific route. (Note this may
+ happen well upstream of the point at which the routes actually
+
+
+
+Ullmann [Page 16]
+
+RFC 1475 TP/IX June 1993
+
+
+ diverge.)
+
+ This allows all cooperating routers to make immediate forwarding
+ decisions, without any searching of tables or caches once the
+ datagram has entered the routing domain. If the host participates in
+ the routing, at least to the extent of acquiring the initial Ri
+ required from the first router, then only routers that have done
+ aggregations need make decisions. (If the routing changes with
+ datagrams in flight, some router will be required to make a decision
+ to re-rail each datagram.)
+
+3.4.2 Flows
+
+ If a "flow" is to be set up, the identifiers are replaced by
+ Flowi(router,route), where each router's structure for the flow
+ 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 inserted
+ either by the originating host or by a cooperating router near the
+ originator. Since the forward route identifier field is opaque to
+ the sending router, and implicitly meaningful only to the next hop
+ router, use for flows (or similar optimizations) need not be
+ otherwise defined by the protocol. (One presumes that a router
+ issuing both Ri's and Flowi's will take care to make sure that it can
+ distinguish them by some private method.)
+
+ If a flow has been set up by a restricted target RAP route
+ announcement, it is no different from a route in the implementation.
+ If this announcement originates from the host itself, the Ri in
+ incoming datagrams can be used to determine whether they followed the
+ flow, or to optimize delivery of the datagrams to the next layer
+ protocol.
+
+3.4.3 Mobile hosts
+
+ First, a definition: A "mobile host" is a host that can move around,
+ connecting via different networks at different times, while
+ maintaining open TCP connections. It is distinguished from a
+ "portable host", which is simply a host that can appear in various
+ places in the net, without continuity. A portable host can be
+ implemented by assigning a new address for each location (more or
+ 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 layer
+ of the protocol suite must provide network-wide routing, or the
+ datagrams must be tunnelled from the "home" network of the host to
+ its present location. In the real network, some combination of these
+ is probable: most of the net will forward datagrams toward the home
+
+
+
+Ullmann [Page 17]
+
+RFC 1475 TP/IX June 1993
+
+
+ network, and then the datagrams will follow a specific host route to
+ the mobile host.
+
+ The requirement on the routing system is that it must be able to
+ propagate a host route at least to the home network; any other
+ distribution is useful optimization. When a host route is propagated
+ 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 a
+ real tunnel, in the strict sense; the datagrams are following an
+ actual route at the network protocol layer.)
+
+ As explained in RAP [RFC14XX-RAP], a targeted route can be issued
+ when desired; in particular, it can be triggered by the establishment
+ of a TCP connection or by the arrival of datagrams that do not carry
+ an Ri indicating that they have followed a (non-tunnel) route.
+
+4. TCP: Transport protocol
+
+ Internet version 7 expands the sizes of the sequence and
+ acknowledgement fields, the window, and the port numbers. This is to
+ remove limitations in version 4 that begin to restrict throughput at
+ (for example) the bandwidth of FDDI and round trip delay of more than
+ 60 milliseconds. At gigabit speeds and delays typical of
+ international links, the version 4 TCP would be a serious limitation.
+ See [RFC1323].
+
+ 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.
+
+4.1 TCP segment header format
+
+ 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 9 32-bit word IP header. If IP options add up
+ to an odd number of 32 bit words, a null option may be added to push
+ 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 offset
+
+ An 8 bit count of the number of 32 bit words in the TCP header,
+ including any options.
+
+4.1.2 MBZ
+
+ Reserved bits, must be zero, and must be ignored.
+
+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
+
+ This is a 16 bit checksum of the segment. The pseudo-header used in
+ the checksum consists of the destination address, the source address,
+ the protocol field (constant 6 for TCP), and the 32 bit length of the
+ TCP segment.
+
+
+
+
+
+
+
+Ullmann [Page 19]
+
+RFC 1475 TP/IX June 1993
+
+
+4.1.5 Source port
+
+ The source port number, a 32 bit identifier. See the section on port
+ numbers below.
+
+4.1.6 Destination port.
+
+ The 32 bit destination port number.
+
+4.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. V7 hosts must implement the full 64 bit sequence
+ number rollover.
+
+4.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.
+
+4.1.9 Window
+
+ The 32 bit offered window.
+
+4.1.10 Options
+
+ TCP options, some of which are documented below.
+
+4.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:
+
+
+
+Ullmann [Page 20]
+
+RFC 1475 TP/IX June 1993
+
+
+ hosts must not reject connections because the "client" port is in the
+ registered range.
+
+4.3 TCP options
+
+4.3.1 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | type | length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | option data ... | padding |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.3.2 Null
+
+ The null option (type = 0), is to be ignored.
+
+4.3.3 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.
+
+4.3.4 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 last octet of urgent data. (Not
+ an offset, as in v4.)
+
+4.3.5 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 [Page 21]
+
+RFC 1475 TP/IX June 1993
+
+
+5. UDP: User Datagram protocol
+
+ The user datagram protocol is also expanded to include larger port
+ numbers, for reasons similar to the TCP.
+
+5.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:
+
+5.1.1 Data offset
+
+ An 8 bit count of the number of 32 bit words in the UDP header,
+ including any options.
+
+5.1.2 MBZ
+
+ Reserved bits, must be zero, and must be ignored.
+
+5.1.3 Checksum
+
+ This is a 16 bit checksum of the datagram. The pseudo-header used in
+ the checksum consists of the destination address, the source,
+ address, and the protocol field (constant 17 for UDP), and the 32 bit
+ length of the user datagram.
+
+5.1.4 Source port
+
+ The source port number, a 32 bit identifier. See the section on TCP
+ 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 Options
+
+ UDP options, none are presently defined.
+
+6. ICMP
+
+ The ICMP protocol is very similar to ICMPv4, in some cases not
+ requiring any conversion.
+
+ The complication is that IP datagrams are nested within ICMP
+ messages, and must be converted. This is discussed later.
+
+6.1 ICMP 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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 many types, the data consists of a nested IP datagram, usually
+ truncated, which is a copy of the datagram causing the event being
+ 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 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.
+
+6.2 Conversion failed ICMP message
+
+ The introduction of network layer conversion requires a new message
+ type, to report conversion errors. Note that an invalid datagram
+ should result in the sending of some other ICMP message (e.g.,
+ parameter problem) or the silent discarding of the datagram. This
+ 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 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 .... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The type for Conversion Failed is 31.
+
+ The codes are:
+
+ 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
+
+ The use of code 0 should be avoided, any other condition found by
+ implementors should be assigned a new code requested from IANA. When
+ code 0 is used, it is particularily important that the pointer be set
+ properly.
+
+ The pointer is an offset from the start of the original datagram to
+ the beginning of the offending field.
+
+ The data is part of the datagram that could not be converted. It
+ must be at least the IP and transport headers, and must include the
+ field pointed to by the previous parameter. For code 4, the
+ transport header is probably not identifiable; the data should
+
+
+
+Ullmann [Page 24]
+
+RFC 1475 TP/IX June 1993
+
+
+ include 256 bytes of the original datagram.
+
+7. Notes on the domain system
+
+7.1 A records
+
+ Address records will be added to the IN (Internet) zone with IPv7
+ addresses for all hosts as IPv7 is deployed. Eventually the IPv4
+ addresses will be removed. As mentioned above, the AD
+ (Administrative Domain) 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 192.0.0.192.42.95.1.68
+
+ It is important that the A record be used, to avoid the cache
+ consistancy problem that would arise when different records had
+ different remaining TTLs.
+
+ Note that if an unmodified version of the more popular public domain
+ nameserver is a secondary for a zone containing IPv7 addresses, it
+ 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 that
+ the AD numbers are initially reserved out of the IPv4 network number
+ space. Eventually, zones with IPv7 addresses would be expected to be
+ served only by upgraded servers.
+
+7.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.192.#. (Plus, of course, any other ADs assigned to it
+ over time.)
+
+8. 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 TCP and ICMP at the session/transport layer; UDP is a
+ subset of the TCP conversion. Most protocols at this layer will
+
+
+
+Ullmann [Page 25]
+
+RFC 1475 TP/IX June 1993
+
+
+ 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.
+
+8.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 network numbers are assigned, by
+ which time most of the infrastructure should be IPv7.
+
+8.1.1 Option format
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | 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.
+
+8.2 Fragmented datagrams
+
+ Datagrams that have been fragmented must be reassembled by 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 IPv4 fragments;
+
+
+
+Ullmann [Page 26]
+
+RFC 1475 TP/IX June 1993
+
+
+ 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.
+
+ If the fragments take different paths through the net, and arrive at
+ 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, both
+ hosts and routers, in whatever order desired by their owners.
+ Organizations must be able to upgrade any given system without
+ reconfiguration or modification of any other; and IPv4 hosts must be
+ able to interoperate essentially forever. (IPv4 routers will
+ probably be effectively eliminated at some point, except where they
+ exist in their own remote or isolated corners.)
+
+ Each TCP/IP v7 system, whether host or router, must be able to
+ recognize adjacent systems in the topology that are (only) v4, and
+ call the appropriate conversion routine just before sending the
+ datagram.
+
+ Digression: I believe v7 hosts will get much better performance by
+ doing everything internally in v7, and using conversion to filter
+ datagrams when necessary. This keeps the usual code path simple,
+ with only a "hook" right after receiving to convert incoming IPv4
+ datagrams, and just before sending to convert to IPv4. Routers may
+ prefer to keep datagrams in their incoming version, at least until
+ after the routing decision is made, and then doing the conversion
+ only if necessary. In either case, this is an implementation
+ specific decision.
+
+ It must be noted that any forwarding system may convert datagrams to
+ IPv7, then back to IPv4, even if that loses information such as
+ unknown options. The reverse is not acceptable: a system that
+ receives an IPv7 datagram should not convert it to IPv4, then back to
+ IPv7 on forwarding.
+
+ The preferred method for identifying which hosts require conversion
+ is to ARP first for the IPv7 address, and then again if no response
+ is received, for the IPv4 address. The reservation of ADs out of the
+ v4 network number space is useful again here, protecting hosts that
+ fail to properly use the ARP address length fields.
+
+ On networks where ARP is not normally used, the method is to assume
+ that a remote system is v7. If an IPv7 datagram is received from it,
+ the assumption is confirmed. If, after a short time, no IPv7
+ datagram is received, a v7 ICMP echo is sent. If a reply is received
+
+
+
+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 to
+ understand IPv7, and datagrams are converted to IPv4 just before
+ transmitting them.
+
+ Implementations should also provide for explicit configuration where
+ desired.
+
+8.4 Hybrid IPv4 systems
+
+ In the course of implementing IPv7, especially in constrained
+ environments such as small terminal servers, it may be useful to
+ implement the IPv4 address extension option directly, thereby
+ regaining universal connectivity.
+
+ 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.
+
+ A hybrid IPv4 + address extension system does not have to implement
+ the conversion, it places this onus on its neighbors. It may itself
+ 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 assume
+ that a host with a IPv7 address is a native IPv7 implementation.
+
+8.5 Maximum segment size in TCP
+
+ It is probably advisable for IPv4 implementations to reduce the MSS
+ offered by a small amount where possible, to avoid fragmentation when
+ datagrams are converted to IPv7. This arises when IPv4 hosts are
+ communicating through an IPv7 infrastructure, with the same MTU as
+ the local networks of the hosts.
+
+8.6 Forwarding and redirects
+
+ It may be important for a router to not send ICMP redirects when it
+ finds that it must do a conversion as part of forwarding the
+ datagram. In this case, the hosts involved may not be able to
+ interact directly. The IPv7 host could ignore the redirect, but this
+ results in an unpleasant level of noise as the sequence continually
+ recurs.
+
+8.7 Design considerations
+
+ The conversion is designed to be fairly efficient in implementation,
+ especially on RISC architectures, assuming they can either do a
+
+
+
+Ullmann [Page 28]
+
+RFC 1475 TP/IX June 1993
+
+
+ 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.
+
+ For CISC machines, the same considerations will lead to fairly
+ efficient code.
+
+ The conversion code must be extremely careful to be robust when
+ presented with invalid input; in particular, it may be presented with
+ truncated transport layer headers when called recursively from the
+ ICMP conversion.
+
+8.8 Conversion from IPv4 to IPv7
+
+ Individual steps in the conversion; the order is in most cases not
+ 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), 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.)
+
+ 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 subnet
+ extension numbers into destination and source.
+
+ o Convert other options where possible. If an unknown option
+
+
+
+Ullmann [Page 29]
+
+RFC 1475 TP/IX June 1993
+
+
+ with copy-on-fragment is found, fail. If copy-on-fragment is
+ not set, ignore the option. I.e., the flag is (ab)used as an
+ 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 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.
+
+ 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 number
+ is not a typographical error. Note that the IPv7+TCPv7
+ headers add up to 28 bytes more than the corresponding v4
+ headers in the usual case.) This check is only to avoid
+ 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 to
+ destination address.
+
+ o Same for source address.
+
+ o Generate v4 address extension option. (If enabled; this
+
+
+
+Ullmann [Page 30]
+
+RFC 1475 TP/IX June 1993
+
+
+ probably should be a configuration option, should default to
+ 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 TCPv7
+
+ o Subtract header words from v4 checksum. (Note that this is
+ 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 will
+ suffice on most architectures), copy it. If equal or
+ 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; we
+ 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 to
+ recompute the checksum over the data; it must remain an
+ end-to-end checksum.
+
+ o Return to IP layer conversion.
+
+8.11 Conversion from TCPv7 to TCPv4
+
+ o Subtract header from v7 checksum.
+
+ o 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.)
+
+ 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 has
+ been found to be a good default for IPv4 hosts. If the IPv7
+ host is offering a very large window, the IPv4 host probably
+ isn't prepared to play at that level.)
+
+ o Process options. If 32 Bit Rollover is not present, and A
+ flag is set, fail. (Send ICMP conversion failed/32 bit
+ Rollover missing.)
+
+ o If Urgent is present, compute offset. If in segment, set U
+ 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 conversion
+
+ ICMP messages are converted by copying the type and code into the new
+ packet, and copying the other type-specific fields directly.
+
+ If the message contains an encapsulated, and usually truncated, IP
+ datagram, the conversion routine is called recursively to translate
+ it as far as possible. There are some special considerations:
+
+ o The encapsulated datagram is less likely to be valid, given
+ that it did generate an error of some kind.
+
+ o The conversion should attempt to complete all fields
+ available, even if some would cause failures in the general
+ case. Note, in particular, that in the course of converting
+ a datagram, when a failure occurs, an ICMP message
+ (conversion failed) is sent; this message itself may
+ immediately require conversion. Part of that conversion will
+ involve converting the original datagram.
+
+ o Conditions such as overall datagram length too large are not
+ checked.
+
+ o The AD and subnet byte assumed in the nested conversion may
+ not be sensible if the IPv4 address extension option is not
+ present and the datagram has strayed from the expected AD.
+ (Not unlikely, given that we know a priori that some error
+ occured.)
+
+ o The conversion must be very sure not to make another
+ 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 transport
+ layer checksum in the nested datagram. The conversion may
+ prefer to just zero the checksum field. Likewise, validating
+ the original checksum is pointless.
+
+ It may be best in a given implementation to have a separate code path
+ for the nested conversion, that handles these issues out of the
+ optimized usual path.
+
+9. Postscript
+
+ The present version of TCP/IP has been a success partly by accident,
+ for reasons that weren't really designed in. Perhaps the most
+ significant is the low level of network integration required to make
+ it work.
+
+
+
+Ullmann [Page 33]
+
+RFC 1475 TP/IX June 1993
+
+
+ We must be careful to retain the successful ingredients, even where
+ we may be unaware of them. Tread lightly, and use all that we have
+ learned, especially about not changing things that work.
+
+ This document has described a fairly conservative step forward, with
+ clear extensibility for future developments, but without jumping into
+ the abyss.
+
+10. References
+
+ [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+ USC/Information Sciences Institute, August 1980.
+
+ [RFC791] Postel, J., "Internet Protocol - DARPA Internet Program
+ Protocol Specification", STD 5, RFC 791, DARPA,
+ September 1981.
+
+ [RFC792] Postel, J., "Internet Control Message Protocol -
+ DARPA Internet Program Protocol Specification"
+ STD 5, RFC 792, USC/Information Sciences Institute,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol - DARPA
+ Internet Program Protocol Specification", STD 7, RFC 793,
+ USC/Information Sciences Institute, September 1981.
+
+ [RFC801] Postel, J., "NCP/TCP Transition Plan", USC/Information
+ Sciences Institute, November 1981.
+
+ [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.
+
+ [RFC1323] Jacobson, V., Braden, R, and D. Borman, "TCP Extensions
+ for High Performance", RFC 1323, LBL, USC/Information
+ Sciences Institute, Cray Research, May 1992.
+
+ [RFC1335] Wang, Z., and J. Crowcroft, A Two-Tier Address Structure
+ for the Internet: A Solution to the Problem of Address
+ Space Exhaustion", RFC 1335, University College London,
+ May 1992.
+
+ [RFC1338] Fuller, V., Li, T., Yu, J., and K. Varadhan,
+ "Supernetting: an Address Assignment and Aggregation
+ Strategy", RFC 1338, BARRNet, cicso, Merit, OARnet,
+ June 1992.
+
+
+
+
+
+Ullmann [Page 34]
+
+RFC 1475 TP/IX June 1993
+
+
+ [RFC1347] Callon, R., "TCP and UDP with Bigger Addresses (TUBA),
+ A Simple Proposal for Internet Addressing and Routing",
+ RFC 1347, DEC, June 1992.
+
+ [RFC1476] Ullmann, R., "RAP: Internet Route Access Protocol",
+ RFC 1476, Process Software Corporation, June 1993.
+
+ [RFC1379] Braden, R., "Extending TCP for Transactions -- Concepts",
+ RFC 1379, USC/Information Sciences Institute,
+ November 1992.
+
+11. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ullmann [Page 35]
+ \ No newline at end of file