This was the IPvB (nee original IPv6) *translation* header.
Note that it was cleverly designed to translate from IPv4.
Most of the fields are in exactly the same place. Especially,
the 32-bit Source IP address is in exactly the same place, hoping
that filters could operate on both stacks.
We were implementing on then new i386 32-bit machines, but also
tested on i286 16-bit machines. We knew there would be 64-bit
machines (such as the DEC Alpha), so it was carefully designed
for multiple environments.
3.1. Translation Header Format
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
>Version> IHV | Service | Minimal Length |
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
> Identification | Next Header | Hop Limit |
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
> >
+ Source +
> >
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
> >
+ Destination +
> >
+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+‐+
Version 4 bits: constant 0xB (1011 binary).
Indicates the format of the internet header. This
document describes version 11.
Note:
The IPv4 Version is 0x4 (0100
binary). IPvB is the complement
(binary inverse) of IPv4.
Although this field is always
present, and may be used internally
by systems, different headers MUST
be distinguished at the link layer.
Some implementations of IPv4 failed
to correctly check (or set) the
IPv4 Version.
IHV 4 bits. Internet Header Variant.
0x0
Invalid; MUST be silently discarded.
0x6
IPv4 header translation. The least significant
bit here reflects the most significant IPv4 Flags
bit, as some systems used that bit in the past.
(See "IPvB Translation for IPv4" [].)
0x8
Flow header (see below).
0xA
Reserved for future use.
The IPvB header is a fixed minimum size. However,
the Version field is a scarce resource Therefore,
larger values are used for format variants,
transient indications, and other purposes.
Note:
For IPv4, this field was the
Internet Header Length (IHL) in
32‐bit words. The minimum value
for a matching IPvB header is 6
words.
Service 8 bits: default 0.
Contains the IPv4 Type of Service (ToS).
Minimal Length 16 bits: minimum 64 (bytes). Smaller values MUST be
silently discarded.
The length of the datagram, including internet
header(s) and payload data. All nodes must be
prepared to accept datagrams of up to 1480 octets.
It is recommended that hosts send datagrams larger
than 1480 octets only after assurance that the
destination is prepared to accept the larger
datagrams.
The number 1480 is selected to allow a reasonable
sized data block to be transmitted in addition to
the required header information, and to allow
typical lower‐layer encapsulations room for their
respective headers. Over time, memory limitations
have eased considerably, and there have been some
indications that a larger minimum datagram size
throughout the internet would be beneficial.
Note:
IPv4 has minimum required 576 and
maximum 65,535 octet datagrams.
Translation to IPv4 requires that
the IPvB limits are only applicable
to nodes indicating the presence of
IPvB. (See "IPvB Neighbor
Discovery" [] and "IPvB Translation
for IPv4" [].)
Identification 16 bits: default 0.
Assigned by the sender. Originally used in IPv4 to
aid in assembling the fragments of a datagram.
However, IPvB uses a Fragmentation Header instead,
and treats all IPv4 datagrams as Don’t Fragment
(DF).
Next Header 8 bits.
Identifies the type of header immediately following
this header. Uses the same values as the IPv4
Protocol field. (See [RFC‐1700] et seq.)
Hop Limit 8 bits: initially 255.
Indicates the maximum time the datagram is allowed
to remain in the internet routing system. The
intent is to cause undeliverable datagrams to be
discarded, and to bound the maximum datagram
lifetime. The time is measured in units of seconds,
but is only an upper bound on the time a datagram
may exist.
This field is modified in internet header
processing. Every node that routes the datagram
between interfaces MUST decrement the value by at
least one. For large bandwidth‐delay paths, the
value SHOULD decrease by more than one, and MAY
decrease by one for each anticipated second in
transit (including queuing delay) over the outgoing
interface.
If this field contains the value zero (0) before
sending, or some higher limit upon receipt as
configured for each protocol, then the datagram MUST
be discarded.
Note:
IPv4 defaults to an initial value
of 64 []. (See also "IPvB
Translation for IPv4" [].)
Security considerations require
that the initial value be well
known, so that protocol
implementations can detect the
number of hops from its source.
Source 64 bits.
The location of the node originating the datagram.
Note:
The least significant 32 bits are
aligned with the IPv4 Source field
to permit serendipitous comparisons
for network egress and ingress
filtering of both header versions
concurrently.
Destination 64 bits.
The location of the routing area where an interface
of the intended communication peer might be found.
The IPvB header maintains 64‐bit alignment. Together with an IPvB
Encapsulating Security Protocol (ESP), the header combination
maintains 128‐bit and 256‐bit alignment. Serendipitous alignment
allows simple loads and stores, instead of slower byte by byte
iterations.