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

[Pekka Savola <pekkas@netcore.fi>]

On Sun, 21 Mar 2004, Tony Hain wrote:
> > 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. 

I don't think the market has, due to a number of reasons.  We would
probably not be here and now, discussing IPv6 deployment if it had
;-).  The bottom line is that v6ops WG is chartered from the start to
give BCP and Info documents on deployment.  Whether the market wants
to conform or ignore that is of course up to them.

> > > 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. 

I see zero technical content in your reply, so following up is 
probably not productive.

> > > - 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.

Good.  That's an easily fixable problem, already in the works.  
Nobody just seemed to bother to add automation to the tunnel setup
systems, but that can be remedied.

> > > - 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. 
[snip the rest]

That doesn't seem to be a fundamentally all that different problem
than the Teredo case you already mentioned.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings