RE: Recent navel gazing - we need to stop wasting cycles on FUD

["Tony Hain" <tony@tndh.net>]

Pekka Savola wrote:
> On Fri, 19 Mar 2004, Tony Hain wrote:
> > 6to4
> > - Enterprise -> allows multiple subnet deployments behind the tunnel
> > endpoint with a public IPv4 address.
> 
> I don't think any serious enterprise would want to do anything as
> unreliable as 6to4.  Just get a configured tunnel w/ prefix delegation
> or native access.

The interesting thing to note is that one person's opinion doesn't matter.
The market has done just fine in the past without a supervising nanny. 

> 
> > - Unmanaged -> this is both simple, and in common use as an automated
> prefix
> > delegation approach.
> 
> Agreed, esp. when the gateway is upgraded.  Unfortunately, the quality
> is rather bad still.

The IETF is about defining the technology. Implementations are for the
market to sort out.

> 
> > ISATAP
> > - Enterprise -> where the apps & hosts move before the infrastructure
> (this
> > is reasonable both from the perspective of demonstrating value, and from
> the
> > perspective that hosts are generally upgraded before infrastructure),
> 
> All you need is one tunnel box e.g. to act as a tunnel server, it's
> not an "all or no infrastructure" deal.  Similarly, if you use VLANs
> inside the enterprise, more often than not, you could inject native v6
> in all the VLANs just by deploying one router (see the draft about
> this).  Sites have deployed native v6 using these methods over 3 years
> ago, and still running..

You clearly have never figured out ISATAP, so please quit trying, and quit
spewing nonsense. 

> 
> > - ISP -> it has value in the Cable operator environment where the
> management
> > side of the gateway is addressed in private IPv4 space, yet the gateway
> > needs to tunnel across older DOCSIS equipment that will take years to
> > replace (6to4 would work with public addresses, and manual config is
> always
> > an option).
> 
> Any particular reason why a tunnel server solution would not be
> applicable?


Automation.

> 
> > Teredo
> > - Unmanaged -> automated single subnet & needed to deal with the NAT
> managed
> > by someone else problem (home / hotel / airport ...).
> 
> Right.
> 
> > - ISP -> automated single subnet & needed to deal with the NAT managed
> by
> > someone else problem (the charging for addresses approach has resulted
> in
> > customers deploying infrastructure, and getting a service behind that
> device
> > is proving to be an issue).
> 
> I don't think I understand what you mean for _ISP_ here.  Deploying a
> Teredo relay/server for its customers?  I don't think they'll bother,
> because such relays/servers must be deployed globally as well, so what
> benefit would it bring to them?  But if someone wants to do it, why
> not...

The point is that the ISP wants to deploy a service on the home wireless
network, but doesn't own the NAT because they have forced their customer to
deploy that by charging for addresses. Since they don't own a critical piece
of the infrastructure they need a way to tunnel through it. 

> 
> > Tunnel brokers as a class
> > - ISP -> for the aggressive ISP that wants to take mindshare away from
> local
> > competitors, there is an opportunity to offer new applications (this is
> > really no different than the Dial-up ISP case tunneling over the
> lethargic
> > PSTN).
> 
> It's interesting that you don't see tunnel brokers as a solution for
> an ISP that wants to offer v6 to its *own* users.  Any particular
> reason why not?

They have not been asking for it. 

> 
> You're making assumption that the TB service for other users would not
> be free, right?  (Otherwise the ISP would not have a point -- but
> would rather just advertise like "switch to us, we offer you free
> tunnel broker if you get your v4 service from us!").

I make no assumptions about service offerings. I only note that tunneling
over lame service providers has a historical precedent, so technologies like
tunnel brokers that allow that mode of operation are viable in the market.

Tony