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