Subject: [P2PSIP] Anycast support in RELOAD, again

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 20 Sep 2012 09:29:38 -0700

In Vancouver we decided[1] to remove the support for
multicast/anycast/broadcast in the RELOAD spec, following a discussion back in
Taipei about problems for supporting anycast.

I thought a bit more about the anycast problem, and I found a solution to this
problem that is simple and so that would permit to keep the text in -base.

To summarize the problem, a bootstrap node cannot be directly running on an
anycast address because the real destination can change at any time, and that
would break DTLS.  That can be solved by adding the IP address of a bootstrap
node not running on the anycast address in the PingResponse, but unfortunately
this is not a compatible change.  There is other problems with this approach,
related to the fact that the Ping must be sent without DTLS (naked Ping).

But, as per -base section 6.5.1.4, all RELOAD nodes are also STUN servers, so
the naked Ping can be replaced by a STUN connectivity check.  The nice thing
about STUN is that the support for anycast is already there, as a STUN server
running on an anycast address will respond with a 300 Try Alternate with an
ALTERNATE-SERVER attribute containing the IP address of the non-anycast node.

So the whole problem can be solved by just saying in -base that any connection
to the bootstrap servers must start with a STUN connectivity check.  The first
IP address to successfully respond (i.e. after processing the 300), is the one
where the DTLS/TLS connection must be established to start sending the RELOAD
messages.

[1] https://www.ietf.org/proceedings/84/minutes/minutes-84-p2psip
[2] https://www.ietf.org/proceedings/82/minutes/minutes-82-p2psip

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug