 source,
destination, and datagram ID for identification of IPv4 fragments;

Ullmann                                                        [Page 26]

RFC 1475                         TP/IX                         June 1993

note that destination is used implicitly in the usual reassembly at
the destination.  When reassembling an IPv7 datagram, the 128 bit
fragment ID is used as usual.

If the fragments take different paths through the net, and arrive at
different conversion points, the datagram is lost.

8.3  Where does the conversion happen?

The objective of conversion is to be able to upgrade systems, both
hosts and routers, in whatever order desired by their owners.
Organizations must be able to upgrade any given system without
reconfiguration or modification of any other; and IPv4 hosts must be
able to interoperate essentially forever.  (IPv4 routers will
probably be effectively eliminated at some point, except where they
exist in their own remote or isolated corners.)

Each TCP/IP v7 system, whether host or router, must be able to
recognize adjacent systems in the topology that are (only) v4, and
call the appropriate conversion routine just before sending the
datagram.

Digression:  I believe v7 hosts will get much better performance by
doing everything internally in v7, and using conversion to filter
datagrams when necessary.  This keeps the usual code path simple,
with only a "hook" right after receiving to convert incoming IPv4
datagrams, and just before sending to convert to IPv4.  Routers may
prefer to keep datagrams in their incoming version, at least until
after the routing decision is made, and then doing the conversion
only if necessary.  In either case, this is an implementation
specific decision.

It must be noted that any forwarding system may convert datagrams to
IPv7, then back to IPv4, even if that loses information such as
unknown options.  The reverse is not acceptable:  a system that
receives an IPv7 datagram should not convert it to IPv4, then back to
IPv7 on forwarding.

The preferred method for identifying which hosts require conversion
is to ARP first for the IPv7 address, and then again if no response
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

Ullmann                                                        [Page 27]

RFC 1475                         TP/IX                         June 1993

(in either version) the assumption is confirmed.

If no reply is recieved, the remote system is assumed not to
understand IPv7, and datagrams are converted to IPv4 just before
transmitting them.

Implementations should also provide for explicit configuration where
desired.

8.4  Hybrid IPv4 systems

In the course of implementing IPv7, especially in constrained
environments such as small terminal servers, it may be useful to
implement the IPv4 address extension option directly, thereby
regaining universal connectivity.

This may also be a useful interim step for vendors not prepared to do
a major rework of an implementation; but it is important not to get
stalled in this step.

A hybrid IPv4 + address extension system does not have to implement
the conversion, it places this onus on its neighbors.  It may itself
have an address with the subnet extension (7th byte) not equal to 1.

The implication of hybrid systems is that it is not valid to assume
that a host with a IPv7 address is a native IPv7 implementation.

8.5  Maximum segment size in TCP

It is probably advisable for IPv4 implementations to reduce the MSS
offered by a small amount where possible, to avoid fragmentation when
datagrams are converted to IPv7.  This arises when IPv4 hosts are
communicating through an IPv7 infrastructure, with the same MTU as
the local networks of the hosts.

8.6  Forwarding and redirects

It may be important for a router to not send ICMP redirects when it
finds that it must do a conversion as part of forwarding the
datagram.  In this case, the hosts involved may not be able to
interact directly.  The IPv7 host could ignore the redirect, but this
results in an unpleasant level of noise as the sequence continually
recurs.

8.7  Design considerations

The conversion is designed to be fairly efficient in implementation,
especially on RISC architectures, assuming they can either do a

Ullmann                                                        [Page 28]

RFC 1475                         TP/IX                         June 1993

conditional move (or store), or do a short forward branch without
losing the instruction cache.  The other conditional branches in the
body of the code are usually not-taken out to the failure/discard
case.

Handling options does involve a loop and a dispatch (case) operation.
The options in IPv4 are more difficult to handle, not being designed
for speed on a 32 bit aligned RISCish architecture, but they do not
occur often, except perhaps the address extension option.

For CISC machines, the same considerations will lead to fairly
efficient code.

The conversion code must be extremely careful to be robust when
presented with invalid input; in particular, it may be presented with
truncated transport layer headers when called recursively from the
ICMP conversion.

8.8  Conversion from IPv4 to IPv7

Individual steps in the conversion; the order is in most cases not
significant.

o  Verify checksum.

o  Verify fragment offset is 0, MF flag is 0.

o  Verify version is 4.

o  Extend TTL to 16 bits, multiply by 16.

o  Set forward route identifier to 0.

o  Set first 3 octets of destination to AD (i.e., 192.0.0), copy
first three octets from v4 address, set next octet to 1, copy
last octet.  (This can be done with shift/mask/or operations
on most architectures.)

o  Do the same translation on source address.

o  Copy protocol, set high 8 bits to zero.

o  If DF flag set, add Don't Fragment option.

extension numbers into destination and source.

o  Convert other options where possible.  If an unknown option

Ullmann                                                        [Page 29]

RFC 1475                         TP/IX                         June 1993

with copy-on-fragment is found, fail.  If copy-on-fragment is
not set, ignore the option.  I.e., the flag is (ab)used as an
indicator of whether the option is mandatory.

o  Compute new IP header length.

o  Convert session/transport layer (TCP) header and data.

o  Compute new overall datagram length.

o  Calculate IPv7 checksum.

8.9  Conversion from IPv7 to IPv4

The steps to convert IPv7 to IPv4 follow.  Note that the converting
router or host is partly in the role of destination host; it checks
both bits of class in IP options, and (as in the other direction)
must reassemble fragmented datagrams.

o  Verify checksum.

o  Verify version is 7

o  Set type-of-service to 0 (there may be an option defined,
that will be handled later).

o  If length is greater than (about) 65563, fail.  (That number
is not a typographical error.  Note that the IPv7+TCPv7
headers 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

o  Generate v4 address extension option.  (If enabled; this

Ullmann                                                        [Page 30]

RFC 1475                         TP/IX                         June 1993

probably should be a configuration option, should default to
on.)

o  Process v7 options.  If any unknown options of class not 0
found, fail.

o  If Don't Fragment option found, set DF flag.

o  If Don't Convert option found, fail.

o  Convert other options where possible, or fail.

o  Compute new IP header length.  This may fail (too large),
fail conversion if so.

o  Convert session/transport layer (e.