An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)
RFC 7343
| Document | Type |
RFC - Proposed Standard
(September 2014; No errata)
Obsoletes RFC 4843
|
|
|---|---|---|---|
| Authors | Julien Laganier , Francis Dupont | ||
| Last updated | 2018-12-20 | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Gonzalo Camarillo | ||
| Shepherd write-up | Show (last changed 2014-03-20) | ||
| IESG | IESG state | RFC 7343 (Proposed Standard) | |
| Consensus Boilerplate | Yes | ||
| Telechat date | |||
| Responsible AD | Ted Lemon | ||
| Send notices to | (None) | ||
| IANA | IANA review state | IANA OK - Actions Needed | |
| IANA action state | RFC-Ed-Ack | ||
Internet Engineering Task Force (IETF) J. Laganier
Request for Comments: 7343 Luminate Wireless, Inc.
Obsoletes: 4843 F. Dupont
Category: Standards Track Internet Systems Consortium
ISSN: 2070-1721 September 2014
An IPv6 Prefix for
Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)
Abstract
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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7343.
Laganier & Dupont Standards Track [Page 1]
RFC 7343 ORCHIDv2 September 2014
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Rationale and Intent . . . . . . . . . . . . . . . . . . 3
1.2. ORCHID Properties . . . . . . . . . . . . . . . . . . . . 4
1.3. Expected Use of ORCHIDs . . . . . . . . . . . . . . . . . 5
1.4. Action Plan . . . . . . . . . . . . . . . . . . . . . . . 5
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Cryptographic Hash Identifier Construction . . . . . . . . . 5
3. Routing and Forwarding Considerations . . . . . . . . . . . . 7
4. Design Choices . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Collision Considerations . . . . . . . . . . . . . . 13
Appendix B. Changes from RFC 4843 . . . . . . . . . . . . . . . 13
1. Introduction
This document introduces Overlay Routable Cryptographic Hash
Identifiers (ORCHID), a new class of identifiers that are like IP
addresses. These identifiers are intended to be globally unique in a
statistical sense (see Appendix A), non-routable at the IP layer, and
routable at some overlay layer. The identifiers are securely bound,
via a secure hash function, to the concatenation of an input
bitstring and a context tag. Typically, but not necessarily, the
input bitstring will include a suitably encoded public cryptographic
Show full document text