RFC 1475
TP/IX: The Next Internet
TP/IX: The Next Internet 🦋
Okay bestie, this is RFC 1475 🎀, and it's giving "Network Working Group" energy. It was written by R. Ullmann of Process Software Corporation and dated June 1993. It's an Experimental protocol doc, not an Internet standard. It doesn't list anything it obsoletes or updates, so it's not replacing or patching any other RFC 💅.
Status of This Memo ✨
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard. Discussion and suggestions for improvement are requested 🫶. For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 📚. Distribution of this memo is unlimited 🌈.
Abstract 🌸
The first version of this memo, which described a possible next generation of Internet protocols, was written by the present author in the summer and fall of 1989. It was circulated informally in December 1989, including to the IESG 🧚. A further informal note on the addressing, called "Toasternet Part II", was circulated on the IETF mail list in March of 1992 💜.
Table of Contents 📖
1. Introduction . . . . . . . . . . . . . . . . . . . . 3
1.1 Objectives . . . . . . . . . . . . . . . . . . . . 5
1.2 Philosophy . . . . . . . . . . . . . . . . . . . . 6
2. Internet numbers . . . . . . . . . . . . . . . . . . 6
2.1 Is 64 Bits Enough? . . . . . . . . . . . . . . . . 6
2.2 Why version 7? . . . . . . . . . . . . . . . . . . 7
2.3 The version 7 IP address . . . . . . . . . . . . . 7
2.4 AD numbers . . . . . . . . . . . . . . . . . . . . 8
2.5 Mapping of version 4 numbers . . . . . . . . . . . 8
3. IP: Internet datagram protocol . . . . . . . . . . . 9
3.1 IP datagram header format . . . . . . . . . . . . 10
3.1.1 Version . . . . . . . . . . . . . . . . . . . . 10
3.1.2 Header length . . . . . . . . . . . . . . . . . 10
3.1.3 Time to live . . . . . . . . . . . . . . . . . 10
3.1.4 Total datagram length . . . . . . . . . . . . . 11
3.1.5 Forward route identifier . . . . . . . . . . . 11
3.1.6 Destination . . . . . . . . . . . . . . . . . . 11
3.1.7 Source . . . . . . . . . . . . . . . . . . . . 11
3.1.8 Protocol . . . . . . . . . . . . . . . . . . . 11
3.1.9 Checksum . . . . . . . . . . . . . . . . . . . 11
3.1.10 Options . . . . . . . . . . . . . . . . . . . . 11
3.2 Option Format . . . . . . . . . . . . . . . . . . 12
3.2.1 Class (C) . . . . . . . . . . . . . . . . . . . 12
3.2.2 Copy on fragmentation (F) . . . . . . . . . . . 13
3.2.3 Type . . . . . . . . . . . . . . . . . . . . . 13
3.2.4 Length . . . . . . . . . . . . . . . . . . . . 13
3.2.5 Option data . . . . . . . . . . . . . . . . . . 13
3.3 IP options . . . . . . . . . . . . . . . . . . . 13
3.3.1 Null . . . . . . . . . . . . . . . . . . . . . 13
3.3.2 Fragment . . . . . . . . . . . . . . . . . . . 14
3.3.3 Last Fragment . . . . . . . . . . . . . . . . . 14
3.3.4 Don't Fragment . . . . . . . . . . . . . . . . 15
3.3.5 Don't Convert . . . . . . . . . . . . . . . . . 15
3.4 Forward route identifier . . . . . . . . . . . . 15
3.4.1 Procedure description . . . . . . . . . . . . . 15
3.4.2 Flows . . . . . . . . . . . . . . . . . . . . . 17
3.4.3 Mobile hosts . . . . . . . . . . . . . . . . . 17
4. TCP: Transport protocol . . . . . . . . . . . . . 18
4.1 TCP segment header format . . . . . . . . . . . . 18
4.1.1 Data offset . . . . . . . . . . . . . . . . . . 19
4.1.2 MBZ . . . . . . . . . . . . . . . . . . . . . . 19
4.1.3 Flags . . . . . . . . . . . . . . . . . . . . . 19
4.1.4 Checksum . . . . . . . . . . . . . . . . . . . 19
4.1.5 Source port . . . . . . . . . . . . . . . . . . 20
4.1.6 Destination port . . . . . . . . . . . . . . . 20
4.1.7 Sequence . . . . . . . . . . . . . . . . . . . 20
4.1.8 Acknowledgement . . . . . . . . . . . . . . . . 20
4.1.9 Window . . . . . . . . . . . . . . . . . . . . 20
4.1.10 Options . . . . . . . . . . . . . . . . . . . . 20
4.2 Port numbers . . . . . . . . . . . . . . . . . . 20
4.3 TCP options . . . . . . . . . . . . . . . . . . . 21
4.3.1 Option Format . . . . . . . . . . . . . . . . . 21
4.3.2 Null . . . . . . . . . . . . . . . . . . . . . 21
4.3.3 Maximum Segment Size . . . . . . . . . . . . . 21
4.3.4 Urgent Pointer . . . . . . . . . . . . . . . . 21
4.3.5 32 Bit rollover . . . . . . . . . . . . . . . . 21
5. UDP: User Datagram protocol . . . . . . . . . . . 22
5.1 UDP header format . . . . . . . . . . . . . . . . 22
5.1.1 Data offset . . . . . . . . . . . . . . . . . . 22
5.1.2 MBZ . . . . . . . . . . . . . . . . . . . . . . 22
5.1.3 Checksum . . . . . . . . . . . . . . . . . . . 22
5.1.4 Source port . . . . . . . . . . . . . . . . . . 22
5.1.5 Destination port . . . . . . . . . . . . . . . 22
5.1.6 Options . . . . . . . . . . . . . . . . . . . . 23
6. ICMP . . . . . . . . . . . . . . . . . . . . . . . 23
6.1 ICMP header format . . . . . . . . . . . . . . . 23
6.2 Conversion failed ICMP message . . . . . . . . . 23
7. Notes on the domain system . . . . . . . . . . . . 25
7.1 A records . . . . . . . . . . . . . . . . . . . . 25
7.2 PTR zone . . . . . . . . . . . . . . . . . . . . 25
8. Conversion between version 4 and version 7 . . . . 25
8.1 Version 4 IP address extension option . . . . . . 26
8.1.1 Option format . . . . . . . . . . . . . . . . . . 26
8.2 Fragmented datagrams . . . . . . . . . . . . . . . 26
8.3 Where does the conversion happen? . . . . . . . . 27
8.4 Hybrid IPv4 systems . . . . . . . . . . . . . . . 28
8.5 Maximum segment size in TCP . . . . . . . . . . . 28
8.6 Forwarding and redirects . . . . . . . . . . . . . 28
8.7 Design considerations . . . . . . . . . . . . . . 28
8.8 Conversion from IPv4 to IPv7 . . . . . . . . . . . 29
8.9 Conversion from IPv7 to IPv4 . . . . . . . . . . . 30
8.10 Conversion from TCPv4 to TCPv7 . . . . . . . . . . 31
8.11 Conversion from TCPv7 to TCPv4 . . . . . . . . . . 32
8.12 ICMP conversion . . . . . . . . . . . . . . . . . 33
9. Postscript . . . . . . . . . . . . . . . . . . . . 33
10. References . . . . . . . . . . . . . . . . . . . . 34
11. Security Considerations . . . . . . . . . . . . . 35
12. Author's Address . . . . . . . . . . . . . . . . . 351. Introduction ✨
Okay so this memo is the spec for version 7 of the Internet Protocol 💅, plus version 7 of TCP and the user datagram protocol 🎀. Version 7 was designed to fix several major problems that popped up as version 4 evolved and got deployed everywhere, and to make a huge step forward in the datagram switching and forwarding architecture of the Internet 🦋.
The major problems are threefold 🫶. First, the address space of version 4 is now seen as way too small 😭. When version 4 was designed it was considered almost impossibly large, but two things happened to create a problem. The first is a success crisis: the internet protocols got more widely used and accepted than their designers ever expected 🔥. Also, technology moved forward and put microprocessors into devices that were only future dreams a decade ago 🧚.
The second major problem is a perceived routing explosion 💀. The present routing architecture of the internet has each organization's network routed independently. It's becoming increasingly clear that this doesn't scale to a universal internet. Sure, it's possible to route several billion networks in one flat, structureless domain, but it's not desirable 🙈.
There's also the political and administrative issue of assigning network numbers to organizations 🍓. Under version 4, organizations have to request network assignments from a single authority. That's been eased a bit by reserving blocks for delegated assignments, but the address space isn't large enough to do this in the necessary general case, with large blocks going to (for example) national authorities 🌸.
The third problem is the increasing bandwidth of networks and of the applications that are possible on the network 🚀. TCP has proven useful across an unprecedented range of network speeds, but it's now the limiting factor at the highest speeds because of restrictions on window size, sequence space, and port numbers. All of these limits can be addressed by increasing the sizes of the relevant fields. See [RFC1323] ✨.
There's also a chance to move the technology forward and take advantage of a combination of the best features of the hop-by-hop connectionless forwarding of version 4 (and CLNP), as well as the pre-established paths of version 5 (and, for example, the OSI CONS) 💜.
Internet Version 7 includes four major areas of improvement, while still keeping interoperation with version 4, with a small amount of conversion knowledge imposed on version 7 hosts and routers 👑:
- It increases the address fields to 64 bits, with sufficient space for visible future expansion of the internet 🌈.
- It adds a numbering layer for administrations, above the organization or network layer, as well as providing more space for subnetting within organizations 🫧.
- It increases the range of speeds and network path delays over which TCP will operate satisfactorily, as well as the number of transactions in bounded time that can be served by a host ⭐.
- Finally, it provides a forward route identifier in each datagram, to support extremely fast path, circuit, or flow-based forwarding, or any desired combination, while preserving hop-by-hop connectivity 🦋.
The result is not just a movement sideways, deploying a new network layer protocol to patch current problems. It is a significant step forward for network layer technology,
1. Introduction
1.1. Objectives
okay bestie, here's the wishlist for this design ✨ these are the goals:
- Learn from IP version 4 🦋 fix the stuff that's troublesome, and leave alone the stuff that isn't broken.
- Keep the essential "look and feel" of the Internet protocol suite 💅 it's been SO successful, and you don't argue with success.
- Don't stuff in concepts the Internet has already shown don't belong in the protocol definition 🙈 best example: no routing info crammed into the addressing, except the administrative hierarchy, which has sometimes been useful. The one routing-aid in v4 addressing (the class system) is now the most serious single problem 💀
- Let current hosts keep interoperating, if not universally then at least within an organization or bigger area, for the indefinite future. There will be version 4 hosts for 10-15 years into the future, so the Internet has to stay on good terms with them 🫶
- Don't 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.
- The design must let individual hosts and routers get upgraded effectively at random, with no transition plan constraints 🎀
- The design must not require renumbering the Internet. The admin work already done is immense, and if it's done again, it'll be in assigning NSAPs 🥲
- 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 keep operating within their organization at least.)
- 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 🧚
- It must be a competent alternative to CLNP 👑
- It must not change 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 🍓
- It must be defined Real Soon. The window of opportunity is almost closed, and vendors will take 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 of them are essential to the survival of the Internet 🌈
1.2. Philosophy
Protocols should become simpler as they evolve. ✨
2. Internet numbers
The version 4 numbering system has proven to be very flexible, (mostly) expandable, and simple. In short: it works 💖 There are two problems. Neither was serious when this specification was first developed in 1988 and 1989, but as expected, they have become more serious:
- The division into network, and then subnet, is insufficient. Almost all sites need a network assignment large enough to subnet. At the top of the hierarchy, there is a need to assign administrative domains.
- As bit-packing is done to accomplish the desired network structure, the 32 bit limit causes more and more aggravation 😤
2.1. Is 64 Bits Enough?
Consider this 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^32 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.
2.2. Why version 7?
It was clearly recognized at the start of this project in 1988 that making the address 64 bits implies a new IP header format. It 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, which I wasn't aware of until recently. I suspected it might have been allocated 6. Besides, I liked 7 💜
Apparently (as reported by Bob Braden), the IAB followed much the same logic, and may have had the idea planted by the mention of version 7 in the "Toasternet Part II" memo 🍞 The IAB in June 1992 floated a proposal that CLNP, or a CLNP-based design, be Internet Version 7. (And promptly got themselves toasted. 💀) However, close inspection of the bits shows that CLNP is clearly version 8 🔥
2.3. The version 7 IP address
The Version 7 IP 64 bit address looks like this:
+-------+-------+-------+-------+-------+-------+-------+-------+
| Admin Domain | Network | Host |
+-------+-------+-------+-------+-------+-------+-------+-------+Note!! ✨ the boundary between "network" and "host" is no more fixed than it is today. Each (sub)network will have its own mask. Just as the mask today can be anywhere from FF00 0000 (8/24) to FFFF FFFC (30/2), the mask for the 64 bit address can reasonably be FFFF FF00 0000 0000 (24/40) to FFFF FFFF FFFF FFFC (62/2) 🎀
The AD (Administrative Domain) identifies an administration, which may be a service provider, a national administration, or a large multi-organization (e.g. a government) 🏛️ The idea is that there should not be more than a few hundred of these at first, and eventually thousands or tens of thousands at most. (But note that we do not introduce a hard limit of 2^16 here. This estimate may be off by a few orders of magnitude.) Since only 1/4th of the address space is initially used (the first two bits are 01), the remainder can then be allocated in the future, with more information available 🦋
Most individual organizations would not be ADs. In the short term, ADs are known to the "core routing". It pays to keep the number smallish, a few thousand given current routing technology. In the long term, this is not necessary. Big administrations (i.e., with tens of millions of networks) get small blocks where needed, or additional single AD numbers when needed 🌸
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 on 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 📞 no detours, bestie!
2.4. AD numbers
AD numbers are allocated out of the same numbering space as network numbers. This means that a version 4 address can be distinguished from the first 32 bits of a version 7 address. This is useful to help prevent the inadvertent use of the first half of the longer address by a version 4 host 🛡️
There is a non-trivial amount of software that assumes that an "int" is the same size and shape as an IP address, and does things like ipaddr = *(int *)ptr. This usage has always been incorrect, but it does occur with disturbing frequency 😬 As IPv7 8 byte addresses appear in the application layers, this software will find those addresses unreachable. This is preferable to interacting with a random host 🙃
One possible method would be to allocate ADs in the range 96.0.0 to 192.255.255, using the top 1/4 of the version 4 class A space. It is probably best to allocate the first component downwards from 192, so that the boundary between class A and AD can be moved if desired later. This initial allocation provides for 2031616 ADs, which is many more than there should be, even in full deployment 🥳
Eventually, both AD and network will use the full 24 bit space available to them. Knowledge of the AD range should not be coded into software. If it was coded in, that software would break when the entire 24 bit space is used for ADs. (This lesson should have been learned from CIDR.) 📚
2.5. Mapping of version 4 numbers
Initially, all existing Internet numbers are defined as belonging to the NSF/Internet AD, number 192.0.0. 🏠
The mapping from/to version 4 IP addresses looks like this:
+-------+-------+-------+-------+-------+-------+-------+-------+
| Admin Domain | Network | Host |
+-------+-------+-------+-------+-------+-------+-------+-------+
[ fixed at A0 00 00 ] [ 1st 24 bits of V4 IP] [1] [last 8]So, for example, 192.42.95.15 (V4) becomes 192.0.0.192.42.95.1.15 ✨
And the "standard" loopback interface address becomes 192.0.0.127.0.0.1.1. (I can see explaining that in 2015 to someone born in 1995. 🙈)
The present protocol multicast (192.0.0.224.x.y.1.z) and loopback addresses are permanently allocated in the NSF AD 💜
3. IP: Internet datagram protocol
The Internet datagram protocol is revised to expand some fields (most notably the addresses), while removing and relegating to options all fields that are 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. IPv4 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. A future Host Requirements specification for hosts and routers used in the "connected Internet" may require some options in its profile, e.g., Fragment would probably be required 🧩
Digression: In IPv4, options are often "considered harmful". It is the opinion of the present author that this is because they are rarely needed, and not designed to be processed rapidly on most architectures. This leads to little or no attempt to improve performance in implementations, while at the same time enormous effort is dedicated to optimization of the no-option case. IPv7 is expected to be different on both counts 🙌
Fields are always aligned on their own size. The 64 bit fields sit 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 🎀
3.1. IP datagram header format 🎀
Bestie, the header is where the whole vibe lives 💖 Here's the layout, and then we go field by field 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| header length | time to live |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| total datagram length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ forward route identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ destination address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ source address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| protocol | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Okay so each field gets its own little explainer, no cap. Read these, they're the good stuff ✨
3.1.1. Version
This doc is all about version 7 of the protocol 🦋 main character era ✨
3.1.2. Header length
The header length is a 12 bit count of the number of 32 bit words in the IPv7 header 📏 So a header can be (theoretically at least) up to 16380 bytes long 😭 huge.
3.1.3. Time to live
TTL is a 16 bit count, nominally in 1/16 seconds ⏱️ and each hop is required to decrement it by at least one 🧚
This definition should allow us to keep the useful (even if not entirely valid) reading of TTL as a hop count 🌸 while we move to faster networks and routers 🏎️ The most familiar use is by "traceroute" 🙈 which honestly ought to be directly implemented by one or more ICMP messages.
The scale factor turns the usual version 4 default TTL into a bigger number of hops 📈 This is desirable because the forward route architecture of version 7 makes simpler, faster switches possible 🔥 and that may cause the network diameter to increase 👀
3.1.4. Total datagram length
It's the 32 bit length of the entire datagram, in octets 📦 so a datagram can be up to 4294967295 bytes overall 🤯 Particular networks will normally impose lower limits 🫶
3.1.5. Forward route identifier
This is the identifier from the routing protocol that the next hop router uses to find its next hop 🗺️ (The full tea is down below ✨)
3.1.6. Destination
The 64 bit IPv7 destination address 📬
3.1.7. Source
The 64 bit IPv7 source address 📮
3.1.8. Protocol
This is the transport layer protocol, e.g., TCP is 6 🧁 The present code space for this layer of demultiplexing is about half full 😬 so expanding it to 16 bits, allowing 65535 registered "transport" layers, seems prudent 💅
3.1.9. Checksum
A 16 bit checksum of the entire IP header, using the familiar algorithm used in IPv4 🧮 iconic.
3.1.10. Options
Options may follow 🎀 They're variable length and always 32 bit aligned, as discussed previously 🌈
3.2. Option Format 🧸
Every 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field does 💜
3.2.1. Class (C)
This field tells implementations what to do with datagrams containing options they don't understand 🤔 No implementation is required to implement (i.e., understand) any given option by the TCP/IP specification itself, which is lowkey wild 🙈
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 datagramSo a host that gets a datagram addressed to itself will use it if there are no unknown options of class 2 or 3 💖 And a router that gets a datagram not addressed to it will forward it if and only if there are no unknown options of class 1 or 3 🦋 (The astute reader will notice the bits can also be read as separate meanings: one lets it be used even if unknown, one lets it be forwarded if unknown 🧠)
Classes 0 and 2 are imperative 🫡 If the datagram gets 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 the option definition restricts it.
Also, for options the host or router already knows (implements), the class has no meaning 💅 The option definition totally determines the behavior, although the option might explicitly define a class dependent behavior, so keep an eye out 👀
3.2.2. Copy on fragmentation (F)
If the F bit is set, this option must be copied into all fragments when a datagram gets fragmented 🧩 If the F bit is reset (zero), the option must only be copied into the first (zero-offset) fragment 🥹
3.2.3. Type
The type field identifies the particular option 🏷️ Types are registered as well known values in the internet 🌐 A few of the options with their types are described below 💜
3.2.4. Length
Length of the option data, in bytes 📏
3.2.5. Option data
It's variable length, set 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. That's the usual case when the option is the only one present and immediately follows the IP header ✨
3.3. IP options 🌷
The next sections describe the options defined to emulate IPv4 features, or necessary in the basic structure of the protocol 🎀
3.3.1. Null
The null option, type 0, is 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 and leaving the length and content of the data unmodified 🔄
⚠️ Heads up bestie: this implies 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 it need not be implemented to serve its function 💅
3.3.2. Fragment
Fragment (type 1) indicates that the datagram is part of a complete IP datagram 🧩 It is always class 2.
The data consists of (one of) the 64 bit IP address(es) of the router doing the fragmentation 📍, a 64 bit datagram ID generated by that router 🆔, and a 32 bit fragment offset 📐 The IDs should be generated so as to be very likely unique over a period of time larger than the TCP MSL (maximum segment lifetime) ⏳ (The TCP ISN (initial sequence number) generator might be used to initialize the ID generator in a router 🌱)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C |F| type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ fragmenting router IP address +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ datagram ID +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+If a datagram must be refragmented, the original 128 bit address+ID is preserved 🔒 so that the datagram can be reassembled from any sufficient set of the resulting fragments 🧵 The 64 bits fields are positioned so that they are aligned in the usual case of the fragment option following the IP header 📐✨
A router implementing Fragment (doing fragmentation) must recognize the Don't Fragment option 🙅♀️
3.3.3. Last Fragment
Last Fragment (type 2) has the same format as Fragment, but it 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 total length is known) 🧩 This will work well when datagrams are not reordered in the network 🫶
3.3.4. Don't Fragment
This option (type 3, class 0) indicates that the datagram may not be fragmented 🚫 If it can not be forwarded without fragmentation, it is discarded, and the appropriate ICMP message sent 📨 (Unless, of course, the datagram is an ICMP message 💀.) There is no data present.
3.3.5. Don't Convert
The Don't Convert option prohibits conversion from IPv7 to IPv4 protocol 🚫 Instead, the datagram gets discarded and an ICMP message gets sent (conversion failed/don't convert set) 📭
It's type 4, usually class 0, and it 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, so the host receiving the datagram may convert it as part of its procedure 🌀 There is no data present in this option.
3.4. Forward route identifier 🗺️
Each IP datagram carries a 64 bit field called "forward route identifier" 💫 It gets updated (if the information is available) at each hop 🔁 This field's value is derived from the routing protocol (e.g., RAP [RFC1476]) 📚 It's used to expedite routing decisions by preserving knowledge where possible between consecutive routers 🏎️ It can also be used to make datagrams stay within reserved flows and mobile-host tunnels where required 🦋
3.4.1 Procedure description
okay so picture three routers, A, B, and C 🧚🎀. Traffic is zipping through all of them between two hosts (or networks), X and Y, so packets go XABCY and YCBAX 💖. We only look at one direction here: routing info flowing from C to A, which gives A a route to C. The other direction works the same way, bestie 💅.
First, the notation (don't panic, it's just labels 🫶):
R(r,d,i,h) A route that means: "from router r, to go toward
final destination d, replace the forward route
identifier in the packet with i, and take next
hop h."
Ri(r,d) An opaque (outside of router r) identifier, that
can be used by r to find R(r,d,...).
Flowi(r,rt) An opaque (outside of router r) identifier, that
router r can use to find a flow or tunnel with which
the datagram is associated, and from that the route
rt on which the flow or tunnel is built, as well as
the Flowi() for the subsequent hop.
Ri(Dgram) The forward route identifier in a datagram.okay so router C announces the route R(C,Y,0,Y) to router B 📣. It includes an identifier Ri(C,Y) that's internal to C, which lets C find the route super fast (think a table index or an actual memory address ⚡).
Router B creates R(B,Y,Ri(C,Y),C) via router C, and announces it to A 🙌. It includes an identifier Ri(B,Y), which is internal to B. A just treats it as an opaque object, aka a mystery blob that only B understands 🔮.
Router A creates R(A,Y,Ri(B,Y),B) via router B. It has no one to announce it to 🥲.
Now the fun part. X originates a datagram addressed to Y. It has no routing information, so it sets Ri(Dgram) to zero and forwards the datagram to router A (X's default gateway) 📦.
A finds no valid Ri(Dgram), so it looks up the destination (Y) in its routing tables. It finds R(A,Y,Ri(B,Y),B), sets Ri(Dgram) <- Ri(B,Y), and forwards the datagram to B 🏃♀️.
Router B looks at Ri(Dgram), which directly identifies the next hop route R(B,Ri(C,Y),C). It sets Ri(Dgram) <- Ri(C,Y) and forwards it to router C 🧃.
Router C looks at Ri(Dgram), which directly locates R(C,0,Y). It sets Ri(Dgram) <- 0 and forwards to Y 🎉.
Y recognizes its own address in Dest(Dgram) and ignores Ri(Dgram) ✨.
Of course, the routers will validate the Ri's they receive, especially if they're memory addresses (e.g., M(a) < Ri < M(b), Ri mod N == 0), and they'll probably check that the route actually describes the datagram's destination 🔍. If the Ri is invalid, the router MUST use the ordinary method of finding a route (i.e., what it would have done if Ri was 0), and silently ignore the invalid Ri 🫥.
When a route has been aggregated at some router, implicitly or explicitly, it will find that the incoming Ri(Dgram) at most can identify the aggregation, and it MUST make a decision. The forwarded datagram then contains the Ri for the specific route. (Note this can happen well upstream of the point at which the routes actually diverge.) 🌿
This allows all cooperating routers to make immediate forwarding decisions, without any searching of tables or caches once the datagram has entered the routing domain 🏎️. If the host participates in the routing, at least to the extent of acquiring the initial Ri REQUIRED from the first router, then only routers that have done aggregations need make decisions. (If the routing changes with datagrams in flight, some router will be REQUIRED to make a decision to re-rail each datagram.) 🚂
3.4.2 Flows
If a "flow" is to be set up, the identifiers get replaced by Flowi(router,route), where each router's structure for the flow contains a pointer to the route the flow is built on 🌊. Datagrams can drop out of the flow at some point, and can be inserted either by the originating host or by a cooperating router near the originator 🪂. Since the forward route identifier field is opaque to the sending router and only implicitly meaningful to the next hop router, use for flows (or similar optimizations) doesn't need to be otherwise defined by the protocol 🤷♀️. (One presumes that a router issuing both Ri's and Flowi's will take care to make sure it can tell them apart by some private method 🕵️.)
If a flow has been set up by a restricted target RAP route announcement, it's no different from a route in the implementation 🧩. If this announcement originates from the host itself, the Ri in incoming datagrams can be used to determine whether they followed the flow, or to optimize delivery of the datagrams to the next layer protocol 💫.
3.4.3 Mobile hosts
First, a definition 📖: a "mobile host" is a host that can move around, connecting via different networks at different times, while maintaining open TCP connections. It's distinguished from a "portable host", which is simply a host that can appear in various places in the net, without continuity. A portable host can be implemented by assigning a new address for each location (more or less automatically), and arranging to update the domain system 🗺️. Supporting truly mobile hosts is the more interesting problem 😏.
To implement mobile host support in a general way, either some layer of the protocol suite MUST provide network-wide routing, or the datagrams MUST be tunnelled from the "home" network of the host to its present location 🏠. In the real network, some combination of these is probable: most of the net will forward datagrams toward the home network, and then the datagrams will follow a specific host route to the mobile host 📬.
The requirement on the routing system is that it MUST be able to propagate a host route at least to the home network. Any other distribution is useful optimization 🧠. When a host route is propagated by RAP as a targeted route, and the routers use the resulting Ri's, the datagram follows an effective tunnel to the mobile host 🚇. (Not a real tunnel, in the strict sense. The datagrams are following an actual route at the network protocol layer.)
As explained in RAP [RFC14XX-RAP], a targeted route can be issued when desired. In particular, it can be triggered by the establishment of a TCP connection or by the arrival of datagrams that do not carry an Ri indicating that they have followed a (non-tunnel) route 🎯.
4. TCP: Transport protocol ✨
Internet version 7 expands the sizes of the sequence and acknowledgement fields, the window, and the port numbers 🌈. This is to remove limitations in version 4 that begin to restrict throughput at (for example) the bandwidth of FDDI and round trip delay of more than 60 milliseconds. At gigabit speeds and delays typical of international links, the version 4 TCP would be a serious limitation 😤. See [RFC1323].
The port numbers are also expanded. This alleviates the problem of going through the entire port number range with a rapid sequence of transactions in less than the lifetime of datagrams in the network 🦋.
4.1 TCP segment header format
The 64 bit fields (sequence and acknowledgement) in the TCP header are off-phase aligned, in anticipation of the usual case of the TCP header following the 9 32-bit word IP header 🧩. If IP options add up to an odd number of 32 bit words, a null option MAY be added to push the transport header to off-phase alignment 🎀.
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each field does 👇
4.1.1 Data offset
An 8 bit count of the number of 32 bit words in the TCP header, including any options 📏.
4.1.2 MBZ
Reserved bits, MUST be zero, and MUST be ignored 🙅♀️.
4.1.3 Flags
These are the protocol state flags, used exactly as in TCPv4, except that there's no urgent data flag 🚩.
4.1.4 Checksum
This is a 16 bit checksum of the segment 🧮. The pseudo-header used in the checksum consists of the destination address, the source address, the protocol field (constant 6 for TCP), and the 32 bit length of the TCP segment.
4.1.5 Source port
The source port number, a 32 bit identifier. See the section on port numbers below 🔢.
4.1.6 Destination port.
The 32 bit destination port number 🎯.
4.1.7 Sequence
A 64 bit sequence number, the sequence number of the first octet of user data in the segment 🍰.
The ISN (Initial Sequence Number) generator used in TCPv4 is used in TCPv7, with the 32 bit value loaded into both the high and low 32 bits of the TCPv7 sequence number. This provides reasonable behavior when the 32 bit rollover option is used (see below) for TCPv4 interoperation. V7 hosts MUST implement the full 64 bit sequence number rollover 🔁.
4.1.8 Acknowledgement
The 64 bit acknowledgement number, acknowledging receipt of octets up to but not including the octet identified 🫶. Valid if the A flag is set. If A is reset (0), this field SHOULD be zero, and MUST be ignored 🙈.
4.1.9 Window
The 32 bit offered window 🪟.
4.1.10 Options
TCP options, some of which are documented below 📚.
4.2 Port numbers
Port numbers are divided into several ranges (all numbers are decimal) 🔢:
0 reserved
1-32767 Internet registered ("well-known") protocols
32768-98303 reserved, to allow TCPv7-TCPv4 conversion
98304 up dynamic assignmentIt 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 in the registered range 🚫.
4.3 TCP options
4.3.1 Option Format
Each option begins with a 32 bit header 🧃:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option data ... | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.3.2 Null
The null option (type = 0), is to be ignored 🫥.
4.3.3. Maximum Segment Size
okay so the maximum segment size option (type = 1) is basically one TCP telling the other one "bestie pls don't send me anything bigger than this many data octets" 🎀. when it shows up on a SYN segment it's mandatory 💅, but on any other segment it's just advisory, like a friendly little suggestion 🌸
the data part is simple: it's one 32 bit word that says the size in octets 🍓
4.3.4. Urgent Pointer
the urgent pointer (type = 2) is the v7 glow-up of the urgent field from TCPv4 🦋. its presence is the same thing as having the U flag set ✨. the data is a 64 bit sequence number that identifies the last octet of urgent data (not an offset like in v4, so don't mix them up 🙈)
4.3.5. 32 Bit rollover
the 32 bit rollover option (type = 3) says that only the low order 32 bits of the sequence and acknowledgement packets are significant in the packet 🧚
this is needed because a converting internet layer gateway has no retained state, so it can't properly set the high order bits 💀. this option MUST be implemented by version 7 hosts that want to interoperate with version 4 hosts 🫶
5. UDP: User Datagram protocol ✨
UDP got a glow-up too 💖. it's also expanded to include larger port numbers, for reasons pretty similar to TCP.
5.1. UDP header format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data offset | MBZ | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here's what each field does 👇
5.1.1. Data offset
an 8 bit count of the number of 32 bit words in the UDP header, including any options 📏
5.1.2. MBZ
reserved bits. they MUST be zero, and they MUST be ignored 🙅
5.1.3. Checksum
this is a 16 bit checksum of the datagram 🧮. the pseudo-header used in the checksum is made up of the destination address, the source address, and the protocol field (constant 17 for UDP), plus the 32 bit length of the user datagram 💜
5.1.4. Source port
the source port number, a 32 bit identifier 🌈. see the section on TCP port numbers above ✨
5.1.5. Destination port.
the 32 bit destination port number 🎯
5.1.6. Options
UDP options, none are presently defined 🫧 (so no options for now, bestie 💅)
6. ICMP 🧚
the ICMP protocol is very similar to ICMPv4, and in some cases it doesn't need any conversion at all 🙌
the complication is that IP datagrams are nested inside ICMP messages, and those nested datagrams MUST be converted. we'll get to that later 👀
6.1. ICMP header format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | code | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type-specific parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type-specific data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the type and code values are well-known and defined in [RFC792] 📖. the codes only have meaning inside a particular type, so they're not orthogonal 🙃
the next 32 bit word is usually defined for the specific type, but sometimes it's unused 🤷♀️
for lots of types, the data is a nested IP datagram, usually truncated, which is a copy of the datagram that caused the event being reported 🪞. in IPv4, the nested datagram is the IP header plus 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 (so the port numbers inside TCP and UDP come along for the ride 🎀), and SHOULD include the first 256 bytes of the datagram. i.e., in most cases where the original datagram wasn't large, it'll return the entire datagram 🫶
6.2. Conversion failed ICMP message
the introduction of network layer conversion needs a new message type, so we can report conversion errors 🚨. note that an invalid datagram SHOULD result in some other ICMP message being sent (e.g., parameter problem) or the datagram being silently discarded 🗑️. this message only gets sent when a valid datagram can't be converted ✨
Note: implementations are not expected to, and SHOULD NOT, check the validity of incoming datagrams just to pull this off. it just means that an error found during conversion that's a real error in the incoming datagram SHOULD be reported as that error, not as a conversion failure 💅
note that the conversion failed ICMP message MAY be sent in either the IPv4 or IPv7 domain. it's a valid ICMP message type for IPv4 too 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type | code | checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pointer to problem area |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| copy of datagram that could not be converted .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the type for Conversion Failed is 31 🔥
the codes are:
0 Unknown/unspecified error
1 Don't Convert option present
2 Unknown mandatory option present
3 Known unsupported option present
4 Unsupported transport protocol
5 Overall length exceeded
6 IP header length exceeded
7 Transport protocol > 255
8 Port conversion out of range
9 Transport header length exceeded
10 32 Bit Rollover missing and ACK set
11 Unknown mandatory transport option presentthe use of code 0 SHOULD be avoided. any other condition that implementors find SHOULD be assigned a new code requested from IANA 📝. when code 0 is used, it's super important that the pointer is set properly 🙏
the pointer is an offset from the start of the original datagram to the beginning of the offending field 📍
the data is the part of the datagram that couldn't be converted. it MUST be at least the IP and transport headers, and it MUST include the field the previous parameter points to 🎯. for code 4, the transport header probably isn't identifiable, so the data SHOULD include 256 bytes of the original datagram 💖
7. Notes on the domain system 🍓
7.1. A records
address records will be added to the IN (Internet) zone with IPv7 addresses for all hosts as IPv7 gets deployed 🌐. eventually the IPv4 addresses will be removed 👋. as mentioned above, the AD (Administrative Domain) space is initially assigned so that the first 4 octets of a v7 address can't be confused with a v4 address (or, rather, the confusion will be to no effect 🙃)
for example:
DELTA.Process.COM. A 192.42.95.68
A 192.0.0.192.42.95.1.68it's important that the A record be used, to avoid the cache consistency problem that would show up when different records had different remaining TTLs ⏳
note that if an unmodified version of the more popular public domain nameserver is a secondary for a zone containing IPv7 addresses, it will erroneously issue RRs with only the first four bytes. (i.e., 192.0.0.192 in the example.) that's another reason to make sure the AD numbers are initially reserved out of the IPv4 network number space 🚫. eventually, zones with IPv7 addresses would be expected to be served only by upgraded servers 🫶
7.2. PTR zone
the inverse (PTR) zone is .#, with the IPv7 address (reversed) 🔄. i.e., it's 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 only holds authority for the AD 0.0.192.#. (plus, of course, any other ADs assigned to it over time 🌟)
8. Conversion between version 4 and version 7 🌈
as noted in the description of the datagram format, it's possible to provide a mostly-transparent bridge between version 4 and version 7 🌉
this covers 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, but it'll probably be necessary to specify exactly which ones do get translations 📋
new protocols at the session/transport layer defined over IPv7 SHOULD have protocol numbers greater than 255, and they won't 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 is computed for the generated datagram ✅
8.1. Version 4 IP address extension option
a new option is defined for IP version 4 to carry the extended addresses of IPv7 💌. this will be particularly useful in the initial testing of IPv7, during a time when most of the internet's fabric is still IPv4 🧵. an IPv7 host will be able to connect to another IPv7 host anywhere on the internet even though most of the paths and routers are IPv4, and it can still use the full addressing 🦋. this keeps working until non-unique network numbers get assigned, and by then most of the infrastructure SHOULD be IPv7 🔮
8.1.1. Option format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type (147) | length = 10 | source IPv7 AD number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | src 7th octet | destination IPv7 AD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number ... | dst 7th octet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the source and destination are in IPv4 order (source first), for consistency 🫶. the type code is 147 🔢
8.2. Fragmented datagrams
datagrams that have been fragmented MUST be reassembled by the converting host or router before conversion 🧩. when the conversion is being done by the destination host (i.e., a v7 host receiving v4 datagrams), this is similar to the present fragmentation model 💅
when it's being done by an intermediate router (acting as an internetwork layer gateway), the router SHOULD use all of source, destination, and datagram ID to identify 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 💀
8.3. Where does the conversion happen? 🤔
okay so the whole point of conversion is letting systems get upgraded in whatever order their owners want 💖. Orgs need to be able to upgrade any one system without reconfiguring or changing any other, and v4 hosts need to keep interoperating essentially forever ✨. (v4 routers will probably get effectively eliminated at some point, except out in their own remote or isolated corners 🏝️)
Each TCP/IP v7 system, 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: ngl I believe v7 hosts will get way better performance by doing everything internally in v7 and only using conversion to filter datagrams when it's actually needed 🚀. That keeps the usual code path simple, with just a "hook" right after receiving to convert incoming IPv4 datagrams, and another right 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 only convert if necessary. Either way it's an implementation specific decision 🧚.
Here's the big one 👀: any forwarding system may convert datagrams to IPv7, then back to IPv4, even if that loses information such as unknown options. The reverse is not acceptable. A system that receives an IPv7 datagram should not convert it to IPv4, then back to IPv7 on forwarding 🙅.
The preferred method for figuring out which hosts need conversion is to ARP first for the IPv7 address, and then again if no response comes back, 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 move is to assume that a remote system is v7. If an IPv7 datagram comes in from it, the assumption is confirmed ✅. If, after a short time, no IPv7 datagram shows up, a v7 ICMP echo gets sent. If a reply is received (in either version), the assumption is confirmed.
If no reply is received, the remote system is assumed not to understand IPv7, and datagrams get converted to IPv4 just before transmitting them 📤.
Implementations should also provide for explicit configuration where desired ⚙️.
8.4. Hybrid IPv4 systems 🌈
In the course of implementing IPv7, especially in constrained environments like 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 who aren't ready to do a major rework of their 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.
Lowkey the big implication here: it is not valid to assume that a host with an IPv7 address is a native IPv7 implementation 🙈.
8.5. Maximum segment size in TCP 📏
It is probably advisable for IPv4 implementations to reduce the MSS they offer by a small amount where possible, to avoid fragmentation when datagrams are converted to IPv7. This comes up when IPv4 hosts are communicating through an IPv7 infrastructure, with the same MTU as the local networks of the hosts 🧩.
8.6. Forwarding and redirects 🔀
It may be important for a router to not send ICMP redirects when it finds that it has to 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 that results in an unpleasant level of noise as the sequence keeps recurring 📢.
8.7. Design considerations 🛠️
The conversion is designed to be fairly efficient to implement, 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, since they weren't designed for speed on a 32 bit aligned RISCish architecture. But they don't occur often, except perhaps the address extension option 🤷.
For CISC machines, the same considerations will lead to fairly efficient code 💜.
The conversion code must be extremely careful to be robust when presented with invalid input. In particular, it may be presented with truncated transport layer headers when called recursively from the ICMP conversion 💀.
8.8. Conversion from IPv4 to IPv7 🦋
Here are the individual steps in the conversion. The order is in most cases not significant ✨.
- Verify checksum.
- Verify fragment offset is
0, MF flag is0. - Verify version is
4. - Extend TTL to 16 bits, multiply by 16.
- Set forward route identifier to
0. - Set first 3 octets of destination to AD (i.e.,
192.0.0), copy first three octets from v4 address, set next octet to1, copy last octet. (This can be done with shift/mask/or operations on most architectures 🧠.) - Do the same translation on source address.
- Copy protocol, set high 8 bits to zero.
- If DF flag set, add Don't Fragment option.
- If Address Extension option present, copy ADs and subnet extension numbers into destination and source.
- 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 🙃.
- Compute new IP header length.
- Convert session/transport layer (TCP) header and data.
- Compute new overall datagram length.
- Calculate IPv7 checksum.
8.9. Conversion from IPv7 to IPv4 🔁
The steps to convert IPv7 to IPv4 follow. Note that the converting router or host is partly in the role of destination host 🎯. It checks both bits of class in IP options, and (as in the other direction) must reassemble fragmented datagrams 🧵.
- Verify checksum.
- Verify version is 7
- Set type-of-service to
0(there may be an option defined that will be handled later). - If length is greater than (about)
65563, fail. (That number is not a typographical error 👀. Note that the IPv7+TCPv7 headers add up to 28 bytes more than the corresponding v4 headers in the usual case.) This check is only to avoid useless work. The precise check is later. - Generate an ID (using an ISN based sequence generator, possibly also based on destination or source or both) 🎲.
- Set flags and fragment field to
0. - Divide TTL by 16. If zero, fail (send ICMP Time Exceeded). If greater than
255, set to255. - If next layer protocol is greater than
255, fail. Else copy. - Copy first 3 octets and 8th octet of destination to destination address.
- Same for source address.
- Generate v4 address extension option. (If enabled. This probably should be a configuration option, and should default to on ⚙️.)
- Process v7 options. If any unknown options of class not
0are found, fail. - If Don't Fragment option found, set DF flag.
- If Don't Convert option found, fail.
- Convert other options where possible, or fail.
- Compute new IP header length. This may fail (too large), so fail conversion if so.
- Convert session/transport layer (e.g., TCP).
- Compute new overall datagram length. If greater than
65535, fail. - Compute IPv4 checksum.
8.10. Conversion from TCPv4 to TCPv7 🌸
- Subtract header words from v4 checksum. (Note that this is actually done with one's complement addition.)
- Copy flags (except for Urgent).
- If source port is less than
32768(a sign condition test will suffice on most architectures), copy it. If equal or greater, add65536. - Same operation on destination port.
- Copy sequence to low 32 bits, set high to
0. - Copy acknowledgement to low 32 bits, set high to
0. - Copy window. (The TCPv4 performance extension [RFC1323] window-scale cannot be used, as it would require state. We use the basic window offered 🪟.)
- Add 32 bit rollover option.
- Convert maximum segment size option if present.
- Compute data offset and copy data.
- Add header words into saved checksum. It is important not to recompute the checksum over the data. It must remain an end-to-end checksum 🌈.
- Return to IP layer conversion.
8.11. Conversion from TCPv7 to TCPv4 🍓
- Subtract header from v7 checksum.
- If source port is greater than
65535, subtract65536. If result is still greater than65535, fail. (Send ICMP conversion failed/port conversion out of range. The sending host may then reset its port number generator to98304🔄.) - Same translation for destination port.
- Copy low 32 bits of sequence number.
- If A bit set, copy low 32 bits of acknowledgement.
- Copy flags.
- If window is greater than
61440, set it to24576. 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 🙈.) - Process options. If 32 Bit Rollover is not present, and A flag is set, fail. (Send ICMP conversion failed/32 bit Rollover missing.)
- If Urgent is present, compute offset. If in segment, set U flag and offset field. If not, ignore.
- Convert Maximum Segment Size option. If greater than
16384, set to16384. - Compute new data offset.
- Add header words into v4 checksum.
- Return to IP layer conversion.
8.12. ICMP conversion ✨
okay so ICMP messages get converted by copying the type and code into the new packet, and then copying the other type-specific fields straight across. no cap, that's the whole vibe 💅
If the message contains an encapsulated, and usually truncated, IP datagram, the conversion routine gets called recursively to translate it as far as possible. There are some special considerations, bestie 🫶
- The encapsulated datagram is less likely to be valid, given that it already caused an error of some kind 😭
- The conversion should try to complete all the fields it can, even if some would fail in the general case. Here's the tea: when a failure happens while converting a datagram, an ICMP message (conversion failed) gets sent, and that message itself might need converting right away. Part of that conversion involves converting the original datagram again 🌀 it's a whole loop, iykyk
- Conditions like an overall datagram length that's too large are not checked 🙈
- The AD and subnet byte assumed in the nested conversion may not make sense if the IPv4 address extension option isn't present and the datagram has strayed from the expected AD. (Not unlikely, since we know a priori that some error occurred 💀)
- The conversion must be very sure not to make another recursive call if the nested datagram is an ICMP message. (This shouldn't happen, but obviously it may 🫠)
- 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, one that handles these issues outside the optimized usual path. Keep the fancy stuff separate, periodt 💅
9. Postscript 🦋
ngl, the current version of TCP/IP has been a success partly by accident. Nobody really designed for a lot of the reasons it works. Perhaps the most significant one is the low level of network integration required to make it work. Main character energy, but make it accidental 🌈
We have to be careful to keep the ingredients that made it succeed, even the ones we don't realize are doing the heavy lifting 🫶 Tread lightly, use everything we've learned, and especially don't change things that already work ✨
This document describes a fairly conservative step forward. It has clear extensibility for future developments, and it does all of this without jumping into the abyss 🌸
10. References 📚
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, USC/Information Sciences Institute, August 1980.
[RFC791] Postel, J., "Internet Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 791, DARPA, September 1981.
[RFC792] Postel, J., "Internet Control Message Protocol - DARPA Internet Program Protocol Specification" STD 5, RFC 792, USC/Information Sciences Institute, September 1981.
[RFC793] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, USC/Information Sciences Institute, September 1981.
[RFC801] Postel, J., "NCP/TCP Transition Plan", USC/Information Sciences Institute, November 1981.
[RFC1287] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, "Towards the Future Internet Architecture", RFC 1287, MIT, BBN, CNRI, ISI, UCDavis, December 1991.
[RFC1323] Jacobson, V., Braden, R, and D. Borman, "TCP Extensions for High Performance", RFC 1323, LBL, USC/Information Sciences Institute, Cray Research, May 1992.
[RFC1335] Wang, Z., and J. Crowcroft, A Two-Tier Address Structure for the Internet: A Solution to the Problem of Address Space Exhaustion", RFC 1335, University College London, May 1992.
[RFC1338] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BARRNet, cicso, Merit, OARnet, June 1992.
[RFC1347] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing", RFC 1347, DEC, June 1992.
[RFC1476] Ullmann, R., "RAP: Internet Route Access Protocol", RFC 1476, Process Software Corporation, June 1993.
[RFC1379] Braden, R., "Extending TCP for Transactions -- Concepts", RFC 1379, USC/Information Sciences Institute, November 1992.
11. Security Considerations 💀
Security issues are not discussed in this memo. 😱 Yes, you read that right. The whole security section is literally one sentence, so if you're building something with this, do your own homework, bestie 🔥
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
That's a wrap, the end of RFC 1475! 🌈✨👑
📦 where this page comes from
- ietf: rfc1475 1993-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms