From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1475.txt | 1963 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1963 insertions(+) create mode 100644 doc/rfc/rfc1475.txt (limited to 'doc/rfc/rfc1475.txt') 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 -- cgit v1.2.3