Shim6: Level 3 Multihoming Shim Protocol for IPv6
Extracted elements (31)
Context establishment is intentionally deferred: the shim does not create a context until a heuristic (e.g., more than 50 packets exchanged or a timer expiry during active exchange) is met. This avoids the overhead of a 4-way handshake for short-lived communications that are unlikely to benefit from multihoming failover.
IP multicast is explicitly excluded from Shim6 shim processing because multicast routing depends on the IP source address for RPF checks and all receivers would need the ULID-to-locator mapping, making transparent remapping impractical. RTP-based protocols are naturally accommodated since RTP has its own explicit SSRC identifier.
The Context Tag is 47 bits — the largest value that fits in an 8-octet extension header while reserving one bit (the P bit) to distinguish Shim6 Payload Extension headers from Shim6 control messages, so that both can share a single IP protocol number (140) and pass through firewalls with a single rule.
The Shim6 checksum covers only the Shim6 header itself, with no pseudo-header (unlike ICMPv6). Including source/destination addresses in a pseudo-header would invalidate the checksum whenever locators change, defeating the locator-agility goal.
Shim6 assumes there are no IPv6-to-IPv6 NATs on any path: both ends must be able to exchange their own IPv6 addresses and have those addresses be meaningful to the peer. NAT would break both the locator-exchange mechanism and the HBA/CGA verification of the locator set.
The Shim6 layer is placed between the IP endpoint sublayer (handling fragmentation/reassembly) and the IP routing sublayer. This ensures that fragment reassembly is robust even when different fragments of the same datagram arrive via different source locators due to broken multipath routing.
Any communication using a ULID MUST be terminated when the ULID becomes invalid (i.e., when its underlying prefix becomes invalid). This prevents the prefix from being reassigned to another site while it is still in use via a different locator.
Shim6 signaling packets MUST NOT exceed 1280 bytes, including the IPv6 header and any intermediate headers. Implementations may omit part of the locator address information or split information across multiple messages to meet this limit.
The Responder Validator option MUST be included in every R1 message. It MUST also be included in I2 and I2bis messages, generated by copying the Responder Validator received in the preceding R1 or R1bis, enabling the responder to confirm that the I2/I2bis parameters match those in the original I1.
When a Locator List is included in I2, R2, or I2bis, the CGA Parameter Data Structure option MUST also be included so the receiver can verify the locators. The CGA Signature option MUST additionally be included when any locator in the list uses CGA rather than HBA for verification.
When the IPv6 source and destination addresses in a packet's header do not match the ULID pair, the ULID Pair option MUST be included in I1, I2, or I2bis messages. This occurs notably during context recovery when a different locator pair is used to transport the context-establishment exchange.
A ULID-pair context is the state the shim maintains between a pair of upper-layer identifiers, identified by a pair of Context Tags (one per direction) plus an optional Forked Instance Identifier. It tracks the current locator pair and the peer's locator set.
Context forking allows ULP-aware applications to use multiple locator pairs for a single ULID pair. Forked contexts are distinguished by a non-zero 32-bit Forked Instance Identifier (FII); the default context has FII zero. Forking is unidirectional — both directions must be set up independently by the ULP.
Context Tags are 47-bit numbers allocated by each end of a context, used to demultiplex both Shim6 Payload Extension headers and control messages. Because Payload Extension headers are demultiplexed without examining locators, a receiver's Context Tags must be unique across all of its contexts.
Shim6 is a layer 3 multihoming shim for IPv6 that operates below transport protocols. It maintains per-ULID-pair context state and transparently remaps IPv6 address fields between ULIDs (used by upper layers) and locators (used for routing), with no impact on ULP checksums or connection identification.
The upper-layer identifier (ULID) is the IPv6 address selected by default address selection during initial contact with a peer. It is used for pseudo-header checksum computation and connection identification; it is always one member of the host's locator set and requires no separate name space.
IANA assigned IP protocol number 140 to Shim6. All Shim6 messages — both the Payload Extension header and control messages — use this protocol number, allowing a single firewall rule to permit all Shim6 traffic.
IANA created the Shim6 message type registry with initial values: I1=1, R1=2, I2=3, R2=4, R1bis=5, I2bis=6, Update Request=64, Update Acknowledgement=65, Keepalive=66, Probe=67, Error=68. Types 0–63 do not trigger R1bis on missing context; types 64–127 do.
A Reachability Probe+Reply exchange (specified in RFC 5534) MUST be completed before any new locator is used as a destination. This prevents third-party flooding attacks in which an attacker causes a victim's traffic stream to be redirected to an arbitrary address.
Context Tags protect Shim6 against off-path attackers: every post-establishment control message carries the receiver's Context Tag, requiring an attacker to observe the path to forge a message. Additionally, the I1 message creates no state on the responder; a complete 3-way exchange (I1, R1, I2) must succeed before the responder allocates context state, limiting state-exhaustion DoS impact.
Shim6 uses Hash-Based Addresses (HBA, RFC 5535) and/or Cryptographically Generated Addresses (CGA, RFC 3972) to prevent redirection attacks. When HBAs are used, all addresses included in Shim6 (as locator or ULID) must belong to the same HBA set. For CGA, only the ULID needs to be a CGA; additional locators need not be.
A ULID-pair context transitions through: no state (IDLE), I1-SENT (initiator awaiting R1), I2-SENT (initiator awaiting R2), and ESTABLISHED. When a peer loses state, the R1bis/I2bis exchange re-enters ESTABLISHED from a lost-context condition. Teardown is unilateral; context-recovery messages signal missing state to the peer.
The common Shim6 control header contains: Next Header (always 59/NO_NXT_HDR), Hdr Ext Len, P=0, 7-bit Type (0–63 do not trigger R1bis on missing context; 64–127 do), S=0 (distinguishes Shim6 from HIP), and a 16-bit one's-complement checksum over the Shim6 header only with no pseudo-header.
The common Shim6 message header starts with 8-bit Next Header, 8-bit Hdr Ext Len (in 8-octet units, excluding first 8 octets), and a 1-bit P flag. P=1 identifies a Shim6 Payload Extension header; P=0 identifies a control message, allowing both types to share IP protocol number 140.
The I1 message (Type=1) carries a 47-bit Initiator Context Tag and a 32-bit random Initiator Nonce. The ULID Pair option MUST be included when the packet's IPv6 addresses do not match the ULID pair; the Forked Instance Identifier option MUST be included when forking an existing context.
The I2 message (Type=3, minimum 24 octets) carries a 47-bit Initiator Context Tag, a new 32-bit Initiator Nonce, the Responder Nonce copied from R1, and 32-bit Reserved2. The Responder Validator option MUST be copied from R1; a Locator List, CGA PDS, and CGA Signature may optionally be included.
The I2bis message (Type=6, minimum 32 octets) carries a 47-bit Initiator Context Tag, 32-bit Initiator Nonce, 32-bit Responder Nonce (from R1bis), 49-bit Reserved2, and the 47-bit Packet Context Tag copied from R1bis. It re-establishes a lost context without a full I1/R1 round trip.
The R1 message (Type=2) carries the 32-bit Initiator Nonce echoed from I1 and a new 32-bit Responder Nonce. The Responder Validator option MUST be included. The responder creates no per-initiator state when sending R1.
The R1bis message (Type=5) is generated when a packet arrives referencing a non-existent context (Shim6 Payload Extension header or type-64–127 control message). It carries the 47-bit Packet Context Tag from the triggering packet and a 32-bit Responder Nonce, plus an optional Responder Validator.
The R2 message (Type=4) carries a 47-bit Responder Context Tag and the 32-bit Initiator Nonce copied from I2. It completes context establishment and is also sent when concurrent I1 messages cross in flight. Optionally carries a Locator List with CGA/HBA verification material.
The Shim6 Payload Extension Header is exactly 8 octets: Next Header (8 bits), Hdr Ext Len=0 (8 bits), P=1 (1 bit), and Receiver Context Tag (47-bit unsigned integer). It is included only when the current locator pair differs from the ULID pair.