Network Working Group M. Petit-Huguenin Internet-Draft Impedance Mismatch Intended status: Standards Track January 14, 2013 Expires: July 18, 2013 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. 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. 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 18, 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 Petit-Huguenin Expires July 18, 2013 [Page 1] Internet-Draft One-To-Many Bootstrap Nodes January 2013 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Searching for Bootstrap Node . . . . . . . . . . . . . . . . . 3 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Petit-Huguenin Expires July 18, 2013 [Page 2] Internet-Draft One-To-Many Bootstrap Nodes January 2013 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 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 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 elements to let nodes that do not implement this specification join the overlay. The RELAX NG grammar for the one-to-many 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 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. Petit-Huguenin Expires July 18, 2013 [Page 3] Internet-Draft One-To-Many Bootstrap Nodes January 2013 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: Petit-Huguenin Expires July 18, 2013 [Page 4] Internet-Draft One-To-Many Bootstrap Nodes January 2013 http://implementers.org/reload-one-to-many 7. Normative References [I-D.ietf-p2psip-base] Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) Base Protocol", draft-ietf-p2psip-base-23 (work in progress), November 2012. [OASIS.relax_ng] Bray, T. and M. Murata, "RELAX NG Specification". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010. [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, . 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. Petit-Huguenin Expires July 18, 2013 [Page 5] Internet-Draft One-To-Many Bootstrap Nodes January 2013 VGhpcyBpcyBub3QgcmlnaHQhCg== Author's Address Marc Petit-Huguenin Impedance Mismatch Email: petithug@acm.org Petit-Huguenin Expires July 18, 2013 [Page 6]