doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc7343.txt b/doc/rfc/rfc7343.txt
new file mode 100644
index 0000000..61ef297
--- /dev/null
+++ b/doc/rfc/rfc7343.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+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
+   key.
+
+
+
+
+Laganier & Dupont            Standards Track                    [Page 2]
+
+RFC 7343                        ORCHIDv2                  September 2014
+
+
+1.1.  Rationale and Intent
+
+   These identifiers are expected to be used at the existing IPv6
+   Application Programming Interfaces (APIs) and application protocols
+   between consenting hosts.  They may be defined and used in different
+   contexts, suitable for different overlay protocols.  Examples of
+   these include Host Identity Tags (HITs) in the Host Identity Protocol
+   (HIP) [HIPv2] and Temporary Mobile Identifiers (TMIs) for Mobile IPv6
+   Privacy Extension [PRIVACYTEXT].
+
+   As these identifiers are expected to be used along with IPv6
+   addresses at both applications and APIs, coordination is desired to
+   make sure that an ORCHID is not inappropriately taken for a regular
+   IPv6 address and vice versa.  In practice, allocation of a separate
+   prefix for ORCHIDs seems to suffice, making them compatible with IPv6
+   addresses at the upper layers while simultaneously making it trivial
+   to prevent their use at the IP layer.
+
+   While being technically possible to use ORCHIDs between consenting
+   hosts without any coordination with the IETF and the IANA, the IETF
+   would consider such practice potentially dangerous.  A specific
+   danger would be realized if the IETF community later decided to use
+   the ORCHID prefix for some different purpose.  In that case, hosts
+   using the ORCHID prefix would be, for practical purposes, unable to
+   use the prefix for the other new purpose.  That would lead to partial
+   balkanization of the Internet, similar to what has happened as a
+   result of historical hijackings of IPv4 addresses that are not RFC
+   1918 [RFC1918] for private use.
+
+   The whole need for the proposed allocation grows from the desire to
+   be able to use ORCHIDs with existing applications and APIs.  This
+   desire leads to the potential conflict, mentioned above.  Resolving
+   the conflict requires the proposed allocation.
+
+   One can argue that the desire to use these kinds of identifiers via
+   existing APIs is architecturally wrong, and there is some truth in
+   that argument.  Indeed, it would be more desirable to introduce a new
+   API and update all applications to use identifiers, rather than
+   locators, via that new API.  That is exactly what we expect to happen
+   in the long run.
+
+   However, given the current state of the Internet, we do not consider
+   it viable to introduce any changes that, at once, require
+   applications to be rewritten and host stacks to be updated.  Rather
+   than that, we believe in piece-wise architectural changes that
+   require only one of the existing assets to be touched.  ORCHIDs are
+   designed to address this situation: to allow people to implement with
+   protocol stack extensions, such as secure overlay routing, HIP, or
+
+
+
+Laganier & Dupont            Standards Track                    [Page 3]
+
+RFC 7343                        ORCHIDv2                  September 2014
+
+
+   Mobile IP privacy extensions, without requiring them to update their
+   applications.  The goal is to facilitate large-scale deployments with
+   minimum user effort.
+
+   For example, at the time of this writing, there already exist HIP
+   implementations that run fully in user space, using the operating
+   system to divert a certain part of the IPv6 address space to a user-
+   level daemon for HIP processing.  In practical terms, these
+   implementations are already using a certain IPv6 prefix for
+   differentiating HIP identifiers from IPv6 addresses, allowing them
+   both to be used by the existing applications via the existing APIs.
+
+   The Overlay Routable Cryptographic Hash Identifiers originally
+   defined in [RFC4843] 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.
+
+   Because the updated ORCHIDv2 format is not backward compatible, IANA
+   has allocated a new 28-bit prefix out of the IANA IPv6 Special
+   Purpose Address Block, namely 2001:0000::/23, as per [RFC6890].  The
+   prefix that was temporarily allocated for the experimental ORCHID was
+   returned to IANA in March 2014 [RFC4843].
+
+1.2.  ORCHID Properties
+
+   ORCHIDs are designed to have the following properties:
+
+   o  Statistical uniqueness (see also Appendix A).
+
+   o  Secure binding to the input parameters used in their generation
+      (i.e., the Context Identifier and a bitstring).
+
+   o  Aggregation under a single IPv6 prefix.  Note that this is only
+      needed due to the coordination need as indicated above.  Without
+      such coordination need, the ORCHID namespace could potentially be
+      completely flat.
+
+   o  Non-routability at the IP layer, by design.
+
+   o  Routability at some overlay layer, making them, from an
+      application point of view, semantically similar to IPv6 addresses.
+
+   As mentioned above, ORCHIDs are intended to be generated and used in
+   different contexts, as suitable for different mechanisms and
+   protocols.  The Context Identifier is meant to be used to
+   differentiate between the different contexts; see Appendix A for a
+
+
+
+
+Laganier & Dupont            Standards Track                    [Page 4]
+
+RFC 7343                        ORCHIDv2                  September 2014
+
+
+   discussion of the related API issues implementation issues and
+   Section 4 for the design choices explaining why the Context
+   Identifiers are used.
+
+1.3.  Expected Use of ORCHIDs
+
+   Examples of identifiers and protocols that are expected to adopt the
+   ORCHID format include Host Identity Tags (HITs) in the Host Identity
+   Protocol [HIPv2] and the Temporary Mobile Identifiers (TMIs) in the
+   Simple Privacy Extension for Mobile IPv6 [PRIVACYTEXT].  The format
+   is designed to be extensible to allow other experimental proposals to
+   share the same namespace.
+
+1.4.  Action Plan
+
+   This document requests IANA to allocate a prefix out of the IPv6
+   addressing space for Overlay Routable Cryptographic Hash Identifiers.
+
+1.5.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Cryptographic Hash Identifier Construction
+
+   An ORCHID is generated using the ORCHID Generation Algorithm (OGA).
+   The algorithm takes a bitstring and a Context Identifier as input and
+   produces an ORCHID as output.  The hash function used in the ORCHID
+   Generation Algorithm is defined for each OGA identifier by the
+   specification for the respective usage context (e.g., HIPv2).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laganier & Dupont            Standards Track                    [Page 5]
+
+RFC 7343                        ORCHIDv2                  September 2014
+
+
+ Input      :=  any bitstring
+ OGA ID     :=  4-bit Orchid Generation Algorithm identifier
+ Hash Input :=  Context ID | Input
+ Hash       :=  Hash_function( Hash Input )
+ ORCHID     :=  Prefix | OGA ID | Encode_96( Hash )
+
+ where:
+
+ |               : Denotes concatenation of bitstrings
+
+ Input           : A bitstring that is unique or statistically unique
+                   within a given context.  The bitstring is intended
+                   to be associated with the to-be-created ORCHID in
+                   the given context.
+
+ Context ID      : A randomly generated value defining the expected
+                   usage context for the particular ORCHID and the
+                   hash function to be used for generation of ORCHIDs
+                   in this context.  These values are allocated out of
+                   the namespace introduced for Cryptographically
+                   Generated Addresses (CGA) Type Tags (see RFC 3972 and
+                   http://www.iana.org/assignments/cga-message-types).
+
+ OGA ID          : A 4-bit-long identifier for the Hash_function
+                   in use within the specific usage context.
+
+ Hash_function   : The one-way hash function (i.e., hash function
+                   with preimage resistance and second-preimage
+                   resistance) to be used as identified by the
+                   value for the OGA ID according document
+                   defining the context usage identified by the
+                   Context ID.  For example, version 2 of the
+                   HIP specification defines truncated SHA1 [RFC3174] as
+                   the hash function to be used to generate
+                   ORCHIDv2 in the HIPv2 protocol when the
+                   OGA ID is 3 [HIPv2].
+
+ Encode_96( )    : An extraction function in which output is obtained
+                   by extracting the middle 96-bit-long bitstring
+                   from the argument bitstring.
+
+ Prefix          : A constant 28-bit-long bitstring value
+                   (2001:20::/28).
+
+
+   To form an ORCHID, two pieces of input data are needed.  The first
+   piece can be any bitstring, but it is typically expected to contain a
+   public cryptographic key and some other data.  The second piece is a
+
+
+
+Laganier & Dupont            Standards Track                    [Page 6]
+
+RFC 7343                        ORCHIDv2                  September 2014
+
+
+   Context Identifier, which is a 128-bit-long datum, allocated as
+   specified in Section 6.  Each specific ORCHIDv2 application (such as
+   HIP HITs or MIP6 TMIs) is expected to allocate their own, specific
+   Context Identifier.
+
+   The input bitstring and Context Identifier are concatenated to form
+   an input datum, which is then fed to the cryptographic hash function
+   to be used for the value of the OGA identifier according to the
+   document defining the context usage identified by the Context ID.
+   The result of the hash function is processed by an encoding function,
+   resulting in a 96-bit-long value.  This value is prepended with the
+   concatenation of the 28-bit ORCHID prefix and the 4-bit OGA ID.  The
+   result is the ORCHID, a 128-bit-long bitstring that can be used at
+   the IPv6 APIs in hosts participating to the particular experiment.
+
+   The ORCHID prefix is allocated under the IPv6 global unicast address
+   block.  Hence, ORCHIDs are indistinguishable from IPv6 global unicast
+   addresses.  However, it should be noted that ORCHIDs do not conform
+   with the IPv6 global unicast address format defined in Section 2.5.4
+   of [RFC4291] since they do not have a 64-bit Interface ID formatted
+   as described in Section 2.5.1. of [RFC4291].
+
+3.  Routing and Forwarding Considerations
+
+   ORCHIDs are designed to serve as location-independent endpoint
+   identifiers rather than IP-layer locators.  Therefore, routers MAY be
+   configured not to forward any packets containing an ORCHID as a
+   source or a destination address.  If the destination address is an
+   ORCHID but the source address is a valid unicast source address,
+   routers MAY be configured to generate an ICMP Destination
+   Unreachable, Administratively Prohibited message.
+
+   ORCHIDs are not designed for use in IPv6 routing protocols, since
+   such routing protocols are based on the architectural definition of
+   IPv6 addresses.  Future non-IPv6 routing systems, such as overlay
+   routing systems, may be designed based on ORCHIDs.  Any such ORCHID-
+   based routing system is out of scope of this document.
+
+   Router software MUST NOT include any special handling code for
+   ORCHIDs.  In other words, the non-routability property of ORCHIDs, if
+   implemented, is to be implemented via configuration rather than by
+   hardwired software code, e.g., the ORCHID prefix can be blocked by a
+   simple configuration rule such as an Access Control List entry.
+
+
+
+
+
+
+
+
+Laganier & Dupont            Standards Track                    [Page 7]
+
+RFC 7343                        ORCHIDv2                  September 2014
+
+
+4.  Design Choices
+
+   The design of this namespace faces two competing forces:
+
+   o  As many bits as possible should be preserved for the hash result.
+
+   o  It should be possible to share the namespace between multiple
+      mechanisms.
+
+   The desire to have a long hash result requires that the prefix be as
+   short as possible and use few (if any) bits for additional encoding.
+   The present design takes this desire to the maximum: all the bits
+   beyond the prefix and the ORCHID Generation Algorithm Identifier are
+   used as hash output.  This leaves no bits in the ORCHID itself
+   available for identifying the context; however, the 4 bits used to
+   encode the ORCHID Generation Algorithm Identifier provides
+   cryptographic agility with respect to the hash function in use for a
+   given context (see Section 5).
+
+   The desire to allow multiple mechanisms to share the namespace has
+   been resolved by including the Context Identifier in the hash
+   function input.  While this does not allow the mechanism to be
+   directly inferred from an ORCHID, it allows one to verify that a
+   given input bitstring and ORCHID belong to a given context, with high
+   probability (but also see Section 5).
+
+5.  Security Considerations
+
+   ORCHIDs are designed to be securely bound to the Context ID and the
+   bitstring used as the input parameters during their generation.  To
+   provide this property, the ORCHID Generation Algorithm relies on the
+   second-preimage resistance (a.k.a. one-way) property of the hash
+   function used in the generation [RFC4270].  To have this property and
+   to avoid collisions, it is important that the allocated prefix is as
+   short as possible, leaving as many bits as possible for the hash
+   output.
+
+   For a given Context ID, all mechanisms using ORCHIDs MUST use exactly
+   the same mechanism for generating an ORCHID from the input bitstring.
+   Allowing different mechanisms, without explicitly encoding the
+   mechanism in the Context ID or the ORCHID itself, would allow
+   so-called bidding-down attacks.  That is, if multiple different hash
+   functions were allowed to construct ORCHIDs valid for the same
+   Context ID, and if one of the hash functions became insecure, that
+   would allow attacks against even those ORCHIDs valid for the same
+   Context ID that had been constructed using the other, still secure
+   hash functions.
+
+
+
+
+Laganier & Dupont            Standards Track                    [Page 8]
+
+RFC 7343                        ORCHIDv2                  September 2014
+
+
+   An identifier for the hash function to be used for the ORCHID
+   generation is encoded in the ORCHID itself, while the semantic for
+   the values taken by this identifier are defined separately for each
+   Context ID.  Therefore, the present design allows the use of
+   different hash functions per given Context ID for constructing
+   ORCHIDs from input bitstrings.  The intent is that the protocol or
+   application using an ORCHIDv2 allocates a Context ID for that use and
+   defines, within the scope of that Context ID, the registry for the
+   ORCHID Generation Algorithm (OGA) ID.  The rationale for this is to
+   allow different applications to use different hash functions that
+   best satisfy their specific requirements, such that the relatively
+   small OGA ID namespace (4 bits wide, i.e., 16 different values) does
+   not get exhausted too quickly.  If more secure hash functions are
+   later needed, newer values for the ORCHID Generation Algorithm can be
+   defined for the given Context ID.
+
+   In order to preserve a low enough probability of collisions (see
+   Appendix A), each method MUST utilize a mechanism that makes sure
+   that the distinct input bitstrings are either unique or statistically
+   unique within that context.  There are several possible methods to
+   ensure this; for example, one can include into the input bitstring a
+   globally maintained counter value, a pseudorandom number of
+   sufficient entropy (minimum 96 bits), or a randomly generated public
+   cryptographic key.  The Context ID makes sure that input bitstrings
+   from different contexts never overlap.  These together make sure that
+   the probability of collisions is determined only by the probability
+   of natural collisions in the hash space and is not increased by a
+   possibility of colliding input bitstrings.
+
+   The generation of an ORCHIDv2 identifier from an input bitstring
+   involves truncation of a hash output to construct a fixed-size
+   identifier in a fashion similar to the scheme specified in "Naming
+   Things with Hashes" [RFC6920].  Accordingly, the Security
+   Considerations of [RFC6920] pertaining to truncation of the hash
+   output during identifier generation are also applicable to ORCHIDv2
+   generation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laganier & Dupont            Standards Track                    [Page 9]
+
+RFC 7343                        ORCHIDv2                  September 2014
+
+
+6.  IANA Considerations
+
+   Because the updated ORCHIDv2 format is not backward compatible with
+   the earlier one, IANA has allocated a new 28-bit prefix out of the
+   IANA IPv6 Special Purpose Address Block, namely 2001:0000::/23, as
+   per [RFC6890].  The prefix that was temporarily allocated for the
+   experimental ORCHID was returned to IANA in March 2014 [RFC4843].
+   The registry information for the allocation is as follows:
+
+   o  Address Block: 2001:20::/28
+
+   o  Name: ORCHIDv2
+
+   o  RFC: RFC 7343
+
+   o  Allocation Date: 2014-07
+
+   o  Termination Date: N/A
+
+   o  Source: True
+
+   o  Destination: True
+
+   o  Forwardable: True
+
+   o  Global: True
+
+   o  Reserved-by-Protocol: False
+
+   The Context Identifier (or Context ID) is a randomly generated value
+   defining the usage context of an ORCHID and the hash function to be
+   used for generation of ORCHIDs in this context.  This document
+   defines no specific value.  The Context ID shares the namespace
+   introduced for CGA Type Tags.  Hence, defining new values follows the
+   rules of Section 8 of [RFC3972], i.e., First Come, First Served.
+   However, no IANA actions are required.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laganier & Dupont            Standards Track                   [Page 10]
+
+RFC 7343                        ORCHIDv2                  September 2014
+
+
+7.  Contributors
+
+   Pekka Nikander (pekka.nikander@nomadiclab.com) co-authored an
+   earlier, experimental version of this specification [RFC4843].
+
+8.  Acknowledgments
+
+   Special thanks to Geoff Huston for his sharp but constructive
+   critique during the development of this memo.  Tom Henderson helped
+   to clarify a number of issues.  This document has also been improved
+   by reviews, comments, and discussions originating from the IPv6,
+   Internet Area, and IETF communities.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
+              RFC 3972, March 2005.
+
+9.2.  Informative References
+
+   [HIPv2]    Moskowitz, R., Heer, T., Jokela, P., and T. Henderson,
+              "Host Identity Protocol Version 2 (HIPv2)", Work in
+              Progress, July 2014.
+
+   [PRIVACYTEXT]
+              Dupont, F., "A Simple Privacy Extension for Mobile IPv6",
+              Work in Progress, July 2006.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+              E. Lear, "Address Allocation for Private Internets", BCP
+              5, RFC 1918, February 1996.
+
+   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
+              (SHA1)", RFC 3174, September 2001.
+
+   [RFC4270]  Hoffman, P. and B. Schneier, "Attacks on Cryptographic
+              Hashes in Internet Protocols", RFC 4270, November 2005.
+
+   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+              Architecture", RFC 4291, February 2006.
+
+
+
+
+
+
+Laganier & Dupont            Standards Track                   [Page 11]
+
+RFC 7343                        ORCHIDv2                  September 2014
+
+
+   [RFC4843]  Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix
+              for Overlay Routable Cryptographic Hash Identifiers
+              (ORCHID)", RFC 4843, April 2007.
+
+   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
+              "Special-Purpose IP Address Registries", BCP 153, RFC
+              6890, April 2013.
+
+   [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
+              Keranen, A., and P. Hallam-Baker, "Naming Things with
+              Hashes", RFC 6920, April 2013.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laganier & Dupont            Standards Track                   [Page 12]
+
+RFC 7343                        ORCHIDv2                  September 2014
+
+
+Appendix A.  Collision Considerations
+
+   As noted earlier, the aim is that so long as keys are not reused,
+   ORCHIDs be globally unique in a statistical sense.  That is, given
+   the ORCHID referring to a given entity, the probability of the same
+   ORCHID being used to refer to another entity elsewhere in the
+   Internet must be sufficiently low so that it can be ignored for most
+   practical purposes.  We believe that the presented design meets this
+   goal (see Section 4).
+
+   As mentioned above, ORCHIDs are expected to be used at the legacy
+   IPv6 APIs between consenting hosts.  The Context ID is intended to
+   differentiate between the various experiments, or contexts, sharing
+   the ORCHID namespace.  However, the Context ID is not present in the
+   ORCHID itself but is only in front of the input bitstring as an input
+   to the hash function.  While this may lead to certain implementation-
+   related complications, we believe that the trade-off of allowing the
+   hash result part of an ORCHID being longer more than pays off the
+   cost.
+
+   Because ORCHIDs are not routable at the IP layer, in order to send
+   packets using ORCHIDs at the API level, the sending host must have
+   additional overlay state within the stack to determine which
+   parameters (e.g., what locators) to use in the outgoing packet.  An
+   underlying assumption here, and a matter of fact in the proposals
+   that the authors are aware of, is that there is an overlay protocol
+   for setting up and maintaining this additional state.  It is assumed
+   that the state-setup protocol carries the input bitstring and that
+   the resulting ORCHID-related state in the stack can be associated
+   back with the appropriate context and state-setup protocol.
+
+Appendix B.  Changes from RFC 4843
+
+   o  Updated HIP references to revised HIP specifications.
+
+   o  The Overlay Routable Cryptographic Hash Identifiers originally
+      defined in [RFC4843] 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.
+
+   o  Moved the "Collision Considerations" section into an appendix and
+      removed unnecessary discussions.
+
+   o  Removed the discussion on overlay routing.
+
+
+
+
+
+
+Laganier & Dupont            Standards Track                   [Page 13]
+
+RFC 7343                        ORCHIDv2                  September 2014
+
+
+Authors' Addresses
+
+   Julien Laganier
+   Luminate Wireless, Inc.
+   Cupertino, CA
+   USA
+
+   EMail: julien.ietf@gmail.com
+
+
+   Francis Dupont
+   Internet Systems Consortium
+
+   EMail: fdupont@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Laganier & Dupont            Standards Track                   [Page 14]
+