One document matched: draft-petithuguenin-p2psip-reload-one-to-many-00.xml
<?xml version="1.0" encoding="UTF-8"?><?rfc linefile="1:draft-petithuguenin-p2psip-reload-one-to-many.xml"?>
<!-- automatically generated by xml2rfc v1.36 on 2013-01-14T23:21:49Z -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc rfcedstyle="no" ?>
<rfc ipr="noModificationTrust200902" docName="draft-petithuguenin-p2psip-reload-one-to-many-00" category="std">
<front>
<title abbrev="One-To-Many Bootstrap Nodes">Anycast, Multicast or Broadcast Bootstrap Nodes for REsource LOcation And Discovery (RELOAD)</title>
<author initials="M." surname="Petit-Huguenin" fullname="Marc Petit-Huguenin">
<organization>Impedance Mismatch</organization>
<address>
<email>petithug@acm.org</email>
</address>
</author>
<date day="14" month="January" year="2013" />
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section anchor="sec.intro" title="Introduction">
<t>
<xref target="I-D.ietf-p2psip-base">RELOAD</xref> 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.
</t>
</section>
<section anchor="sec.term" title="Terminology">
<t>The key words "MUST" and "MAY" in this document are to be interpreted as described in <xref target="RFC2119" />.</t>
<t>
<list style="hanging">
<t hangText="One-to-many Address:">An Anycast, Multicast or Broadcast IP address.</t>
</list>
</t>
</section>
<section title="Searching for Bootstrap Node">
<t>
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.
</t>
<t>
The RELAX NG grammar for the one-to-many <bootstrap-node> element is as follow.
Whitespace and case processing MUST follow the rules of <xref target="OASIS.relax_ng" /> and <xref target="W3C.REC-xmlschema-2-20041028">XML Schema Datatypes</xref>.
</t>
<figure>
<artwork>
namespace otm = "http://implementers.org/reload-one-to-many"
parameter &= element otm:bootstrap-node {
attribute address { xsd:string },
attribute port { xsd:int }?
}*
</artwork>
</figure>
<t>
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 <xref target="RFC5952" />.
More than one "bootstrap-node" element MAY be present.
</t>
<t>
Instead of the bootstrap node, a <xref target="RFC5389">STUN</xref> 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.
</t>
<t>
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.
</t>
<t>
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 <xref target="I-D.ietf-p2psip-base" /> can be used.
</t>
</section>
<section anchor="sec.ack" title="Acknowledgments">
<t>
Some of the text in this document was taken from version 23 of <xref target="I-D.ietf-p2psip-base" ></xref>, authored by Cullen Jennings, Bruce B. Lowekamp, Eric Rescorla, Salman A. Baset and Henning Schulzrinne.
</t>
</section>
<section anchor="sec.sec" title="Security Considerations">
<t>
</t>
</section>
<section anchor="sec.iana" title="IANA Considerations">
<t>
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:
</t>
<t>http://implementers.org/reload-one-to-many</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc?><?rfc linefile="1:reference.RFC.2119"?>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
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
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<?rfc linefile="121:draft-petithuguenin-p2psip-reload-one-to-many.xml"?>
<?rfc?><?rfc linefile="1:reference.RFC.5389"?>
<reference anchor='RFC5389'>
<front>
<title>Session Traversal Utilities for NAT (STUN)</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<author initials='R.' surname='Mahy' fullname='R. Mahy'>
<organization /></author>
<author initials='P.' surname='Matthews' fullname='P. Matthews'>
<organization /></author>
<author initials='D.' surname='Wing' fullname='D. Wing'>
<organization /></author>
<date year='2008' month='October' /></front>
<seriesInfo name='RFC' value='5389' />
<format type='TXT' octets='125650' target='ftp://ftp.isi.edu/in-notes/rfc5389.txt' />
</reference>
<?rfc linefile="122:draft-petithuguenin-p2psip-reload-one-to-many.xml"?>
<?rfc?><?rfc linefile="1:reference.RFC.5952"?>
<reference anchor='RFC5952'>
<front>
<title>A Recommendation for IPv6 Address Text Representation</title>
<author initials='S.' surname='Kawamura' fullname='S. Kawamura'>
<organization /></author>
<author initials='M.' surname='Kawashima' fullname='M. Kawashima'>
<organization /></author>
<date year='2010' month='August' /></front>
<seriesInfo name='RFC' value='5952' />
<format type='TXT' octets='26570' target='ftp://ftp.isi.edu/in-notes/rfc5952.txt' />
</reference>
<?rfc linefile="123:draft-petithuguenin-p2psip-reload-one-to-many.xml"?>
<?rfc?><?rfc linefile="1:reference.I-D.ietf-p2psip-base"?>
<reference anchor='I-D.ietf-p2psip-base'>
<front>
<title>REsource LOcation And Discovery (RELOAD) Base Protocol</title>
<author initials='C' surname='Jennings' fullname='Cullen Jennings'>
<organization />
</author>
<author initials='B' surname='Lowekamp' fullname='Bruce Lowekamp'>
<organization />
</author>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization />
</author>
<author initials='S' surname='Baset' fullname='Salman Baset'>
<organization />
</author>
<author initials='H' surname='Schulzrinne' fullname='Henning Schulzrinne'>
<organization />
</author>
<date month='November' day='5' year='2012' />
<abstract><t>This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-p2psip-base-23' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-23.txt' />
</reference>
<?rfc linefile="124:draft-petithuguenin-p2psip-reload-one-to-many.xml"?>
<reference anchor="OASIS.relax_ng">
<front>
<title>RELAX NG Specification</title>
<author initials="T" surname="Bray">
<organization>Textuality</organization>
</author>
<author initials="M" surname="Murata">
<organization>Contivo Inc.</organization>
</author>
</front>
<format target="http://relaxng.org/spec-20011203.html" type="HTML" />
</reference>
<?rfc?><?rfc linefile="1:reference.W3C.REC-xmlschema-2-20041028"?>
<reference anchor='W3C.REC-xmlschema-2-20041028'
target='http://www.w3.org/TR/2004/REC-xmlschema-2-20041028'>
<front>
<title>XML Schema Part 2: Datatypes Second Edition</title>
<author initials='A.' surname='Malhotra' fullname='Ashok Malhotra'>
<organization />
</author>
<author initials='P.' surname='Biron' fullname='Paul V. Biron'>
<organization />
</author>
<date month='October' day='28' year='2004' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation' value='REC-xmlschema-2-20041028' />
<format type='HTML' target='http://www.w3.org/TR/2004/REC-xmlschema-2-20041028' />
</reference>
<?rfc linefile="140:draft-petithuguenin-p2psip-reload-one-to-many.xml"?>
</references>
<section anchor="sec.examples" title="Example">
<t>
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.
</t>
<figure>
<artwork>
<?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>
</artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 22:39:38 |