Internet Draft R. L. Ullmann Process Software Corporation December 4, 1992 TCP/IP: Internet Version 7 1 Status of this Memo This memo describes a proposal for the next version of the Internet protocols. The protocol is described is for information only, this does not represent a protocol on the formal internet standards track at this writing. 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 June 4, 1993. Ullmann DRAFT: expires June 4, 1993 [page 1] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 2 Contents 1 Status of this Memo . . . . . . . . . . . . . . . . 1 2 Contents . . . . . . . . . . . . . . . . . . . . . . 2 3 Introduction . . . . . . . . . . . . . . . . . . . . 4 3.1 Objectives . . . . . . . . . . . . . . . . . . . . 4 3.2 Philosophy . . . . . . . . . . . . . . . . . . . . 5 4 Internet numbers . . . . . . . . . . . . . . . . . . 6 4.1 Is 64 Bits Enough? . . . . . . . . . . . . . . . . 6 4.2 The version 7 IP address . . . . . . . . . . . . . 7 4.3 AD numbers . . . . . . . . . . . . . . . . . . . . 7 4.4 Mapping of version 4 numbers . . . . . . . . . . . 8 5 IP: Internet datagram protocol . . . . . . . . . . . 8 5.1 IP datagram header format . . . . . . . . . . . . 9 5.1.1 Version . . . . . . . . . . . . . . . . . . . . 9 5.1.2 Header length . . . . . . . . . . . . . . . . . 9 5.1.3 Time to live . . . . . . . . . . . . . . . . . 10 5.1.4 Total datagram length . . . . . . . . . . . . 10 5.1.5 Destination . . . . . . . . . . . . . . . . . 10 5.1.6 Source . . . . . . . . . . . . . . . . . . . . 10 5.1.7 Protocol . . . . . . . . . . . . . . . . . . . 10 5.1.8 Checksum . . . . . . . . . . . . . . . . . . . 10 5.1.9 Options . . . . . . . . . . . . . . . . . . . 10 5.2 Option Format . . . . . . . . . . . . . . . . . 10 5.2.1 Class (C) . . . . . . . . . . . . . . . . . . 11 5.2.2 Copy on fragmentation (F) . . . . . . . . . . 11 5.2.3 Type . . . . . . . . . . . . . . . . . . . . . 11 5.2.4 Length . . . . . . . . . . . . . . . . . . . . 11 5.2.5 Option data . . . . . . . . . . . . . . . . . 12 5.3 IP options . . . . . . . . . . . . . . . . . . . 12 5.3.1 Null . . . . . . . . . . . . . . . . . . . . . 12 5.3.2 Fragment . . . . . . . . . . . . . . . . . . . 12 5.3.3 Last Fragment . . . . . . . . . . . . . . . . 13 5.3.4 Don't Fragment . . . . . . . . . . . . . . . . 13 5.3.5 Don't Convert . . . . . . . . . . . . . . . . 13 6 TCP: Transport protocol . . . . . . . . . . . . . 14 6.1 TCP segment header format . . . . . . . . . . . 14 6.1.1 Data offset . . . . . . . . . . . . . . . . . 14 6.1.2 MBZ . . . . . . . . . . . . . . . . . . . . . 14 6.1.3 Flags . . . . . . . . . . . . . . . . . . . . 14 6.1.4 Checksum . . . . . . . . . . . . . . . . . . . 15 6.1.5 Source port . . . . . . . . . . . . . . . . . 15 6.1.6 Destination port. . . . . . . . . . . . . . . 15 6.1.7 Sequence . . . . . . . . . . . . . . . . . . . 15 6.1.8 Acknowledgement . . . . . . . . . . . . . . . 15 6.1.9 Window . . . . . . . . . . . . . . . . . . . . 15 6.1.10 Options . . . . . . . . . . . . . . . . . . . 15 6.2 Port numbers . . . . . . . . . . . . . . . . . . 15 6.3 TCP options . . . . . . . . . . . . . . . . . . 16 6.3.1 Null . . . . . . . . . . . . . . . . . . . . . 16 6.3.2 Maximum Segment Size . . . . . . . . . . . . . 16 6.3.3 Urgent Pointer . . . . . . . . . . . . . . . . 16 6.3.4 32 Bit rollover . . . . . . . . . . . . . . . 16 7 UDP: User Datagram protocol . . . . . . . . . . . 16 7.1 UDP header format . . . . . . . . . . . . . . . 16 Ullmann DRAFT: expires June 4, 1993 [page 2] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 7.1.1 Data offset . . . . . . . . . . . . . . . . . 17 7.1.2 MBZ . . . . . . . . . . . . . . . . . . . . . 17 7.1.3 Checksum . . . . . . . . . . . . . . . . . . . 17 7.1.4 Source port . . . . . . . . . . . . . . . . . 17 7.1.5 Destination port. . . . . . . . . . . . . . . 17 7.1.6 Options . . . . . . . . . . . . . . . . . . . 17 8 ICMP . . . . . . . . . . . . . . . . . . . . . . . 17 8.1 ICMP header format . . . . . . . . . . . . . . . 17 8.2 Conversion failed ICMP message . . . . . . . . . 18 9 Notes on the domain system . . . . . . . . . . . . 19 9.1 A records . . . . . . . . . . . . . . . . . . . 19 9.2 PTR zone . . . . . . . . . . . . . . . . . . . . 20 10 Conversion between version 4 and version 7 . . . . 20 10.1 Version 4 IP address extension option . . . . . 20 10.1.1 Option format . . . . . . . . . . . . . . . . 20 10.2 Fragmented datagrams . . . . . . . . . . . . . . 21 10.3 Where does the conversion happen? . . . . . . . 21 10.4 Hybrid IPv4 systems . . . . . . . . . . . . . . 22 10.5 Forwarding and redirects . . . . . . . . . . . . 22 10.6 Design considerations . . . . . . . . . . . . . 22 10.7 Conversion from IPv4 to IPv7 . . . . . . . . . . 23 10.8 Conversion from IPv7 to IPv4 . . . . . . . . . . 24 10.9 Conversion from TCPv4 to TCPv7 . . . . . . . . . 25 10.10 Conversion from TCPv7 to TCPv4 . . . . . . . . . 25 10.11 ICMP conversion . . . . . . . . . . . . . . . . 26 11 Postscript . . . . . . . . . . . . . . . . . . . . 27 12 References . . . . . . . . . . . . . . . . . . . . 28 13 Author's Address . . . . . . . . . . . . . . . . . 28 Ullmann DRAFT: expires June 4, 1993 [page 3] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 3 Introduction 3.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 DRAFT: expires June 4, 1993 [page 4] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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. 3.2 Philosophy Protocols should become simpler as they evolve. Ullmann DRAFT: expires June 4, 1993 [page 5] Internet Draft TCP/IP: Internet Version 7 December 4, 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 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; while at the top of the hierarchy, there is a need to assign administrative domains. o 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. 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. Ullmann DRAFT: expires June 4, 1993 [page 6] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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). 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 a 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. 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". 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. Ullmann DRAFT: expires June 4, 1993 [page 7] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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. 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.) 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. 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. Ullmann DRAFT: expires June 4, 1993 [page 8] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 Digression: In IPv4, options are often "considered harmful"; it is the considered opinion 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. 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. Ullmann DRAFT: expires June 4, 1993 [page 9] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 5.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 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. 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 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ullmann DRAFT: expires June 4, 1993 [page 10] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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 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.) 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. Ullmann DRAFT: expires June 4, 1993 [page 11] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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.) 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.) Ullmann DRAFT: expires June 4, 1993 [page 12] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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. 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. 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. Ullmann DRAFT: expires June 4, 1993 [page 13] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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. 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. 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 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Ullmann DRAFT: expires June 4, 1993 [page 14] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 6.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, and the protocol field (constant 6 for TCP). This is the same as the last five 32 bit words in the IP header, with the IP checksum field zeroed. 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. 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 Ullmann DRAFT: expires June 4, 1993 [page 15] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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 last octet of urgent data. (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. 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 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ullmann DRAFT: expires June 4, 1993 [page 16] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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. The pseudo-header used in the checksum consists of the destination address, the source, address, and the protocol field (constant 17 for UDP). This is the same as the last five 32 bit words in the IP header, with the IP checksum field zeroed. 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. 8 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. 8.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 ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ullmann DRAFT: expires June 4, 1993 [page 17] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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, 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. 8.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. 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 (.tba). 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 Ullmann DRAFT: expires June 4, 1993 [page 18] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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 include 236 bytes after the IP header. 9 Notes on the domain system 9.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 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 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 PD nameserver is a secondary for a zone containing IPv7 addresses, it will erroneously issue RRs with only the first four bytes. (I.e. 126.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. Ullmann DRAFT: expires June 4, 1993 [page 19] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 9.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.) 10 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 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. 10.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. 10.1.1 Option format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type (tba) | length = 10 | source IPv7 AD number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | src 7th octet | destination IPv7 AD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | number ... | dst 7th octet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ullmann DRAFT: expires June 4, 1993 [page 20] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 The source and destination are in IPv4 order (source first), for consistancy. The type code is tba, to be assigned. 10.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; 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. (It is theoretically possible to convert the fragments independently, as long as the first fragment contains the entire transport header. But it is almost certainly not worthwhile.) 10.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 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. Ullmann DRAFT: expires June 4, 1993 [page 21] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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 (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. 10.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. 10.5 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. 10.6 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. Ullmann DRAFT: expires June 4, 1993 [page 22] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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. 10.7 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 Multiply TTL by 16, extend to 16 bits. o 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.) 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 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. Ullmann DRAFT: expires June 4, 1993 [page 23] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 o Calculate IPv7 checksum. 10.8 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) 65555, fail. (That number is not a typographical error. Note that the IPv7+TCPv7 headers add up to 20 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). 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 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. Ullmann DRAFT: expires June 4, 1993 [page 24] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 o Convert session/transport layer (e.g. TCP). o Compute new overall datagram length. If greater than 65535, fail. o Compute IPv4 checksum. 10.9 Conversion from TCPv4 to TCPv7 o Verify v4 checksum. 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. o Compute new checksum. o return to IP layer conversion. 10.10 Conversion from TCPv7 to TCPv4 o Verify 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. Ullmann DRAFT: expires June 4, 1993 [page 25] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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 Compute v4 checksum. o Return to IP layer conversion. 10.11 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. Ullmann DRAFT: expires June 4, 1993 [page 26] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 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. 11 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. 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. Ullmann DRAFT: expires June 4, 1993 [page 27] Internet Draft TCP/IP: Internet Version 7 December 4, 1992 12 References [RFC768] Jon Postel. User Datagram protocol. August, 1980 [RFC791] Jon Postel, editor. Internet Protocol. DARPA Internet Program Protocol Specification. ISI/USC. September, 1981. [RFC792] Jon Postel, editor. Internet Control Message Protocol. DARPA Internet Program Protocol Specification. ISI/USC. September, 1981. [RFC793] Jon Postel, editor. Transmission Control Protocol. DARPA Internet Program Protocol Specification. ISI/USC. September, 1981. [RFC801] Jon Postel, NCP/TCP transition plan. November, 1981. [RFC1287] D. Clark, L. Chapin, V. Cerf, R. Braden, R. Hobby. Towards the Future Internet Architecture. December, 1991. [RFC1323] V. Jacobson, R. T. Braden, D. A. Borman. TCP extensions for high performance. May, 1992. [RFC1335] Z. Wang, J. Crowcroft, Two-tier address structure for the Internet: A solution to the problem of address space exhaustion. May, 1992. [RFC1338] V. Fuller, T. Li, J. Yu, K. Varadhan. Supernetting: an Address Assignment and Aggregation Strategy. June, 1992. [RFC1347] R. W. Callon. TCP and UDP with Bigger Addresses (TUBA), A simple proposal for Internet addressing and routing. June, 1992. 13 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 June 4, 1993. Ullmann DRAFT: expires June 4, 1993 [page 28]