On Nov 4, 2012, at 16:16 , Marc Petit-Huguenin <[email protected]> wrote:
> -----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? I don't think you need to take any of them. You might put in acknowledgment that explained the original source…. > > 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
