Re: An alternative to 6to4 and teredo

[Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>]

-- jeudi, janvier 16, 2003 20:32:28 +0100 Erik Nordmark
<Erik.Nordmark@sun.com> wrote/a écrit:

> 
> A long time ago Joshua wrote:
> 
>> This is a chicken and egg problem. That is why transition tools are 
>> important. Apple could develop and ship a system that implemented 6to4 
>> and shipworm/teredo to fall back on when IPv6 wasn't immediately 
>> available. Apple could also ship an application that made use of IPv6. 
>> Microsoft is in a similar position. Once that's done, third party 
>> developers can take advantage of that, assuming all of the transition 
>> mechanisms work. Shooting down 6to4 eliminates one transition 
>> mechanism. Not even acknowledging Teredo is another shot at transition.
> 
> I argue that using tunnel broker and extending it to support UDP tunneling
> across NATs 

see draft-parent-blanchet-ngtrans-tsp-teredo-00.txt

applicability: draft-blanchet-ngtrans-tsp-applicability-00.txt

>is much better than 6to4 and Teredo when considering the space
> of temporary solutions until the ISPs provide native IPv6.
> 
> I think tunnel brokered tunnels provide better incentives for deployment
> than 6to4 relays because they are visible to the user - the provider
> can throw in some content and adds as part of the web page you visit,
> and the can claim "we have x,000 users". A 6to4 relay provider can not
> do this. The "connect to IPv6" icon on the desktop also helps drive
> IPv6 awareness - folks will see that enabling that allows them to run
> their IPv6 peer to peer games even across an IPv4 NAT box, thus they
> are more likely to ask their ISP for native IPv6 than if this is
> completely automatic as is envisioned for Teredo.

tunnel brokers with TSP enables the user to receive:
- a ipv6 address of its tunnel endpoint. 
 + by policy, the broker could give it permanently, even if the ipv4
address change.
 + which means that you keep your ipv6 address permanent if you care.
- an ipv6 prefix, which enables a network behind the device: the network
could be a mobile small network or a fixed network.
 + the ipv6 prefix can be permanent (decided by policy of broker) after
being allocated by the broker.
- register inverse dns delegation.
- set up routing peering if necessary


> 
> The only downside of the tunnel broker schemes is potentially less
> efficient routing. 

- depends on where you put it.
- there is provision in TSP to make a redirect to another broker. redirect
could be related to topology. not perfect but could improve.

> But if the services are popular this might be a
> self-correcting problem. And if they are not popular it is either because
> there is sufficient native IPv6 access or that IPv6 is not being widely
> used.
> 
> The upsides for tunnel broker (with UDP tunneling across NATs, or even PPP
> over  TCP over NATs for those so inclined) in addition to the incentives
> above is that it avoids the security issues around 6to4 and Teredo, and is
> operationally much much simpler to trouble-shoot.

yes. tunnel brokers are just configuring "configured tunnels". 
tsp is a way to automate the establishment of the tunnel, with
authentication.

> And there isn't any risk of creating separate IPv6 native and 6to4
> universes since it is all IPv6 native addresses with regular IPv6 routing.
> 
>   Erik
> 

Marc.