-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/04/2012 08:23 AM, Cullen Jennings wrote: > > I like your solution but given that base is deployable without this, I > wonder if you could just write this up in a separate draft that was an > extension to base?
Sure, in this case remove all the stuff in -base related to anycast/multicast and broadcast (as agreed in Vancouver), and I'll start working on a draft with the bits removed from -base, plus my proposal. I may even be able to do that and publish before the P2PSIP WG meeting. As the new draft will take text from -base, what authors from -base should I add to the new draft? Thanks. > > > On Sep 20, 2012, at 10:29 , Marc Petit-Huguenin <[email protected]> wrote: > > 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 > >> _______________________________________________ P2PSIP mailing list >> [email protected] https://www.ietf.org/mailman/listinfo/p2psip > - -- Marc Petit-Huguenin Personal email: [email protected] Professional email: [email protected] Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQltsPAAoJECnERZXWan7EK5oQALoq1+ROmxiOlaBMGw2/E6jy ZDOPtblDCrubxPyazQypPphkD/zDkqsVwYjXEUonbo8C2RCwUhjJLPwYBdp7hiZf PPsYxBDrSn3rGe8rf9A1S+PaKmcbExrbZhJghycW84qN8T6tJREDqD8Wh37eS/Tk jyycIYOkLHfttL1EA78Q/tj9ogXwdBqOH5AAnlfjn6StmaLZ/2Ro1TWwoGMTR8Pn VBowlw3JpwsGxOc5EbDO9UsKsDTVw3cLOl3fZHWh+mFhf/aCgfipzXaVNlb4K4Gk vK19H2y5Jhf+T7TdJVsz5qmtJBmXszDDt+5mTJwWKO8qSv+/yR7iczzItFtrmFnE 6ifEtEFCrEVsoNlYdeZtMJKCo+LTdEPSh3vlg+c2NOgZ/mJsAJYYz8bf1tQ5fA1C 3o0lP+hPbHqTTrfKNY/SM11IDygNMhhwXvLngNC+0uC5rhwZgNGOUZJDi2mIHTg+ ZdfPJ8DU77TmPN1yJZeVRvBj+azICD/9qSBT69Hs+HkE/9MGnQ4pojgNRtWUEqb0 Xi8HWPcQpCAzom3wq1zp8HDK7G3w1ql+wjC4/oN+caohcbXsJRWFMVLSklPAH5Vw eCd2U5vmSSFA74Md3I8eYrkcLLsvIgcuzFjhQt8X+GAxxNgLZiW4z3o99HogHyQe 1/bwYxOivTdeuCP296pl =UK5L -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
