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

From: "Tony Hain" <[email-masked]>
Date: Fri, 19 Mar 2004 13:13:50 -0800

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

---

From: Pekka Savola <[email-masked]>
Date: Sat, 20 Mar 2004 17:25:07 +0200 (EET)

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

> - Unmanaged -> this is both simple, and in common use as an automated prefix

Agreed, esp. when the gateway is upgraded.  Unfortunately, the quality 
is rather bad still.
 
> 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..

> replace (6to4 would work with public addresses, and manual config is always

Any particular reason why a tunnel server solution would not be 
applicable?
 
> by someone else problem (home / hotel / airport ...). 

Right.

> 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...
 
> really no different than the Dial-up ISP case tunneling over the lethargic

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?

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!").
 
-- 
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: "Tony Hain" <[email-masked]>
Date: Sun, 21 Mar 2004 17:40:42 -0800

> unreliable as 6to4.  Just get a configured tunnel w/ prefix delegation

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. 

> Agreed, esp. when the gateway is upgraded.  Unfortunately, the quality

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

> this).  Sites have deployed native v6 using these methods over 3 years

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

> Any particular reason why a tunnel server solution would not be

Automation.

> benefit would it bring to them?  But if someone wants to do it, why

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. 

> an ISP that wants to offer v6 to its *own* users.  Any particular

They have not been asking for it. 

> 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

---

From: Alain Durand <[email-masked]>
Date: Mon, 22 Mar 2004 15:04:22 -0800

> unreliable as 6to4.  Just get a configured tunnel w/ prefix delegation

I'd like to think of the company I work for as being serious.
We are using 6to4. Not in the way you think, but we are still using it
very seriously.

Your comment is out of place.

	- Alain.

---

From: Tim Chown <[email-masked]>
Date: Tue, 23 Mar 2004 10:08:03 +0000

Hi Alain,

In what way are you seriously using 6to4 in a large enterprise?

I would estimate that 90%+ of the academic sites use manually configured
tunnels.  I don't know of any universities connecting to national
services with 6to4 (there may be some, of course :).

Tim

---

From: Pekka Savola <[email-masked]>
Date: Tue, 23 Mar 2004 12:39:01 +0200 (EET)

> We are using 6to4. Not in the way you think, but we are still using it

It's an entirely different ballgame if you don't use 6to4 for external
connectivity (but internal only, as I recall from previous exchanges)  
.. so for the general 6to4 commectivity, I believe the comment is
still rather accurate.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 23 Mar 2004 10:14:14 -0800

> .. so for the general 6to4 commectivity, I believe the comment is

The point is the validity of the statement really doesn't matter. There is a
valid use for 6to4, as there is with all the other transition technologies
on the table. There is no duplication between them we can identify (other
than possibly in the tunnel broker collection), so we appear to have a
minimum set. Thus they need to be standardized, which may include
modifications from the current documents. 

We also have a set of environment descriptions, and a charter to identify
which of the standardized technologies applies. Specifically 6to4 is on the
list of Enterprise focused technologies, so how it gets used is what needs
to be documented. We do not need to waste time trying to kill any one of the
technologies simply because it does not provide a one-size-fits-all answer,
or does not fit someone's NIH profile. While manually configured tunnels may
appear more stable, they will only scale to a point. For the period beyond
the scale limitations of manual tunnels and full deployment of native
services, an automated tool like 6to4 allows deployment to continue. If any
one network manager chooses not to deploy it, that is a local choice. The
job of the IETF is to get the standardization work done, then provide hints
about intended uses and potential challenges. The market is perfectly
capable of figuring out which tools really apply to the local situation, and
nothing the IETF publishes will change that. If the IETF chooses not to
standardize the technologies or provide usage hints, the market will be left
to pick from non-interoperating approaches, but will none the less meet its
needs to achieve a haphazard deployment. 

Tony

---

From: Tim Chown <[email-masked]>
Date: Tue, 23 Mar 2004 18:30:09 +0000

On Tue, Mar 23, 2004 at 10:14:14AM -0800, Tony Hain wrote:

> While manually configured tunnels may
> services, an automated tool like 6to4 allows deployment to continue. 

Hi Tony, I think you're making very valid points.

Experience in European NRENs is that in the absence of native university
links, manual tunnels are used, rather than 6to4.   Here, the rate of
change of tunnel configuration (add/delete) is important, and I think the
DFN had the largest count at some 300 enterprise sites (which interestingly
have largely been moved to production addressing from 6bone, so there's another
lesson to be learnt in there...).   Routing also has to be configured for
any university site attaching natively anyway... then there are other
resources required such as addres space allocation/management, etc.

I agree SOHO networks where the ISP has (tens+ of) thousands of customers is a
different case.

Tim

---

From: Alain Durand <[email-masked]>
Date: Tue, 23 Mar 2004 22:24:40 -0800

> services with 6to4 (there may be some, of course :).

We have a scenario that is somehow equivalent to a very large enterprise
with many branch offices connected together by a private IPv4 only 
network.
An important characteristic is that there are no communication with the 
"outside" world,
neither in v4 nor in v6, and this is by design. By outside, I mean 
outside of the enterprise,
not outside of 6to4 2002::/16 prefix)

I agree, this is different from the original intend of 6to4, and it is 
based
on the premise that there are no communications to the outside world,
neither in v4 nor in v6, except via IT-controlled proxies.

In this scenario, 6to4 does marvels. Deploying IPv6 in a branch office 
is a 5 minute job,
that is done by configuring 6to4 on one access router. However, I share 
the concerns
of many that in other contexts, 6to4 may not be as desirable, 
especially if external connectivity
is required.

The point I'm trying to make is that one should not confuse, as Pekka 
did,
the protocol with how one could use it.

	- Alain.