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 cryptographicShow full document text