On 2011-07-30 03:06 , Mark Andrews wrote:
In message <4E3127F1(_dot_)2030708(_at_)unfix(_dot_)org>, 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf