tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6940

 
 
 

REsource LOcation And Discovery (RELOAD) Base Protocol

Part 7 of 7, p. 153 to 176
Prev RFC Part

 


prevText      Top      Up      ToC       Page 153 
14.  IANA Considerations

   This section contains the new code points registered by this
   document.

14.1.  Well-Known URI Registration

   IANA has registered a "well-known URI" as described in [RFC5785]:

           +----------------------------+----------------------+
           | URI suffix:                | reload-config        |
           | Change controller:         | IETF <iesg@ietf.org> |
           | Specification document(s): | RFC 6940             |
           | Related information:       | None                 |
           +----------------------------+----------------------+

14.2.  Port Registrations

   IANA has already allocated a TCP port for the main peer-to-peer
   protocol.  This port had the name p2psip-enroll and the port number
   of 6084.  Per this document, IANA has updated this registration to
   change the service name to reload-config.

   IANA has made the following port registration:

   +-----------------------------+-------------------------------------+
   | Registration Technical      | IETF Chair <chair@ietf.org>         |
   | Contact                     |                                     |
   | Registration Owner          | IETF <iesg@ietf.org>                |
   | Transport Protocol          | TCP                                 |
   | Port Number                 | 6084                                |
   | Service Name                | reload-config                       |
   | Description                 | Peer-to-Peer Infrastructure         |
   |                             | Configuration                       |
   +-----------------------------+-------------------------------------+

Top      Up      ToC       Page 154 
14.3.  Overlay Algorithm Types

   IANA has created a "RELOAD Overlay Algorithm Types" Registry.
   Entries in this registry are strings denoting the names of overlay
   algorithms, as described in Section 11.1 of [RFC6940].  The
   registration policy for this registry is "IETF Review" [RFC522].  The
   initial contents of this registry are:

                      +----------------+-----------+
                      | Algorithm Name | Reference |
                      +----------------+-----------+
                      | CHORD-RELOAD   |  RFC 6940 |
                      | EXP-OVERLAY    |  RFC 6940 |
                      +----------------+-----------+

   The value EXP-OVERLAY has been made available for the purposes of
   experimentation.  This value is not meant for vendor-specific use of
   any sort, and it MUST NOT be used for operational deployments.

14.4.  Access Control Policies

   IANA has created a "RELOAD Access Control Policies" Registry.
   Entries in this registry are strings denoting access control
   policies, as described in Section 7.3 of [RFC6940].  New entries in
   this registry SHALL be registered via Standards Action [RFC5226].
   The initial contents of this registry are:

                      +-----------------+-----------+
                      | Access Policy   | Reference |
                      +-----------------+-----------+
                      | USER-MATCH      |  RFC 6940 |
                      | NODE-MATCH      |  RFC 6940 |
                      | USER-NODE-MATCH |  RFC 6940 |
                      | NODE-MULTIPLE   |  RFC 6940 |
                      | EXP-MATCH       |  RFC 6940 |
                      +-----------------+-----------+

   The value EXP-MATCH has been made available for the purposes of
   experimentation.  This value is not meant for vendor-specific use of
   any sort, and it MUST NOT be used for operational deployments.

Top      Up      ToC       Page 155 
14.5.  Application-ID

   IANA has created a "RELOAD Application-ID" Registry.  Entries in this
   registry are 16-bit integers denoting Application-IDs, as described
   in Section 6.5.2 of [RFC6940].  Code points in the range 1 to 32767
   SHALL be registered via Standards Action [RFC5226].  Code points in
   the range 32768 to 61440 SHALL be registered via Expert Review
   [RFC5226].  Code points in the range 61441 to 65534 are reserved for
   private use.  The initial contents of this registry are:

     +-------------+----------------+-------------------------------+
     | Application | Application-ID |                 Specification |
     +-------------+----------------+-------------------------------+
     | INVALID     |              0 |                      RFC 6940 |
     | SIP         |           5060 | Reserved for use by SIP Usage |
     | SIP         |           5061 | Reserved for use by SIP Usage |
     | Reserved    |          65535 |                      RFC 6940 |
     +-------------+----------------+-------------------------------+

14.6.  Data Kind-ID

   IANA has created a "RELOAD Data Kind-ID" registry.  Entries in this
   registry are 32-bit integers denoting data Kinds, as described in
   Section 5.2 of [RFC6940].  Code points in the range 0x00000001 to
   0x7FFFFFFF SHALL be registered via Standards Action [RFC5226].  Code
   points in the range 0x8000000 to 0xF0000000 SHALL be registered via
   Expert Review [RFC5226].  Code points in the range 0xF0000001 to
   0xFFFFFFFE are reserved for private use via the Kind description
   mechanism described in Section 11 of [RFC6940].  The initial contents
   of this registry are:

             +---------------------+------------+-----------+
             | Kind                |    Kind-ID | Reference |
             +---------------------+------------+-----------+
             | INVALID             |        0x0 |  RFC 6940 |
             | TURN-SERVICE        |        0x2 |  RFC 6940 |
             | CERTIFICATE_BY_NODE |        0x3 |  RFC 6940 |
             | CERTIFICATE_BY_USER |       0x10 |  RFC 6940 |
             | Reserved            | 0x7fffffff |  RFC 6940 |
             | Reserved            | 0xfffffffe |  RFC 6940 |
             +---------------------+------------+-----------+

Top      Up      ToC       Page 156 
14.7.  Data Model

   IANA has created a "RELOAD Data Model" registry.  Entries in this
   registry are strings denoting data models, as described in
   Section 7.2 of [RFC6940].  New entries in this registry SHALL be
   registered via Standards Action [RFC5226].  The initial contents of
   this registry are:

                        +------------+-----------+
                        | Data Model | Reference |
                        +------------+-----------+
                        | INVALID    |  RFC 6940 |
                        | SINGLE     |  RFC 6940 |
                        | ARRAY      |  RFC 6940 |
                        | DICTIONARY |  RFC 6940 |
                        | EXP-DATA   |  RFC 6940 |
                        | RESERVED   |  RFC 6940 |
                        +------------+-----------+

   The value EXP-DATA has been made available for the purposes of
   experimentation.  This value is not meant for vendor-specific use of
   any sort, and it MUST NOT be used for operational deployments.

14.8.  Message Codes

   IANA has created a "RELOAD Message Codes" registry.  Entries in this
   registry are 16-bit integers denoting method codes, as described in
   Section 6.3.3 of [RFC6940].  These codes SHALL be registered via
   Standards Action [RFC5226].  The initial contents of this registry
   are:

Top      Up      ToC       Page 157 
   +-------------------------------------+----------------+-----------+
   | Message Code Name                   |     Code Value | Reference |
   +-------------------------------------+----------------+-----------+
   | invalidMessageCode                  |            0x0 |  RFC 6940 |
   | probe_req                           |            0x1 |  RFC 6940 |
   | probe_ans                           |            0x2 |  RFC 6940 |
   | attach_req                          |            0x3 |  RFC 6940 |
   | attach_ans                          |            0x4 |  RFC 6940 |
   | Unassigned                          |            0x5 |           |
   | Unassigned                          |            0x6 |           |
   | store_req                           |            0x7 |  RFC 6940 |
   | store_ans                           |            0x8 |  RFC 6940 |
   | fetch_req                           |            0x9 |  RFC 6940 |
   | fetch_ans                           |            0xA |  RFC 6940 |
   | Unassigned (was remove_req)         |            0xB |  RFC 6940 |
   | Unassigned (was remove_ans)         |            0xC |  RFC 6940 |
   | find_req                            |            0xD |  RFC 6940 |
   | find_ans                            |            0xE |  RFC 6940 |
   | join_req                            |            0xF |  RFC 6940 |
   | join_ans                            |           0x10 |  RFC 6940 |
   | leave_req                           |           0x11 |  RFC 6940 |
   | leave_ans                           |           0x12 |  RFC 6940 |
   | update_req                          |           0x13 |  RFC 6940 |
   | update_ans                          |           0x14 |  RFC 6940 |
   | route_query_req                     |           0x15 |  RFC 6940 |
   | route_query_ans                     |           0x16 |  RFC 6940 |
   | ping_req                            |           0x17 |  RFC 6940 |
   | ping_ans                            |           0x18 |  RFC 6940 |
   | stat_req                            |           0x19 |  RFC 6940 |
   | stat_ans                            |           0x1A |  RFC 6940 |
   | Unassigned (was attachlite_req)     |           0x1B |  RFC 6940 |
   | Unassigned (was attachlite_ans)     |           0x1C |  RFC 6940 |
   | app_attach_req                      |           0x1D |  RFC 6940 |
   | app_attach_ans                      |           0x1E |  RFC 6940 |
   | Unassigned (was app_attachlite_req) |           0x1F |  RFC 6940 |
   | Unassigned (was app_attachlite_ans) |           0x20 |  RFC 6940 |
   | config_update_req                   |           0x21 |  RFC 6940 |
   | config_update_ans                   |           0x22 |  RFC 6940 |
   | exp_a_req                           |           0x23 |  RFC 6940 |
   | exp_a_ans                           |           0x24 |  RFC 6940 |
   | exp_b_req                           |           0x25 |  RFC 6940 |
   | exp_b_ans                           |           0x26 |  RFC 6940 |
   | Reserved                            | 0x8000..0xFFFE |  RFC 6940 |
   | error                               |         0xFFFF |  RFC 6940 |
   +-------------------------------------+----------------+-----------+

Top      Up      ToC       Page 158 
   The values exp_a_req, exp_a_ans, exp_b_req, and exp_b_ans have been
   made available for the purposes of experimentation.  These values are
   not meant for vendor-specific use of any sort, and they MUST NOT be
   used for operational deployments.

14.9.  Error Codes

   IANA has created a "RELOAD Error Code" registry.  Entries in this
   registry are 16-bit integers denoting error codes, as described in
   Section 6.3.3.1 of [RFC6940].  New entries SHALL be defined via
   Standards Action [RFC5226].  The initial contents of this registry
   are:

   +-------------------------------------+----------------+-----------+
   | Error Code Name                     |     Code Value | Reference |
   +-------------------------------------+----------------+-----------+
   | invalidErrorCode                    |            0x0 |  RFC 6940 |
   | Unassigned                          |            0x1 |           |
   | Error_Forbidden                     |            0x2 |  RFC 6940 |
   | Error_Not_Found                     |            0x3 |  RFC 6940 |
   | Error_Request_Timeout               |            0x4 |  RFC 6940 |
   | Error_Generation_Counter_Too_Low    |            0x5 |  RFC 6940 |
   | Error_Incompatible_with_Overlay     |            0x6 |  RFC 6940 |
   | Error_Unsupported_Forwarding_Option |            0x7 |  RFC 6940 |
   | Error_Data_Too_Large                |            0x8 |  RFC 6940 |
   | Error_Data_Too_Old                  |            0x9 |  RFC 6940 |
   | Error_TTL_Exceeded                  |            0xA |  RFC 6940 |
   | Error_Message_Too_Large             |            0xB |  RFC 6940 |
   | Error_Unknown_Kind                  |            0xC |  RFC 6940 |
   | Error_Unknown_Extension             |            0xD |  RFC 6940 |
   | Error_Response_Too_Large            |            0xE |  RFC 6940 |
   | Error_Config_Too_Old                |            0xF |  RFC 6940 |
   | Error_Config_Too_New                |           0x10 |  RFC 6940 |
   | Error_In_Progress                   |           0x11 |  RFC 6940 |
   | Error_Exp_A                         |           0x12 |  RFC 6940 |
   | Error_Exp_B                         |           0x13 |  RFC 6940 |
   | Error_Invalid_Message               |           0x14 |  RFC 6940 |
   | Reserved                            | 0x8000..0xFFFE |  RFC 6940 |
   +-------------------------------------+----------------+-----------+

   The values Error_Exp_A and Error_Exp_B have been made available for
   the purposes of experimentation.  These values are not meant for
   vendor-specific use of any sort, and they MUST NOT be used for
   operational deployments.

Top      Up      ToC       Page 159 
14.10.  Overlay Link Types

   IANA has created a "RELOAD Overlay Link Registry".  Entries in this
   registry are 8-bit integers, as described in Section 6.5.1.1 of
   [RFC6940].  For more information on the link types defined here, see
   Section 6.6 of [RFC6940].  New entries SHALL be defined via Standards
   Action [RFC5226].  This registry has been initially populated with
   the following values:

                 +--------------------+------+-----------+
                 | Protocol           | Code | Reference |
                 +--------------------+------+-----------+
                 | INVALID-PROTOCOL   |    0 |  RFC 6940 |
                 | DTLS-UDP-SR        |    1 |  RFC 6940 |
                 | DTLS-UDP-SR-NO-ICE |    3 |  RFC 6940 |
                 | TLS-TCP-FH-NO-ICE  |    4 |  RFC 6940 |
                 | EXP-LINK           |    5 |  RFC 6940 |
                 | Reserved           |  255 |  RFC 6940 |
                 +--------------------+------+-----------+

   The value EXP-LINK has been made available for the purposes of
   experimentation.  This value is not meant for vendor-specific use of
   any sort, and it MUST NOT be used for operational deployments.

14.11.  Overlay Link Protocols

   IANA has created a "RELOAD Overlay Link Protocol Registry".  Entries
   in this registry are strings denoting protocols as described in
   Section 11.1 of this document and SHALL be defined via Standards
   Action [RFC5226].  This registry has been initially populated with
   the following values:

                       +---------------+-----------+
                       | Link Protocol | Reference |
                       +---------------+-----------+
                       | TLS           |  RFC 6940 |
                       | EXP-PROTOCOL  |  RFC 6940 |
                       +---------------+-----------+

   The value EXP-PROTOCOL has been made available for the purposes of
   experimentation.  This value is not meant for vendor-specific use of
   any sort, and it MUST NOT be used for operational deployments.

Top      Up      ToC       Page 160 
14.12.  Forwarding Options

   IANA has created a "RELOAD Forwarding Option Registry".  Entries in
   this registry are 8-bit integers denoting options, as described in
   Section 6.3.2.3 of [RFC6940].  Values between 1 and 127 SHALL be
   defined via Standards Action [RFC5226].  Entries in this registry
   between 128 and 254 SHALL be defined via Specification Required
   [RFC5226].  This registry has been initially populated with the
   following values:

              +-------------------------+------+-----------+
              | Forwarding Option       | Code | Reference |
              +-------------------------+------+-----------+
              | invalidForwardingOption |    0 |  RFC 6940 |
              | exp-forward             |    1 |  RFC 6940 |
              | Reserved                |  255 |  RFC 6940 |
              +-------------------------+------+-----------+

   The value exp-forward has been made available for the purposes of
   experimentation.  This value is not meant for vendor-specific use of
   any sort, and it MUST NOT be used for operational deployments.

14.13.  Probe Information Types

   IANA has created a "RELOAD Probe Information Type Registry".  Entries
   are 8-bit integers denoting types as described in Section 6.4.2.5.1
   of [RFC6940] and SHALL be defined via Standards Action [RFC5226].
   This registry has been initially populated with the following values:

                 +--------------------+------+-----------+
                 | Probe Option       | Code | Reference |
                 +--------------------+------+-----------+
                 | invalidProbeOption |    0 |  RFC 6940 |
                 | responsible_set    |    1 |  RFC 6940 |
                 | num_resources      |    2 |  RFC 6940 |
                 | uptime             |    3 |  RFC 6940 |
                 | exp-probe          |    4 |  RFC 6940 |
                 | Reserved           |  255 |  RFC 6940 |
                 +--------------------+------+-----------+

   The value exp-probe has been made available for the purposes of
   experimentation.  This value is not meant for vendor-specific use of
   any sort, and it MUST NOT be used for operational deployments.

Top      Up      ToC       Page 161 
14.14.  Message Extensions

   IANA has created a "RELOAD Extensions Registry".  Entries in this
   registry are 8-bit integers denoting extensions as described in
   Section 6.3.3 of [RFC6940] and SHALL be defined via Specification
   Required [RFC5226].  This registry has been initially populated with
   the following values:

           +-----------------------------+--------+-----------+
           | Extensions Name             |   Code | Reference |
           +-----------------------------+--------+-----------+
           | invalidMessageExtensionType |    0x0 |  RFC 6940 |
           | exp-ext                     |    0x1 |  RFC 6940 |
           | Reserved                    | 0xFFFF |  RFC 6940 |
           +-----------------------------+--------+-----------+

   The value exp-ext has been made available for the purposes of
   experimentation.  This value is not meant for vendor-specific use of
   any sort, and it MUST NOT be used for operational deployments.

14.15.  Reload URI Scheme

   This section describes the scheme for a reload URI, which can be used
   to refer to either:

   o  A peer, e.g., as used in a certificate (see Section 11.3 of
      [RFC6940]).

   o  A resource inside a peer.

   The reload URI is defined using a subset of the URI schema specified
   in Appendix A of RFC 3986 [RFC3986] and the associated URI Guidelines
   [RFC4395] per the following ABNF syntax:

      RELOAD-URI = "reload://" destination "@" overlay "/"
               [specifier]
      destination = 1*HEXDIG
      overlay = reg-name
      specifier = 1*HEXDIG

   The definitions of these productions are as follows:

   destination
      A hexadecimal-encoded Destination List object (i.e., multiple
      concatenated Destination objects with no length prefix prior to
      the object as a whole).

Top      Up      ToC       Page 162 
   overlay
      The name of the overlay.

   specifier
      A hexadecimal-encoded StoredDataSpecifier indicating the data
      element.

   If no specifier is present, this URI addresses the peer which can be
   reached via the indicated Destination List at the indicated overlay
   name.  If a specifier is present, the URI addresses the data value.

14.15.1.  URI Registration

   The following summarizes the information necessary to register the
   reload URI.

   URI Scheme Name:  reload

   Status:   permanent

   URI Scheme Syntax:  see Section 14.15 of RFC 6940

   URI Scheme Semantics:  The reload URI is intended to be used as a
      reference to a RELOAD peer or resource.

   Encoding Considerations:  The reload URI is not intended to be human-
      readable text, so it is encoded entirely in US-ASCII.

   Applications/protocols that Use this URI Scheme:  The RELOAD protocol
      described in RFC 6940.

   Interoperability Considerations:  See RFC 6940.

   Security Considerations:  See RFC 6940

   Contact:  Cullen Jennings <fluffy@cisco.com>

   Author/Change Controller:  IESG

   References:  RFC 6940

14.16.  Media Type Registration

   Type Name: application

   Subtype Name: p2p-overlay+xml

   Required Parameters: none

Top      Up      ToC       Page 163 
   Optional Parameters: none

   Encoding Considerations: Must be binary encoded.

   Security Considerations: This media type is typically not used to
   transport information that needs to be kept confidential.  However,
   there are cases where it is integrity of the information is
   important.  For these cases, using a digital signature is
   RECOMMENDED.  One way of doing this is specified in RFC 6940.  In the
   case when the media includes a shared-secret element, the contents of
   the file MUST be kept confidential or else anyone who can see the
   shared secret can affect the RELOAD overlay network.

   Interoperability Considerations: No known interoperability
   consideration beyond those identified for application/xml in
   [RFC3023].

   Published Specification: RFC 6940

   Applications that Use this Media Type: The type is used to configure
   the peer-to-peer overlay networks defined in RFC 6940.

   Additional Information: The syntax for this media type is specified
   in Section 11.1 of [RFC6940].  The contents MUST be valid XML that is
   compliant with the RELAX NG grammar specified in RFC 6940 and that
   use the UTF-8[RFC3629] character encoding.

      Magic Number(s): none

      File Extension(s): relo

      Macintosh File Type Code(s): none

   Person & Email Address to Contact for Further Information: Cullen
   Jennings <fluffy@cisco.com>

   Intended Usage: COMMON

   Restrictions on Usage: None

   Author: Cullen Jennings <fluffy@cisco.com>

   Change Controller: IESG

14.17.  XML Namespace Registration

   This document registers two URIs for the config and config-chord XML
   namespaces in the IETF XML registry defined in [RFC3688].

Top      Up      ToC       Page 164 
14.17.1.  Config URL

   URI: urn:ietf:params:xml:ns:p2p:config-base

   Registrant Contact: IESG.

   XML: N/A, the requested URIs are XML namespaces

14.17.2.  Config Chord URL

   URI: urn:ietf:params:xml:ns:p2p:config-chord

   Registrant Contact: The IESG.

   XML: N/A, the requested URIs are XML namespaces

15.  Acknowledgments

   This specification is a merge of the "REsource LOcation And Discovery
   (RELOAD)" document by David A. Bryan, Marcia Zangrilli, and Bruce B.
   Lowekamp; the "Address Settlement by Peer to Peer" document by Cullen
   Jennings, Jonathan Rosenberg, and Eric Rescorla; the "Security
   Extensions for RELOAD" document by Bruce B. Lowekamp and James
   Deverick; the "A Chord-based DHT for Resource Lookup in P2PSIP" by
   Marcia Zangrilli and David A. Bryan; and the Peer-to-Peer Protocol
   (P2PP) document by Salman A. Baset, Henning Schulzrinne, and Marcin
   Matuszewski.  Thanks to the authors of [RFC5389] for text included
   from that document.  Vidya Narayanan provided many comments and
   improvements.

   The ideas and text for the Chord-specific extension data to the Leave
   mechanisms were provided by Jouni Maenpaa, Gonzalo Camarillo, and
   Jani Hautakorpi.

   Thanks to the many people who contributed, including Ted Hardie,
   Michael Chen, Dan York, Das Saumitra, Lyndsay Campbell, Brian Rosen,
   David Bryan, Dave Craig, and Julian Cain.  Extensive last call
   comments were provided by Jouni Maenpaa, Roni Even, Gonzalo
   Camarillo, Ari Keranen, John Buford, Michael Chen, Frederic-Philippe
   Met, Mary Barnes, Roland Bless, David Bryan, and Polina Goltsman.
   Special thanks to Marc Petit-Huguenin, who provided an amazing amount
   of detailed review.

   Dean Willis and Marc Petit-Huguenin helped resolve and provided text
   to fix many comments received during the IESG review.

Top      Up      ToC       Page 165 
16.  References

16.1.  Normative References

   [OASIS.relax_ng]
              Bray, T. and M. Murata, "RELAX NG Specification", December
              2001.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets", BCP
              5, RFC 1918, February 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2388]  Masinter, L., "Returning Values from Forms: multipart/
              form-data", RFC 2388, August 1998.

   [RFC2585]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
              Infrastructure Operational Protocols: FTP and HTTP", RFC
              2585, May 1999.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
              Types", RFC 3023, January 2001.

   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, September 2001.

   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 2002.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

Top      Up      ToC       Page 166 
   [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
              for Transport Layer Security (TLS)", RFC 4279, December
              2005.

   [RFC4395]  Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
              Registration Procedures for New URI Schemes", BCP 35, RFC
              4395, February 2006.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245, April
              2010.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5272]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC)", RFC 5272, June 2008.

   [RFC5273]  Schaad, J. and M. Myers, "Certificate Management over CMS
              (CMC): Transport Protocols", RFC 5273, June 2008.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
              for Application Designers", BCP 145, RFC 5405, November
              2008.

   [RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.

   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
              Address Text Representation", RFC 5952, August 2010.

   [RFC6091]  Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
              for Transport Layer Security (TLS) Authentication", RFC
              6091, February 2011.

Top      Up      ToC       Page 167 
   [RFC6234]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.

   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
              "Computing TCP's Retransmission Timer", RFC 6298, June
              2011.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.

   [W3C.REC-xmlschema-2-20041028]
              Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
              Second Edition", World Wide Web Consortium Recommendation
              REC-xmlschema-2-20041028, October 2004,
              <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

   [w3c-xml-namespaces]
              Bray, T., Hollander, D., Layman, A., Tobin, R., and
              University of Edinburgh and W3C, "Namespaces in XML 1.0
              (Third Edition)", December 2008.

16.2.  Informative References

   [Chord]    Stoica, I., Morris, R., Liben-Nowell, D., Karger, D.,
              Kaashoek, M., Dabek, F., and H. Balakrishnan, "Chord: A
              Scalable Peer-to-peer Lookup Protocol for Internet
              Applications", IEEE/ACM Transactions on Networking Volume
              11, Issue 1, 17-32, Feb 2003, 2001.

   [DHT-RELOAD]
              Maenpaa, J. and G. Camarillo, "A Self-tuning Distributed
              Hash Table (DHT) for REsource LOcation And Discovery
              (RELOAD)", Work in Progress, August 2013.

   [Eclipse]  Singh, A., Ngan, T., Druschel, T., and D. Wallach,
              "Eclipse Attacks on Overlay Networks: Threats and
              Defenses", INFOCOM 2006, April 2006.

   [P2P-DIAGNOSTICS]
              Song, H., Jiang, X., Even, R., and D. Bryan, "P2P Overlay
              Diagnostics", Work in Progress, August 2013.

   [P2PSIP-RELAY]
              Zong, N., Jiang, X., Even, R., and Y. Zhang, "An extension
              to RELOAD to support Relay Peer Routing", Work in
              Progress, October 2013.

Top      Up      ToC       Page 168 
   [REDIR-RELOAD]
              Maenpaa, J. and G. Camarillo, "Service Discovery Usage for
              REsource LOcation And Discovery (RELOAD)", Work in
              Progress, August 2013.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC2311]  Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
              L. Repka, "S/MIME Version 2 Message Specification", RFC
              2311, March 1998.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC4013]  Zeilenga, K., "SASLprep: Stringprep Profile for User Names
              and Passwords", RFC 4013, February 2005.

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4145]  Yon, D. and G. Camarillo, "TCP-Based Media Transport in
              the Session Description Protocol (SDP)", RFC 4145,
              September 2005.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol", RFC
              4960, September 2007.

   [RFC5054]  Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
              "Using the Secure Remote Password (SRP) Protocol for TLS
              Authentication", RFC 5054, November 2007.

   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
              of Type 0 Routing Headers in IPv6", RFC 5095, December
              2007.

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", RFC 5201, April 2008.

Top      Up      ToC       Page 169 
   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC5694]  Camarillo, G., Ed., and IAB, "Peer-to-Peer (P2P)
              Architecture: Definition, Taxonomies, Examples, and
              Applicability", RFC 5694, November 2009.

   [RFC5765]  Schulzrinne, H., Marocco, E., and E. Ivov, "Security
              Issues and Solutions in Peer-to-Peer Systems for Realtime
              Communications", RFC 5765, February 2010.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785, April
              2010.

   [RFC6079]  Camarillo, G., Nikander, P., Hautakorpi, J., Keranen, A.,
              and A. Johnston, "HIP BONE: Host Identity Protocol (HIP)
              Based Overlay Networking Environment (BONE)", RFC 6079,
              January 2011.

   [RFC6544]  Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach,
              "TCP Candidates with Interactive Connectivity
              Establishment (ICE)", RFC 6544, March 2012.

   [RFC7086]  Keranen, A., Camarillo, G., and J. Maenpaa, "Host Identity
              Protocol-Based Overlay Networking Environment (HIP BONE)
              Instance Specification for REsource LOcation And Discovery
              (RELOAD)", RFC 7086, January 2014.

   [SIP-RELOAD]
              Jennings, C., Lowekamp, B., Rescorla, E., Baset, S.,
              Schulzrinne, H., and T. Schmidt, "A SIP Usage for RELOAD",
              Work in Progress, July 2013.

   [Sybil]    Douceur, J., "The Sybil Attack", IPTPS 02, March 2002.

   [UnixTime] Wikipedia, "Unix Time", 2013, <http://en.wikipedia.org/w/
              index.php?title=Unix_time&oldid=551527446>.

   [bryan-design-hotp2p08]
              Bryan, D., Lowekamp, B., and M. Zangrilli, "The Design of
              a Versatile, Secure P2PSIP Communications Architecture for
              the Public Internet", Hot-P2P'08, 2008.

Top      Up      ToC       Page 170 
   [handling-churn-usenix04]
              Rhea, S., Geels, D., Roscoe, T., and J. Kubiatowicz,
              "Handling Churn in a DHT", In Proc. of the USENIX Annual
              Technical Conference June 2004 USENIX 2004, 2004.

   [lookups-churn-p2p06]
              Wu, D., Tian, Y., and K. Ng, "Analytical Study on
              Improving DHT Lookup Performance under Churn", IEEE
              P2P'06, 2006.

   [minimizing-churn-sigcomm06]
              Godfrey, P., Shenker, S., and I. Stoica, "Minimizing Churn
              in Distributed Systems", SIGCOMM 2006, 2006.

   [non-transitive-dhts-worlds05]
              Freedman, M., Lakshminarayanan, K., Rhea, S., and I.
              Stoica, "Non-Transitive Connectivity and DHTs", WORLDS'05,
              2005.

   [opendht-sigcomm05]
              Rhea, S., Godfrey, B., Karp, B., Kubiatowicz, J.,
              Ratnasamy, S., Shenker, S., Stoica, I., and H. Yu,
              "OpenDHT: A Public DHT and its Uses", SIGCOMM'05, 2005.

   [vulnerabilities-acsac04]
              Srivatsa, M. and L. Liu, "Vulnerabilities and Security
              Threats in Structured Peer-to-Peer Systems: A Quantitative
              Analysis", ACSAC 2004, 2004.

   [wikiChord]
              Wikipedia, "Chord (peer-to-peer)", 2013,
              <http://en.wikipedia.org/w/
              index.php?title=Chord_%28peer-to-peer%29&oldid=549516287>.

   [wikiKBR]  Wikipedia, "Key-based routing", 2013, <en.wikipedia.org/w/
              index.php?title=Key-based_routing&oldid=543850833>.

   [wikiSkiplist]
              Wikipedia, "Skip list", 2013, <http://en.wikipedia.org/w/
              index.php?title=Skip_list&oldid=551304213>.

Top      Up      ToC       Page 171 
Appendix A.  Routing Alternatives

   Significant discussion has been focused on the selection of a routing
   algorithm for P2PSIP.  This section discusses the motivations for
   selecting symmetric recursive routing for RELOAD and describes the
   extensions that would be required to support additional routing
   algorithms.

A.1.  Iterative vs. Recursive

   Iterative routing has a number of advantages.  It is easier to debug,
   consumes fewer resources on intermediate peers, and allows the
   querying peer to identify and route around misbehaving peers
   [non-transitive-dhts-worlds05].  However, in the presence of NATs,
   iterative routing is intolerably expensive, because a new connection
   must be established for each hop (using ICE) [bryan-design-hotp2p08].

   Iterative routing is supported through the RouteQuery mechanism and
   is primarily intended for debugging.  It also allows the querying
   peer to evaluate the routing decisions made by the peers at each hop,
   consider alternatives, and perhaps detect at what point the
   forwarding path fails.

A.2.  Symmetric vs. Forward Response

   An alternative to the symmetric recursive routing method used by
   RELOAD is forward-only routing, where the response is routed to the
   requester as if it were a new message initiated by the responder.
   (In the previous example, Z sends the response to A as if it were
   sending a request.)  Forward-only routing requires no state in either
   the message or intermediate peers.

   The drawback of forward-only routing is that it does not work when
   the overlay is unstable.  For example, if A is in the process of
   joining the overlay and is sending a Join request to Z, it is not yet
   reachable via forward-only routing.  Even if it is established in the
   overlay, if network failures produce temporary instability, A may not
   be reachable (and may be trying to stabilize its network connectivity
   via Attach messages).

   Furthermore, forward-only responses are less likely to reach the
   querying peer than symmetric recursive ones are, because the forward
   path is more likely to have a failed peer than is the request path
   (which was just tested to route the request)
   [non-transitive-dhts-worlds05].

Top      Up      ToC       Page 172 
   An extension to RELOAD that supports forward-only routing but relies
   on symmetric responses as a fallback would be possible, but due to
   the complexities of determining when to use forward-only routing and
   when to fallback to symmetric routing, we have chosen not to include
   it as an option at this point.

A.3.  Direct Response

   Another routing option is direct response routing, in which the
   response is returned directly to the querying node.  In the previous
   example, if A encodes its IP address in the request, then Z can
   simply deliver the response directly to A.  In the absence of NATs or
   other connectivity issues, this is the optimal routing technique.

   The challenge of implementing direct response routing is the presence
   of NATs.  There are a number of complexities that must be addressed.
   In this discussion, we will continue our assumption that A issued the
   request and Z is generating the response.

   o  The IP address listed by A may be unreachable, either due to NAT
      or firewall rules.  Therefore, a direct response technique must
      fallback to symmetric response [non-transitive-dhts-worlds05].
      The hop-by-hop ACKs used by RELOAD allow Z to determine when A has
      received the message (and the TLS negotiation will provide earlier
      confirmation that A is reachable), but this fallback requires a
      timeout that will increase the response latency whenever A is not
      reachable from Z.

   o  Whenever A is behind a NAT it, will have multiple candidate IP
      addresses, each of which must be advertised to ensure
      connectivity.  Therefore, Z will need to attempt multiple
      connections to deliver the response.

   o  One (or all) of A's candidate addresses may route from Z to a
      different device on the Internet.  In the worst case, these nodes
      may actually be running RELOAD on the same port.  Therefore, it is
      absolutely necessary to establish a secure connection to
      authenticate A before delivering the response.  This step
      diminishes the efficiency of direct response routing, because
      multiple round-trips are required before the message can be
      delivered.

   o  If A is behind a NAT and does not have a connection already
      established with Z, there are only two ways the direct response
      will work.  The first is that A and Z must both be behind the same
      NAT, in which case the NAT is not involved.  In the more common
      case, when Z is outside A's NAT, the response will be received
      only if A's NAT implements endpoint-independent filtering.  As the

Top      Up      ToC       Page 173 
      choice of filtering mode conflates application transparency with
      security [RFC4787] and no clear recommendation is available, the
      prevalence of this feature in future devices remains unclear.

   An extension to RELOAD that supports direct response routing but
   relies on symmetric responses as a fallback would be possible, but
   due to the complexities of determining when to use direct response
   routing and when to fallback to symmetric routing, and the reduced
   performance for responses to peers behind restrictive NATs, we have
   chosen not to include it as an option at this point.

A.4.  Relay Peers

   [P2PSIP-RELAY] has proposed implementing a form of direct response by
   having A identify a peer, Q, that will be directly reachable by any
   other peer.  A uses Attach to establish a connection with Q and
   advertises Q's IP address in the request sent to Z.  Z sends the
   response to Q, which relays it to A.  This then reduces the latency
   to two hops, and Z is negotiating a secure connection to Q.

   This technique relies on the relative population of nodes such as A
   that require relay peers and peers such as Q that are capable of
   serving as a relay peer.  It also requires nodes to be able to
   identify which category they are in.  This identification problem has
   turned out to be hard to solve and is still an open area of
   exploration.

   An extension to RELOAD that supports relay peers is possible, but due
   to the complexities of implementing such an alternative, we have not
   added such a feature to RELOAD at this point.

   A concept similar to relay peers, essentially choosing a relay peer
   at random, has previously been suggested to solve problems of pair-
   wise non-transitivity [non-transitive-dhts-worlds05], but
   deterministic filtering provided by NATs makes random relay peers no
   more likely to work than the responding peer.

A.5.  Symmetric Route Stability

   A common concern about symmetric recursive routing has been that one
   or more peers along the request path may fail before the response is
   received.  The significance of this problem essentially depends on
   the response latency of the overlay.  An overlay that produces slow
   responses will be vulnerable to churn, whereas responses that are
   delivered very quickly are vulnerable only to failures that occur
   over that small interval.

Top      Up      ToC       Page 174 
   The other aspect of this issue is whether the request itself can be
   successfully delivered.  Assuming typical connection maintenance
   intervals, the time period between the last maintenance and the
   request being sent will be orders of magnitude greater than the delay
   between the request being forwarded and the response being received.
   Therefore, if the path was stable enough to be available to route the
   request, it is almost certainly going to remain available to route
   the response.

   An overlay that is unstable enough to suffer this type of failure
   frequently is unlikely to be able to support reliable functionality
   regardless of the routing mechanism.  However, regardless of the
   stability of the return path, studies show that in the event of high
   churn, iterative routing is a better solution to ensure request
   completion [lookups-churn-p2p06] [non-transitive-dhts-worlds05]

   Finally, because RELOAD retries the end-to-end request, that retry
   will address the issues of churn that remain.

Appendix B.  Why Clients?

   There are a wide variety of reasons a node may act as a client rather
   than as a peer.  This section outlines some of those scenarios and
   how the client's behavior changes based on its capabilities.

B.1.  Why Not Only Peers?

   For a number of reasons, a particular node may be forced to act as a
   client even though it is willing to act as a peer.  These include:

   o  The node does not have appropriate network connectivity, typically
      because it has a low-bandwidth network connection.

   o  The node may not have sufficient resources, such as computing
      power, storage space, or battery power.

   o  The overlay algorithm may dictate specific requirements for peer
      selection.  These may include participating in the overlay to
      determine trustworthiness, controlling the number of peers in the
      overlay to reduce overly long routing paths, and ensuring minimum
      application uptime before a node can join as a peer.

   The ultimate criteria for a node to become a peer are determined by
   the overlay algorithm and specific deployment.  A node acting as a
   client that has a full implementation of RELOAD and the appropriate
   overlay algorithm is capable of locating its responsible peer in the
   overlay and using Attach to establish a direct connection to that
   peer.  In that way, it may elect to be reachable under either of the

Top      Up      ToC       Page 175 
   routing approaches listed above.  Particularly for overlay algorithms
   that elect nodes to serve as peers based on trustworthiness or
   population, the overlay algorithm may require such a client to locate
   itself at a particular place in the overlay.

B.2.  Clients as Application-Level Agents

   SIP defines an extensive protocol for registration and security
   between a client and its registrar/proxy server(s).  Any SIP device
   can act as a client of a RELOAD-based P2PSIP overlay if it contacts a
   peer that implements the server-side functionality required by the
   SIP protocol.  In this case, the peer would be acting as if it were
   the user's peer and would need the appropriate credentials for that
   user.

   Application-level support for clients is defined by a usage.  A usage
   offering support for application-level clients should specify how the
   security of the system is maintained when the data is moved between
   the application and RELOAD layers.

Top      Up      ToC       Page 176 
Authors' Addresses

   Cullen Jennings
   Cisco
   400 3rd Avenue SW, Suite 350
   Calgary
   Canada

   EMail: fluffy@cisco.com


   Bruce B. Lowekamp (editor)
   Skype
   Palo Alto, CA
   USA

   EMail: bbl@lowekamp.net


   Eric Rescorla
   RTFM, Inc.
   2064 Edgewood Drive
   Palo Alto, CA  94303
   USA

   Phone: +1 650 678 2350
   EMail: ekr@rtfm.com


   Salman A. Baset
   Columbia University
   1214 Amsterdam Avenue
   New York, NY
   USA

   EMail: salman@cs.columbia.edu


   Henning Schulzrinne
   Columbia University
   1214 Amsterdam Avenue
   New York, NY
   USA

   EMail: hgs@cs.columbia.edu