rfc-7343

An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)

J. Laganier, F. Dupont
date2014-09 streamIETF areaint wghip statusPROPOSED STANDARD pages14 canonicalhttps://www.rfc-editor.org/rfc/rfc7343 doi10.17487/RFC7343
This document specifies an updated Overlay Routable Cryptographic Hash Identifiers (ORCHID) format that obsoletes that in RFC 4843. These identifiers are intended to be used as endpoint identifiers at applications and Application Programming Interfaces (APIs) and not as identifiers for network location at the IP layer, i.e., locators. They are designed to appear as application-layer entities and at the existing IPv6 APIs, but they should not appear in actual IPv6 headers. To make them more like regular IPv6 addresses, they are expected to be routable at an overlay level. Consequently, while they are considered non-routable addresses from the IPv6-layer perspective, all existing IPv6 applications are expected to be able to use them in a manner compatible with current IPv6 addresses. The Overlay Routable Cryptographic Hash Identifiers originally defined in RFC 4843 lacked a mechanism for cryptographic algorithm agility. The updated ORCHID format specified in this document removes this limitation by encoding, in the identifier itself, an index to the suite of cryptographic algorithms in use.

obsoletes

updated by

Extracted elements (20)

design-rationale §4

All bits beyond the 28-bit prefix and 4-bit OGA ID are used as hash output, maximizing hash length. The Context Identifier is included only as hash input (not in the ORCHID itself) to keep more bits available for the hash, trading direct context inference for longer hash security.

ip, crypto

design-rationale §1.1

ORCHIDs are designed to be used at existing IPv6 APIs without requiring application changes. A dedicated prefix distinguishes them from regular IPv6 addresses at upper layers while making it trivial to block them at the IP layer, enabling incremental deployment of overlay protocols like HIP.

ip

design-rationale §1.1

ORCHIDv2 introduces a new 28-bit prefix (2001:20::/28) instead of reusing the RFC 4843 experimental prefix because the updated format (adding the OGA ID field) is not backward compatible with ORCHIDv1, and the old prefix was returned to IANA in March 2014.

ip

design-rationale §5

The OGA ID namespace (4 bits, 16 values) is kept per-Context-ID rather than globally to avoid rapid exhaustion of the small namespace, allowing different applications to define their own hash function registries independently.

ip, crypto

interoperability-note §6

Context IDs share the namespace introduced for CGA Type Tags (RFC 3972). New values are allocated First Come, First Served per RFC 3972 §8, but no IANA action is required for individual allocations.

ip, registry

interoperability-note §2

ORCHIDs are allocated under the IPv6 global unicast address block and are indistinguishable from global unicast addresses by prefix inspection alone. However, they do not conform to the IPv6 global unicast address format (RFC 4291 §2.5.4) because they lack a standard 64-bit Interface ID.

ip

interoperability-note §1

ORCHIDs should not appear in actual IPv6 headers; they are intended for use only at application and API layers between consenting hosts, and their non-routability at the IP layer is a deliberate design property.

ip

normative-requirement §5 MUST

Each ORCHID-generating method MUST utilize a mechanism ensuring that input bitstrings are either unique or statistically unique within their context, for example by including a counter, a pseudorandom number of at least 96 bits of entropy, or a randomly generated public key.

ip, crypto, security

normative-requirement §5 MUST

For a given Context ID, all mechanisms using ORCHIDs MUST use exactly the same mechanism for generating an ORCHID from the input bitstring, to avoid bidding-down attacks where a weaker hash function could be used to forge ORCHIDs valid for the same Context ID.

ip, crypto, security

normative-requirement §3 MUST NOT

Router software MUST NOT include any special handling code for ORCHIDs. Non-routability of ORCHIDs, if implemented, must be achieved via configuration (e.g., an ACL entry) rather than hardwired code.

ip

normative-requirement §3 MAY

Routers MAY be configured not to forward any packets containing an ORCHID as a source or destination address. If the destination is an ORCHID but the source is a valid unicast address, routers MAY be configured to generate an ICMP Destination Unreachable, Administratively Prohibited message.

ip

protocol-element §2

The Context Identifier is a randomly generated 128-bit value defining the usage context and the hash function for ORCHID generation. It is allocated from the CGA Type Tags namespace (RFC 3972) on a First Come, First Served basis and is not encoded in the ORCHID itself.

ip, crypto, registry

protocol-element §2

The OGA ID is a 4-bit field embedded in the ORCHID (bits 29–32) that identifies the hash function in use within a specific usage context. It provides cryptographic algorithm agility, supporting up to 16 distinct values per Context ID.

ip, crypto

protocol-element §2

The ORCHID Generation Algorithm (OGA) takes an arbitrary input bitstring and a 128-bit Context Identifier, concatenates them, hashes the result with a context-specified hash function, and extracts the middle 96 bits. The 4-bit OGA ID encodes which hash function was used.

ip, crypto

registry §6

IANA allocated the IPv6 prefix 2001:20::/28 for ORCHIDv2 from the IANA IPv6 Special Purpose Address Block (2001:0000::/23). The allocation is marked Source: True, Destination: True, Forwardable: True, Global: True, with no termination date.

ip, registry

security-consideration §5

Allowing multiple hash functions to produce ORCHIDs valid for the same Context ID without explicit encoding would enable bidding-down attacks: an attacker could exploit a weaker function to attack identifiers generated with a stronger one. The per-Context-ID OGA ID registry prevents this.

ip, crypto, security

security-consideration §5

Hash truncation to 96 bits during ORCHID generation is analogous to RFC 6920 ('Naming Things with Hashes'); the security considerations of RFC 6920 regarding hash truncation apply to ORCHIDv2 generation as well.

ip, crypto, security

security-consideration §5

The security of ORCHIDs depends on the second-preimage resistance of the underlying hash function. Using the shortest possible prefix maximizes hash output bits, directly supporting collision resistance. If the hash function is weakened, ORCHID bindings can be forged.

ip, crypto, security

wire-format §2

An ORCHID is a 128-bit identifier composed of: a 28-bit prefix (2001:20::/28), a 4-bit OGA ID, and a 96-bit hash output extracted from the middle of a cryptographic hash of (Context ID | Input bitstring).

ip, crypto

wire-format §2

The Encode_96() function extracts the middle 96 bits from the hash function output, discarding the leading and trailing bits. This is the portion of the hash embedded in the ORCHID.

ip, crypto