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

From: Pekka Savola <[email-masked]>
Date: Mon, 22 Mar 2004 15:26:45 +0200 (EET)

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

---

From: "BAUDOT Alain FTRD/DMI/CAE" <[email-masked]>
Date: Tue, 23 Mar 2004 15:29:11 +0100

I agree with Tony's point. I guess, anyway, we have to take care about mechanisms having pieces into different environments, since they may have different requirements. Typical cases are obviously unman & ISP, or enterprise & ISP, assuming that a reasonnable scaled deployment should involve hopefully ISPs.

Alain.
-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Tony Hain Envoyé : vendredi 19 mars 2004 22:14 À : [email-masked] Objet : Recent navel gazing - we need to stop wasting cycles on FUD

Several recent threads are about trying to out-guess the market and pick the one-size-fits-all answer to deployment. The entire point of the scenarios documents was to focus the communities on their area of expertise, so we don't continue arguing that 'we don't need X for my environment, therefore we don't need X'. While it is appropriate to point out when specific mechanisms are or are not useful, it is not appropriate to force the entire diverse Internet into a single, or even restricted set, deployment approach.

We are close to finishing the work on scenarios so we can start applying the proposed tools to them. Rather than the continuing efforts to kill off technologies out of context, the applicability work needs to be completed. While it is useful to make sure we have minimal duplication and overlap, as I look at the proposed tool set I don't see any useful reduction. We can discuss the mechanics of any individual tool, but only in the context that we know exactly what problem we are solving. The continuing FUD is based on application of a tool in an environment that it is specifically not suited for. 

FWIW as I see the tools and their application;

6to4 
- Enterprise -> allows multiple subnet deployments behind the tunnel endpoint with a public IPv4 address. 
- Unmanaged -> this is both simple, and in common use as an automated prefix delegation approach.

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

Teredo
- Unmanaged -> automated single subnet & needed to deal with the NAT managed by someone else problem (home / hotel / airport ...). 
- 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). 

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

Translators as a class
- 3G -> needed if IPv6 only handsets are expected to directly reach the legacy IPv4 Internet or devices that have not reached their economic end of life

Application gateways
- 3G / ISP / Enterprise & Unmanaged -> useful if IPv6-only appliances appear in mass before infrastructure gets upgraded (see Sony press releases).

Each of these tools solves a different subset of the problem space. It is up to the market to decide which have value. The IETF's role is to make sure that the mechanisms are well documented so all implementations have the opportunity to interoperate. If there are operational recommendations or warnings those are also appropriate to document. Attempts to kill off technology X because some people think the market will want Y only ensures that technology X will be implemented differently by each vendor. All of these technologies need to be on the standards track, and the recent discussion about making them experimental is BS that needs to stop. We can't have a reasoned discussion about the useful / extraneous features of any technology until we nail the target deployment environments. 

Tony