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

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

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