Anycast, Multicast or Broadcast Bootstrap Nodes for REsource LOcation And Discovery (RELOAD)
draft-petithuguenin-p2psip-reload-one-to-many-00

Abstract

This document describes an extension to REsource LOcation And Discovery (RELOAD) that permits to contact a bootstrap node using an Anycast, Multicast or Broadcast IP address.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 19, 2013.

Copyright Notice

Copyright (c) 2013 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.

This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Searching for Bootstrap Node
• 4. Acknowledgments
• 5. Security Considerations
• 6. IANA Considerations
• 7. Normative References
• Appendix A. Example
• Author's Address

1. Introduction

RELOAD [I-D.ietf-p2psip-base] explains that to join an overlay a node must, if the bootstrap node cache is empty, contact one of the bootstrap peers listed in a <bootstrap-node> element of the configuration document. The process described works only with unicast addresses, as TCP - and so TLS - is not supported with anything else than unicast addresses, and DTLS does not work at all with multicast or broadcast addresses, and will be unreliable with anycast addresses.

2. Terminology

The key words "MUST" and "MAY" in this document are to be interpreted as described in [RFC2119].

One-to-many Address:

An Anycast, Multicast or Broadcast IP address.

3. Searching for Bootstrap Node

An overlay that runs one or more bootstrap node over a one-to-many address MUST add a <bootstrap-node> element for each of them in the configuration document, using the XML namespace designating them as such. The same configuration document MAY also contain unicast <bootstrap-node> elements to let nodes that do not implement this specification join the overlay.

The RELAX NG grammar for the one-to-many <bootstrap-node> element is as follow. Whitespace and case processing MUST follow the rules of [OASIS.relax_ng] and XML Schema Datatypes [W3C.REC-xmlschema-2-20041028].

namespace otm = "http://implementers.org/reload-one-to-many"

parameter &= element otm:bootstrap-node { 
    attribute address {  xsd:string },     
    attribute port { xsd:int }?
}*
				

The <bootstrap-node> element has an attribute called "address" that contains an IPv4 or IPv6 address and an optional attribute called "port" that represents the port and defaults to 6084. The IPv6 address MUST use the hexadecimal form using standard period and colon separators as specified in [RFC5952]. More than one "bootstrap-node" element MAY be present.

Instead of the bootstrap node, a STUN [RFC5389] server implementing the ALTERNATE-SERVER Mechanism (Section 11) MUST run on the one-to-many address. The STUN server only serves Binding Request and the ALTERNATE-SERVER attribute returned MUST contain the unicast address and the port of a bootstrap node. Credentials MUST NOT be required by the STUN server.

If no cached bootstrap nodes are available, a joining node that implements this specification MUST first try to join the bootstrap nodes designated as listening on a one-to-many address. If trying to contact all the one-to-many addresses fails, the joining node MUST try the eventual unicast bootstrap nodes listed in the configuration document. The joining node MUST send a STUN Binding Request to one of the one-to-many addresses, chosen randomly. Any response other than a 300 will put the one-to-many address in a blacklist for 3 minutes, and the joining node MUST try the next one-to-many address. The IP address and port returned in a 300 response MUST be used as if a unicast bootstrap address was retrieved from the configuration file, and MAY be cached the same way a unicast bootstrap node address is cached.

As a consequence of this design, a bootstrap node running on a unicast address do not have to listen for other protocols than the Overlay Link protocols defined in RELOAD. A client that need to know the Node-ID of the bootstrap node can send a Probe or Ping request over DTLS-UDP-SR, TLS-TCP-FH-NO-ICE or DTLS-UDP-SR-NO-ICE with a destination list containing a single wildcard Node-ID. After this, the standard process to join the overlay described in [I-D.ietf-p2psip-base] can be used.

4. Acknowledgments

Some of the text in this document was taken from version 23 of [I-D.ietf-p2psip-base], authored by Cullen Jennings, Bruce B. Lowekamp, Eric Rescorla, Salman A. Baset and Henning Schulzrinne.

5. Security Considerations

6. IANA Considerations

If this document is accepted as a standard track document this section will request a URN in the "XML Namespaces" class of the "IETF XML Registry" from IANA. Until this is done, implementions should use the following URN:

http://implementers.org/reload-one-to-many

7. Normative References

Appendix A. Example

The following example shows that an anycast address and a multicast address can be used to find a bootstrap node. A joining node that does not recognize the extension can still join the overlay by using the unicast addresses.

<?xml version="1.0" encoding="UTF-8" ?>
<overlay xmlns="urn:ietf:params:xml:ns:p2p:config-base"
   xmlns:otm="http://implementers.org/reload-one-to-many">
   <configuration instance-name="overlay.example.org" sequence="22"
       expiration="2002-10-10T07:00:00Z">
       <bootstrap-node address="192.0.0.1" port="6084" />
       <bootstrap-node address="192.0.2.2" port="6084" />
       <bootstrap-node address="2001:DB8::1" port="6084" />
       <otm:bootstrap-node address="192.0.0.1" />
       <otm:bootstrap-node address="233.252.0.1" port="6084" />
   </configuration>
   <signature> VGhpcyBpcyBub3QgcmlnaHQhCg== </signature>
</overlay>
				

Author's Address