space. Eventually, zones with IPv7 addresses would be expected to be
served only by upgraded servers.
7.2 PTR zone
The inverse (PTR) zone is .#, with the IPv7 address (reversed).
I.e., just like .IN-ADDR.ARPA, but with .# instead.
This respects the difference in actual authority: the NSF/DDN NIC is
the authority for the entire space rooted in .IN-ADDR.ARPA. in the
v4 Internet, while in the new Internet it holds the authority only
for the AD 0.0.192.#. (Plus, of course, any other ADs assigned to it
over time.)
8. Conversion between version 4 and version 7
As noted in the description of datagram format, it is possible to
provide a mostly-transparent bridge between version 4 and version 7.
This discusses TCP and ICMP at the session/transport layer; UDP is a
subset of the TCP conversion. Most protocols at this layer will
probably need no translation; however it will probably be necessary
to specify exactly which will have translations done.
New protocols at the session/transport layer defined over IPv7 should
have protocol numbers greater than 255, and will not be translated to
IPv4.
Most of the translations should consist of copying various fields,
verifying fixed values in the datagram being translated, and setting
fixed values in the datagram being produced. In general, the
checksum must be verified first, and then a new checksum computed for
the generated datagram.
8.1 Version 4 IP address extension option
A new option is defined for IP version 4, to carry the extended
addresses of IPv7. This will be particularily useful in the initial
testing of IPv7, during a time when most of the fabric of the
internet is IPv4. An IPv7 host will be able to connect to another
IPv7 host anywhere in the internet even though most of the paths and
routers are IPv4, and still use the full addressing. This will
continue to work until non-unique network numbers are assigned, by
which time most of the infrastructure should be IPv7.
8.1.1 Option format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type (147) | length = 10 | source IPv7 AD number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | src 7th octet | destination IPv7 AD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number ... | dst 7th octet |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The source and destination are in IPv4 order (source first), for
consistancy. The type code is 147.
8.2 Fragmented datagrams
Datagrams that have been fragmented must be reassembled by the
converting host or router before conversion. Where the conversion is
being done by the destination host (i.e., the case of a v7 host
receiving v4 datagrams), this is similar to the present fragmentation
model.
When it is being done by an intermediate router (acting as an
internetwork layer gateway) the router should use all of source,
destination, and datagram ID for identification of IPv4 fragments;
note that destination is used implicitly in the usual reassembly at
the destination. When reassembling an IPv7 datagram, the 128 bit
fragment ID is used as usual.
If the fragments take different paths through the net, and arrive at
different conversion points, the datagram is lost.
8.3 Where does the conversion happen?
The objective of conversion is to be able to upgrade systems, both
hosts and routers, in whatever order desired by their owners.
Organizations must be able to upgrade any given system without
reconfiguration or modification of any other; and IPv4 hosts must be
able to interoperate essentially forever. (IPv4 routers will
probably be effectively eliminated at some point, except where they
exist in their own remote or isolated corners.)
Each TCP/IP v7 system, whether host or router, must be able to
recognize adjacent systems in the topology that are (only) v4, and
call the appropriate conversion routine just before sending the
datagram.
Digression: I believe v7 hosts will get much better performance by
doing everything internally in v7, and using conversion to filter
datagrams when necessary. This keeps the usual code path simple,
with only a "hook" right after receiving to convert incoming IPv4
datagrams, and just before sending to convert to IPv4. Routers may
prefer to keep datagrams in their incoming version, at least until
after the routing decision is made, and then doing the conversion
only if necessary. In either case, this is an implementation
specific decision.
It must be noted that any forwarding system may convert datagrams to
IPv7, then back to IPv4, even if that loses information such as
unknown options. The reverse is not acceptable: a system that
receives an IPv7 datagram should not convert it to IPv4, then back to
IPv7 on forwarding.
The preferred method for identifying which hosts require conversion
is to ARP first for the IPv7 address, and then again if no response
is received, for the IPv4 address. The reservation of ADs out of the
v4 network number space is useful again here, protecting hosts that
fail to properly use the ARP address length fields.
On networks where ARP is not normally used, the method is to assume
that a remote system is v7. If an IPv7 datagram is received from it,
the assumption is confirmed. If, after a short time, no IPv7
datagram is received, a v7 ICMP echo is sent. If a reply is received
(in either version) the assumption is confirmed.
If no reply is recieved, the remote system is assumed not to
understand IPv7, and datagrams are converted to IPv4 just before
transmitting them.
Implementations should also provide for explicit configuration where
desired.
8.4 Hybrid IPv4 systems
In the course of implementing IPv7, especially in constrained
environments such as small terminal servers, it may be useful to
implement the IPv4 address extension option directly, thereby
regaining universal connectivity.
This may also be a useful interim step for vendors not prepared to do
a major rework of an implementation; but it is important not to get
stalled in this step.
A hybrid IPv4 + address extension system does not have to implement
the conversion, it places this onus on its neighbors. It may itself
have an address with the subnet extension (7th byte) not equal to 1.
The implication of hybrid systems is that it is not valid to assume
that a host with a IPv7 address is a native IPv7 implementation.
8.5 Maximum segment size in TCP
It is probably advisable for IPv4 implementations to reduce the MSS
offered by a small amount where possible, to avoid fragmentation when
datagrams are converted to IPv7. This arises when IPv4 hosts are
communicating through an IPv7 infrastructure, with the same MTU as
the local networks of the hosts.
8.6 Forwarding and redirects
It may be important for a router to not send ICMP redirects when it
finds that it must do a conversion as part of forwarding the
datagram. In this case, the hosts involved may not be able to
interact directly. The IPv7 host could ignore the redirect, but this
results in an unpleasant level of noise as the sequence continually
recurs.
8.7 Design considerations
The conversion is designed to be fairly efficient in implementation,
especially on RISC architectures, assuming they can either do a
conditional move (or store), or do a short forward branch without
losing the instruction cache. The other conditional branches in the
body of the code are usually not-taken out to the failure/discard
case.
Handling options does involve a loop and a dispatch (case) operation.
The options in IPv4 are more difficult to handle, not being designed
for speed on a 32 bit aligned RISCish architecture, but they do not
occur often, except perhaps the address extension option.
For CISC machines, the same considerations will lead to fairly
efficient code.
The conversion code must be extremely careful to be robust when
presented with invalid input; in particular, it may be presented with
truncated transport layer headers when called recursively from the
ICMP conversion.
8.8 Conversion from IPv4 to IPv7
Individual steps in the conversion; the order is in most cases not
significant.
o Verify checksum.
o Verify fragment offset is 0, MF flag is 0.
o Verify version is 4.
o Extend TTL to 16 bits, multiply by 16.
o Set forward route identifier to 0.
o Set first 3 octets of destination to AD (i.e., 192.0.0), copy
first three octets from v4 address, set next octet to 1, copy
last octet. (This can be done with shift/mask/or operations
on most architectures.)
o Do the same translation on source address.
o Copy protocol, set high 8 bits to zero.
o If DF flag set, add Don't Fragment option.
o If Address Extension option present, copy ADs and subnet
extension numbers into destination and source.
o Convert other options where possible. If an unknown option
with copy-on-fragment is found, fail. If copy-on-fragment is
not set, ignore the option. I.e., the flag is (ab)used as an
indicator of whether the option is mandatory.
o Compute new IP header length.
o Convert session/transport layer (TCP) header and data.
o Compute new overall datagram length.
o Calculate IPv7 checksum.
8.9 Conversion from IPv7 to IPv4
The steps to convert IPv7 to IPv4 follow. Note that the converting
router or host is partly in the role of destination host; it checks
both bits of class in IP options, and (as in the other direction)
must reassemble fragmented datagrams.
o Verify checksum.
o Verify version is 7
o Set type-of-service to 0 (there may be an option defined,
that will be handled later).
o If length is greater than (about) 65563, fail. (That number
is not a typographical error. Note that the IPv7+TCPv7
headers add up to 28 bytes more than the corresponding v4
headers in the usual case.) This check is only to avoid
useless work, the precise check is later.
o Generate an ID (using an ISN based sequence generator,
possibly also based on destination or source or both).
o Set flags and fragment field to 0.
o Divide TTL by 16, if zero, fail (send ICMP Time Exceeded).
If greater that 255, set to 255.
o If next layer protocol is greater than 255, fail. Else copy.
o Copy first 3 octets and 8th octet of destination to
destination address.
o Same for source address.
o Generate v4 address extension option. (If enabled; this
probably should be a configuration option, should default to
on.)
o Process v7 options. If any unknown options of class not 0
found, fail.
o If Don't Fragment option found, set DF flag.
o If Don't Convert option found, fail.
o Convert other options where possible, or fail.
o Compute new IP header length. This may fail (too large),
fail conversion if so.
o Convert session/transport layer (e.g., TCP).
o Compute new overall datagram length. If greater than 65535,
fail.
o Compute IPv4 checksum.
8.10 Conversion from TCPv4 to TCPv7
o Subtract header words from v4 checksum. (Note that this is
actually done with one's complement addition.)
o Copy flags (except for Urgent).
o If source port is less than 32768 (a sign condition test will
suffice on most architectures), copy it. If equal or
greater, add 65536.
o Same operation on destination port.
o Copy sequence to low 32 bits, set high to 0.
o Copy acknowledgement to low 32 bits, set high to 0.
o Copy window. (The TCPv4 performance extension [RFC1323]
window-scale cannot be used, as it would require state; we
use the basic window offered.)
o Add 32 bit rollover option.
o Convert maximum segment size option if present.
o Compute data offset and copy data.
o Add header words into saved checksum. It is important not to
recompute the checksum over the data; it must remain an
end-to-end checksum.
o Return to IP layer conversion.
8.11 Conversion from TCPv7 to TCPv4
o Subtract header from v7 checksum.
o If source port is greater than 65535, subtract 65536. If
result is still greater than 65535, fail. (Send ICMP
conversion failed/port conversion out of range. The sending
host may then reset its port number generator to 98304.)
o Same translation for destination port.
o Copy low 32 bits of sequence number.
o If A bit set, copy low 32 bits of acknowledgement.
o Copy flags.
o If window is greater than 61440, set it to 24576. If less,
copy it unchanged. (Rationale for the 24K figure: this has
been found to be a good default for IPv4 hosts. If the IPv7
host is offering a very large window, the IPv4 host probably
isn't prepared to play at that level.)
o Process options. If 32 Bit Rollover is not present, and A
flag is set, fail. (Send ICMP conversion failed/32 bit
Rollover missing.)
o If Urgent is present, compute offset. If in segment, set U
flag and offset field. If not, ignore.
o Convert Maximum Segment Size option. If greater than 16384,
set to 16384.
o Compute new data offset.
o Add header words into v4 checksum.
o Return to IP layer conversion.
8.12 ICMP conversion
ICMP messages are converted by copying the type and code into the new
packet, and copying the other type-specific fields directly.
If the message contains an encapsulated, and usually truncated, IP
datagram, the conversion routine is called recursively to translate
it as far as possible. There are some special considerations:
o The encapsulated datagram is less likely to be valid, given
that it did generate an error of some kind.
o The conversion should attempt to complete all fields
available, even if some would cause failures in the general
case. Note, in particular, that in the course of converting
a datagram, when a failure occurs, an ICMP message
(conversion failed) is sent; this message itself may
immediately require conversion. Part of that conversion will
involve converting the original datagram.
o Conditions such as overall datagram length too large are not
checked.
o The AD and subnet byte assumed in the nested conversion may
not be sensible if the IPv4 address extension option is not
present and the datagram has strayed from the expected AD.
(Not unlikely, given that we know a priori that some error
occured.)
o The conversion must be very sure not to make another
recursive call if the nested datagram is an ICMP message.
(This should not occur, but obviously may.)
o It is probably impossible to generate a correct transport
layer checksum in the nested datagram. The conversion may
prefer to just zero the checksum field. Likewise, validating
the original checksum is pointless.
It may be best in a given implementation to have a separate code path
for the nested conversion, that handles these issues out of the
optimized usual path.
9. Postscript
The present version of TCP/IP has been a success partly by accident,
for reasons that weren't really designed in. Perhaps the most
significant is the low level of network integration required to make
it work.
We must be careful to retain the successful ingredients, even where
we may be unaware of them. Tread lightly, and use all that we have
learned, especially about not changing things that work.
This document has described a fairly conservative step forward, with
clear extensibility for future developments, but without jumping into
the abyss.
10. References
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC768,
USC/Information Sciences Institute, August 1980.
[RFC791] Postel, J., "Internet Protocol - DARPA Internet Program
Protocol Specification", STD 5, RFC791, DARPA,
September 1981.
[RFC792] Postel, J., "Internet Control Message Protocol -
DARPA Internet Program Protocol Specification"
STD 5, RFC792, USC/Information Sciences Institute,
September 1981.
[RFC793] Postel, J., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", STD 7, RFC793,
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", RFC1323, 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", RFC1335, University College London,
May 1992.
[RFC1338] Fuller, V., Li, T., Yu, J., and K. Varadhan,
"Supernetting: an Address Assignment and Aggregation
Strategy", RFC1338, BARRNet, cicso, Merit, OARnet,
June 1992.
[RFC1347] Callon, R., "TCP and UDP with Bigger Addresses (TUBA),
A Simple Proposal for Internet Addressing and Routing",
RFC1347, DEC, June 1992.
[RFC1476] Ullmann, R., "RAP: Internet Route Access Protocol",
RFC1476, Process Software Corporation, June 1993.
[RFC1379] Braden, R., "Extending TCP for Transactions -- Concepts",
RFC1379, USC/Information Sciences Institute,
November 1992.
11. Security Considerations
Security issues are not discussed in this memo.
12. Author's Address
Robert Ullmann
Process Software Corporation
959 Concord Street
Framingham, MA 01701
USA
Phone: +1 508 879 6994 x226
Email: Ariel@Process.COM