On 2011-07-30 03:06 , Mark Andrews wrote: > In message <4E3127F1.2030708@xxxxxxxxx>, Jeroen Massar writes: >> On 2011-07-28 01:36 , Mark Andrews wrote: >> [..] >>> Is there *one* tunnel management protocol that they all support or >>> does a cpe vendor have to implement multiple ones to reach them >>> all? I'm pretty sure I know the answer to this question but I'd >>> love to be proved wrong. >> >> There is no 'one' solution to the problems that they are solving. >> >> As such there tend to be a combo of: >> - static proto-41 tunnel >> - 6to4 >> - 6rd >> - TSP => dynamic NATted addresses >> - proto-41 + heartbeat + TIC => dynamic public addresses >> - AYIYA + TIC => dynamic NATted addresses > > I was more thinking about commonality with tunnel brokers. These all are implemented by "tunnelbrokers", be they tunnel brokers where you can just fill in the details yourself (6to4) or the others where the parameters are provided by the entity you want to connect to. > 6rd is not a replacement for 6to4 as it requires ISP involment or > someone to create a registry of 3rd party 6rd providers along with > associated parameters sets similar non anycast 6to4. 6rd is then also intended for a per ISP deployment. > static proto-41 > tunnel is also not a viable replacement as it doesn't handle address > reassignment at the CPE end. See the "proto-41 + heartbeat" option, that is standard proto-41 but with a side-channel which beats where the endpoint currently is. But why are you trying to replace 6to4? What are the requirements that you have that are not satisfied by any of the above methods? Greets, Jeroen _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf