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.