Subject: Automatic tunnels

From: "Christian Huitema" <[email-masked]>
Date: Thu, 24 Jul 2003 09:17:02 -0700

During the Vienna meeting, I sensed that there was a split in the WG
constituency between those who like automatic tunneling techniques such
as 6to4 and Teredo because they enable automatic deployment of IPv6, and
those who have an instinctive dislike for these technologies and would
much prefer controlled mechanisms and the orderly deployment of tunnels.
I would like to understand how we can resolve this tension.

My personal analysis is that configured tunnels have a lot of drawbacks,
unless they are "very short", in practice if they are provided by the
very same ISP that provides IPv4 connectivity. This opinion is based on
our collective experience with long tunnels: they require collaboration
of a remote entity, and thus explicit configuration; they don't follow
the natural Internet topology and thus often result in rather poor
transmission times; and they are costly to provide, as someone has to
pay for the transmission to and from the tunnel endpoint.

Automatic tunnels like 6to4 and Teredo have the advantage of being
potentially "very short": the transmission between two transition hosts
follows the IPv4 topology, and is thus as short as it gets; the
transmission between transition and native includes a dog-leg, but that
leg can be as short as the distance to the nearest relay, i.e. the
nearest dual stack router. The typical issues with automatic tunnels are
the stability of the IPv6 address (as stable as the underlying IPv4),
the provision of reverse mappings in the DNS, and the possibility of
attacks on or through the relays, most of which can probably be
mitigated. Another often quoted issue is that people might just be
satisfied with the transition technology and never go native, but I
don't believe that this creates much of a difference between configured
and automatic tunnels.

An obvious compromise would be to use no tunnel at all if the ISP
provides IPv6 connectivity, configured tunnels when provided by the
local ISP, automatic tunneling otherwise. However, this begs one
question. Why would an ISP invest in providing local tunnels, instead of
providing native connectivity faster? If the ISP wants to facilitate the
transition, why would it not just provide a local 6to4 relay for the
exclusive use of its customers?

-- Christian Huitema

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Thu, 24 Jul 2003 19:23:48 +0200

Hi Christian, all,

I'm in principle in favor of both, because my belief is that only the market will drive one or the other.

Of course, I will much prefer native services, but they only will happen when the ISPs can start making money because the native
service itself, or because is an added value for their "regular" IPv4 service.

The problem is that I don't think most of the ISPs will invest in offering tunnel services, because they will cost almost the same
as providing native service, with the only difference of the customer CPE and the BAS in case of xDSL or similar services. May be
some will start with tunnels until they upgrade their BAS, and then will ask their customers to pay an additional fee for moving to
a native service. Is a possible business model, but as said, who knows.

But what I'm convinced is that we will have both type of tunnels, and we must provide good technical support for them:
1) Automatic tunnels provided mainly by non-local ISPs (as is the case for the actual tunnel brokers, over all the world)
2) Configured tunnels provided by local ISPs.

I think this is opposed to your belief ... but I think the local ISPs will only provide tunnels if they can be managed.

So what I believe is that we need more support for the "local-ISPs". Automatic tunnels don't like them, because, at least actually,
they have non easy way to control the users.

If we have a Teredo-like mechanism that provides authentication (with or w/o billing, that's another history), that will be
interesting for local ISPs, but then is not so-automatic. I think it can be a simple registration site, something like what you have
for a TB.

I don't think that providing transition paths will difficult the global adoption of IPv6, more at the contrary, transition is always
"bad" in terms of performance, and the people will like to take advantage of native IPv6, specially when they tried a good
transition path.

My 20 cents ;-)

Regards,
Jordi

----- Original Message ----- 
From: "Christian Huitema" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 24, 2003 6:17 PM
Subject: Automatic tunnels

-- Christian Huitema

*****************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on-line at:
http://www.ipv6-es.com

---

From: [email-masked]
Date: Fri, 25 Jul 2003 13:43:43 +0900

>The problem is that I don't think most of the ISPs will invest in
>offering tunnel services, because they will cost almost the same
>as providing native service, with the only difference of the customer
>CPE and the BAS in case of xDSL or similar services. May be some
>will start with tunnels until they upgrade their BAS, and then will
>ask their customers to pay an additional fee for moving to a native
>service. Is a possible business model, but as said, who knows.

	we at IIJ use PC with BSD operating system for terminating our
	tunnelling service customers.  required investment is minimal, and 1
	PC can terminate > 10000 tunnels if you want to (we don't do 10000,
	but freenet6 does it).  it is an added value to our IPv4 service (it
	will look more tasty).  other japanese ISPs are doing similar things.
	so i guess i disagree with you on "most of the ISPs won't invest on
	tunnel service".

itojun

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Fri, 25 Jul 2003 08:33:55 +0200

I don't think most of the ISPs will do it with just a PC. Most of them still don't believe in IPv6, so is just a good excuse for
them (they will tell you that is still not well supported by the router vendors). Most of the cost anyway is training the people and
maintaining the service (including the customers hot line).

Its clear, how many TBs exist around the world versus ISPs ?

But may be there are other reasons that I didn't cached ?

Regards,
Jordi

---

From: "Piotr Zurawski" <[email-masked]>
Date: Fri, 25 Jul 2003 09:39:33 +0200

In my company, not supporting the IPv6 was the first reason to make
problems with the deployment.
But I see it as a deeper thing: IPv4 services are managable through
network management systems. For the ATM network you can tune up many
parameters to optimize IP traffic and/or other services. If you add a
new protocol, which cannot be managed via the same interface, this
messes up the things:there are not many people with knowledge how to
solve the problems with tunneled IPv6 and even how to find them. Another
point is that nobody will guarantee, that the service will be working
properly. For IPv4 our hardware vendor gives us the support. For IPv6
we're on our own. Most of us here are technical persons (as far as I see
it). It's not a problem for techies to solve the things - we're just in
it.
This looks completely different from managements' point of view: IPv6
comes as a new service, without any guarantees (we offer SLA for all
type of services being offered, you'd have to cross IPv6 from your SLA
portfolio then - it won't look good). To deploy IPv6 you'll need to
train people and any human resource rotation will cause more problems
(more things to be learnt). Still, since nearly noone *REQUIRES* IPv6
connectivity to be done, it does not come as a priority to be deployed.
For management, more important is to improve the services already
existing. The reason, that would vitally speed up the global deployment
would be the deadline. This is not based on what US DoD done (but it's a
good example how to speed it up). From my experience, if management does
not see the deadline, the current affairs (having deadline and precise
effects) will be considered to be done.

I didn't wanted to feed up the troll. That's just how it looks in few
ISPs in Poland I know.

Best Regards,

Piotr
----- Original Message ----- 
From: "JORDI PALET MARTINEZ" <[email-masked]>
To: <[email-masked]>
Sent: Friday, July 25, 2003 8:33 AM
Subject: Re: Automatic tunnels

> I don't think most of the ISPs will do it with just a PC. Most of them
still don't believe in IPv6, so is just a good excuse for
> them (they will tell you that is still not well supported by the
router vendors). Most of the cost anyway is training the people and

---

From: Alain Durand <[email-masked]>
Date: Fri, 25 Jul 2003 09:08:29 -0700

> exclusive use of its customers?

Christian,

First of, let me clarify that is discussion is more relevant to the 
home ISP
than to the enterprise ISP.

I will agree with your analysis that customers configured tunnels needs
to be terminated within the home ISP core or access network to be 
efficient.
This does not rule out configured tunnels, however it requires ISP 
cooperation to work.

I would also like to point that automatic tunnels have their share of
problems. Security is a big concern on my list. We have studied at 
length
6to4 security issues, we would need to do the same with teredo/isatap.

The rest of the message analyses 6to4 vs tunnel broker from the ISP 
perspective
(as opposite to the user perspective)

One issue is to understand the scaling properties of 
configured/automatic
tunnel solutions. 6to4 to native v6 kinda works (if you accept that the 
packets
you send to your neighbor can go a couple times around the planet) 
today because
there is very little traffic.Tunnel brokers done outside of traditional 
IPv4 ISPs induce
sub-optimal traffic. It's fine as a bootstrapping mechanism for early
adopter, but this cannot sustain production traffic. For this, as said 
earlier,
tunnel server would have to be as close to the source as possible.

We also need to understand if and how a home ISP can deploy gradually 
IPv6
for its customer. Does providing a 6to4 relay helps? Does providing a 
tunnel broker
in in core/access networks help? Does this makes it easier to go 
gradually to native?

The issue with with an ISP deploying an internal 6to4-to-native relay 
is that
it will help its customers who are using 6to4 to send packets to native 
IPv6
destination, but won't do much to make sure that the same packets will
return any quicker. As 6to4 to native and back is fundamentally 
asymmetric routing,
somebody, preferably close to the native IPv6 node has to have a route 
for 2002::/16.
As one can not realistically expect to have every single IPv6 network 
maintaining
a local native-to-6to4 gateway, we would have to rely on public,
open native-to-6to4 relays to exist and advertise 2002::/16 in the DFZ.
So far, I have identified only a few of those public native-to-6to4 
relays.
My understanding is that, expect from the willingness to promote the 
technology,
there is actually little incentive to operate such a relay, as it will 
just attract transit traffic
that has nothing to do with the ISP customers.

But if/once an ISP had deployed local 6to4-to-native relay, what is the 
next step?
It seems to me that there is a more natural evolution path if the ISP 
starts with
a tunnel broker/server. Internal links can be upgraded to native, then 
PE-CPE
links can be upgraded to native in places where the demand justifies it.
In other words, it seems to me that it is easier to go selectively  from
a sparse deployment mode to a dense deployment mode.

	- Alain.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 29 Jul 2003 11:16:58 +0200

To be honest, I think both forms of tunnels offers the ISPs a good 
starting point. Given the current levels of bandwidth consumed by IPv6 
traffic (a large carrier told me they had magnitudes more OSI traffic 
for ADM management than IPv6 traffic) I think that we have to realize 
that carriers will not start rolling out native links of the same 
bandwidth as they do for IPv4 - especially with current revenue levels 
from IPv6 services.

The alternative is dual-stack, but if I would be a carrier I would be 
very reluctant to roll-out dual-stack software (or at least to activate 
it) on my routers.

Tunneling gives the ISPs the advantage that they can activate IPv6 at 
the edge and start in small scale and bind it all together across the 
core. Christian is right in saying that this potentially (not to say in 
real life) gives less performance and higher RTT. However, I think is 
something that market demand will have to take care of.

- - kurtis -

On torsdag, jul 24, 2003, at 19:23 Europe/Stockholm, JORDI PALET 
MARTINEZ wrote:

> Of course, I will much prefer native services, but they only will 
> happen when the ISPs can start making money because the native
> CPE and the BAS in case of xDSL or similar services. May be
> some will start with tunnels until they upgrade their BAS, and then 
> will ask their customers to pay an additional fee for moving to
> But what I'm convinced is that we will have both type of tunnels, and 
> we must provide good technical support for them:
> 1) Automatic tunnels provided mainly by non-local ISPs (as is the case 
> for the actual tunnel brokers, over all the world)
> I think this is opposed to your belief ... but I think the local ISPs 
> will only provide tunnels if they can be managed.
>
> So what I believe is that we need more support for the "local-ISPs". 
> Automatic tunnels don't like them, because, at least actually,
> If we have a Teredo-like mechanism that provides authentication (with 
> or w/o billing, that's another history), that will be
> interesting for local ISPs, but then is not so-automatic. I think it 
> can be a simple registration site, something like what you have
> for a TB.
>
> I don't think that providing transition paths will difficult the 
> global adoption of IPv6, more at the contrary, transition is always
> "bad" in terms of performance, and the people will like to take 
> advantage of native IPv6, specially when they tried a good
> transition path.
>
> My 20 cents ;-)
>
> Regards,
> Jordi
>

---

From: Tim Chown <[email-masked]>
Date: Tue, 29 Jul 2003 10:23:10 +0100

> very reluctant to roll-out dual-stack software (or at least to activate 

I'm curious, what do you see as the main reasons for this?

Tim

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 29 Jul 2003 11:40:43 +0200

> I'm curious, what do you see as the main reasons for this?

Experience? :-) The two vendors have enough of a problem to get v4 
packets from interface A to interface B, and that is with customers 
that are paying for SLAs...

I know it's being done and on pretty large networks as well. But I also 
hear people that are having problems in doing so.

- - kurtis -

---

From: Rute Sofia <[email-masked]>
Date: Tue, 29 Jul 2003 10:46:31 +0100

>Experience?:-) The two vendors have enough of a problem to get v4 
Not sure if I understood the point above correctly, but there are 
several reasons that ISPs use not to deploy dual-stack...the biggest is 
simply fear of the unknown ;-)

Actually, in the past we (FCCN, the portuguese NREN) had several 
problems with Cisco routers, due to unstable "stable" IOS versions.  
But, after a bit of tackling, dual-stack is running indeed. Juniper 
routers were a great help to deploy dual-stack in an operacional 
environment. There were no problems at all.

Rute

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 29 Jul 2003 12:12:02 +0200

>> I know it's being done and on pretty large networks as well. But I 
>> also hear people that are having problems in doing so.
>>
>>
> several reasons that ISPs use not to deploy dual-stack...the biggest 
> is simply fear of the unknown ;-)

Absolutely. It's probably the largest reason. But even then tunnels are 
a great help for ISPs to see and learn.

> environment. There were no problems at all.

Glad to hear. I have heard opposite experiences but this will probably 
vary with your network topology, size, equipment in use etc. Just as 
for v4.

- - kurtis -

---

From: Gert Doering <[email-masked]>
Date: Tue, 29 Jul 2003 12:24:26 +0200

Hi,

> I'm curious, what do you see as the main reasons for this?

Operational errors (like "wrong IP address configured on interface" or
"routing protocol configuration things" or "correct v4 address in DNS but
v6 address wrong" or so) hit in quite surprising ways - you test, you 
run traceroute and ping, all looks fine, and then you realize that you 
traceroute'd only v4 while v6 is broken, or vice versa.

Of course all this is solveable, but it means "more room for errors",
and usually these do happen.

(We're in the process of converting the v4-only network to dual-stack,
and it's quite a challenge)

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  55442  (55636)

SpaceNet AG                 Mail: [email-masked]
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299

---

From: Tim Chown <[email-masked]>
Date: Tue, 29 Jul 2003 11:38:10 +0100

> and it's quite a challenge)

There are many networks that have gone dual stack, so what you're saying
is we need more operational experience feedback of the problems, rather
than just the success stories.   The early adoptors are the US and European
research networks and backbones.   I think they've been instrumental in
helping Cisco, Juniper et al iron out many of the problems to make 
deployment less problematic (but by no means straightforward) for ISPs.

Tim

---

From: Rute Sofia <[email-masked]>
Date: Tue, 29 Jul 2003 11:36:06 +0100

Gert,

>traceroute'd only v4 while v6 is broken, or vice versa.
Most operational errors are because ISPs do not have guidelines on how 
to deploy IPv6. It is quite a big task, given that everything has to be 
changed and somehow, the connectivity should be kept at any cost. Added 
to that, there's the addressing space allocation...
 Also, this is still a field where in operational terms there is still 
room to do a lot.

It took us almost 5 years ;-) to complete the transition to dual-stack, 
mostly because the equipment did not fully behave as it should. So, in 
fact we had to acquire different equipment, and not only upgrade 
software. But, we're a non-commercial ISP. It is obviously harder for a 
commercial ISP to justify a full upgrade to the bakbone. But, given that 
we are speaking of dual-stack and not of IPv6-only ;-), it should not be 
such a big fuss, given that in the worst-case, it can still run as IPv4 ;-)

Rute

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 29 Jul 2003 12:45:06 +0200 (CEST)

On Tue, 29 Jul 2003, Kurt Erik Lindqvist wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

You can look at several examples in Europe. GEANT, SURFNET or RENATER
already dual stacked. They have rather large network. I am sure, that they
had slight problems running dual-stack in the beginning, but they run
successfully now. On the other hand for example at HUNGARNET we also have
rather large IPv6 network, but currently we cannot run dual stack since
there is no IPv6 support at all for large number of our routers (Cisco
7600).  It seems, that we have to find alternative solution...

Regards,
	Janos Mohacsi

---

From: Rute Sofia <[email-masked]>
Date: Tue, 29 Jul 2003 11:44:15 +0100

>deployment less problematic (but by no means straightforward) for ISPs.
Completely agree. NRENs are in the group of ISPs with more IPv6 
experience. And, it is a fact that this helped vendors to tackle 
problems. Also, given that NRENs are quite different in topology and 
equipment, their experience will for sure be benefitial as an example on 
how to deploy IPv6 for other ISPs...

Rute

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 29 Jul 2003 13:08:13 +0200

> equipment, their experience will for sure be benefitial as an example 
> on how to deploy IPv6 for other ISPs...

There is also the fact that NRENs does not have to generate ROI for 
their deployment, while many ISPs are struggling to do ROI on IPv4. 
Which again is a driver for a step-by-step approach.

Best regards,

- - kurtis -

---

From: Rute Sofia <[email-masked]>
Date: Tue, 29 Jul 2003 12:11:41 +0100

Kurtis,

>>uipment, their experience will for sure be benefitial as an example 

It is a fact that NRENs are non-profit organizations, but they do have 
to justify where the money goes ;-), whether we speak of v4, v6, 
services and so on. So, there is always a need for a ROI, independently 
of the technology...

Anyway, this is possibly off-topic ;-). AS for the online topic I 
believe we all agree that:

1) the transition takes a long time, requires some investment, and the 
profit is still not clear (in commercial terms, of course...)
2) there are still lots of issues with the equipment and software used;
3) a step-by-step approach is necessary
4) feedback from ISPs (whether they are commercial or not) is required, 
so others can more easily deploy IPv6...
5) feedback from ISPs to vendors is also required, so problems can be 
solved...

Rute

Rute

---

From: Randy Bush <[email-masked]>
Date: Tue, 29 Jul 2003 07:47:49 -0700

> very reluctant to roll-out dual-stack software (or at least to activate 

i guess that depends on whether you are locked into a router vendor
who lacks support of ipv6 in their hardware.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 29 Jul 2003 07:52:11 -0700

> The early adoptors are the US and European research networks and
> backbones.

rofl!

---

From: Tim Chown <[email-masked]>
Date: Tue, 29 Jul 2003 16:23:56 +0100

> > The early adoptors are the US and European research networks and

So what exactly is laughable about research networks deploying IPv6?  

Tim

---

From: Randy Bush <[email-masked]>
Date: Tue, 29 Jul 2003 08:30:55 -0700

> So what exactly is laughable about research networks deploying IPv6?  

what is amusing is ignoring the research and *commercial* deployment
in asia.

randy

---

From: Tim Chown <[email-masked]>
Date: Tue, 29 Jul 2003 16:35:29 +0100

> what is amusing is ignoring the research and *commercial* deployment

Oh, OK, well that's a fair point - I thought you were suggesting something
else :)

Is there a good reference on what the commercial deployments in Asia are
running, the services offered, number of end users etc?   Would be good 
to see some info to learn from.

Tim

---

From: [email-masked]
Date: Wed, 30 Jul 2003 08:24:59 +0900

>to see some info to learn from.

	contact [email-masked] (or www.v6pc.jp), they may have comprehensive
	tables/stats.

itojun

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Wed, 30 Jul 2003 09:54:55 +0200

> who lacks support of ipv6 in their hardware.

To some extent , yes. Or what the cost of getting that hardware is.

- - kurtis -

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jul 2003 13:42:31 +0200 (CEST)

> I would like to understand how we can resolve this tension.

I suspect that that the issues are complex and interrelated thus
trying to make a black and white distinction between automatic and
configured tunnels is hard.
Thus I've tried to put down different aspects of tunnels below and taken
the liberty of using tunnel broker as an example where "configured"
can actually look the same to the user as "automatic".

1. IPv6 tunnels on by default

Some vendors might want to make IPv6 easier for the users by turning 
on IPv6 tunneling by default (for instance where there is IPv4 connectivity
and no native IPv6 connectivity). Other vendors might prefer a "click
here to enable IPv6 tunneling". I think this is only implementation
issue except in the case of tunneling across NATs.

1b. IPv6 tunnels across NATs on by default

Tunneling across NATs, which by accident will tunnel across many firewall
configurations, presumably means that the IETF shouldn't endorse  a "default
tunnel across NATs" approach but instead suggest that the user be involved in
turning this on. Also, there might be a reasonable requirement that it should
be easy for network admins to prevent such tunneling by having a simple filter
(e.g. filter on a single UDP port.)

2. Single knob "enable IPv6 tunnel" for user

I think this can be implemented for a large number of tunneling technologies.
For instance, a tunnel broker client could have a list public tunnel brokers
and use ping times to select one. Or it would be possible to define an anycast
address for the tunnel broker setup (not used for the tunneled packets).

3. Registration and authentication of user

Some operators of infrastructure for tunnels, whether they fall in
what Christian calls "automatic" or "configured", might want to be
able to know who is using their infrastructure. Also, in the case
of DoS attacks or other issues such operators might want to be able
to point at "the source of that was this IPv4 address" to help
tracking down the problems.
On the other hand there might be folks, such as ISPs, which want to 
be able to provide tunneling infrastructure for a subset of IPv4 addresses
(such as the subscribers of the ISP) without requiring any explicit 
registration and authentication of the user.

Thus it would seem good if there either is one approach which can
optionally do registration and authentication at tunnel
establishment time, or there is one approach with and one without
registration and authentication.

4. Simple for ISPs to deploy

I'm not sure I understand the comparison here between the so called "automatic"
(6to4 and Teredo) and so called "configured" (tunnel broker or similar)
tunnels. With the latter the ISP can make sure they are only providing service
to their subscribers. Is the same true for 6to4 relays and teredo servers?

5. Providing visibility for those providing infrastructure

A non-technical issue is whether entities that provide some infrastructure 
for tunneling ("servers" or "relays") that is not limited to
users with which they have a subscriber relationship, are visible to the 
end users i.e. that the can derive some name recognition for their help.

6. Avoiding traffic concentration at some "server"/"relay"

One of the benefits of 6to4 and teredo is that traffic between nodes
that use that scheme can avoid going through a single point.
I think that this is really separate from terms like "automatic" vs.
"configured", and it would be good to understand the tradeoffs in
this space better. For instance, it seems to me that this benefit goes away
when only one of the communicating parties implement 6to4/teredo.
Also, at least in the case of 6to4, this benefit is accomplished at
the expense of making certain other things more difficult (such as having
multiple 6to4 routers between some cloud and the rest of the Internet).
Finally, there are operational implications of this type of "short-cut
routing". With tunnel broker configured tunnels I understand how to debug
problems thus I think if ISPs want to use them their staff can understand how
to debug  them as well (try a traceroute to/from the IPv4 address of the
tunnel endpoint, etc). And if things don't work one can try switching to
different tunnel broker.
With the shortcuts provided by teredo and 6to4 it is much harder to determine
whether it is an IPv4 problem (IPv4 might work to/from a relay without working
on the direct path) or IPv6 (IPv6 tunneling might work to/from a relay
without working to/from a particular IPv6 peer). The teredo interactions
with the large variation of NAT behavior makes this even harder.
[And combining this with anycast to simplify #2 above adds to the troubles
to debug.]
So color me concerned - I don't think we need the equivalent NHRP for IPv6
tunnels.

---

Perhaps there are more facets of the "automatic" vs. "configured" distinction
than the ones I've listed above.
But hopefully trying to tease apart the different facets makes
it easier to come to a shared understanding of the issues.

  Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jul 2003 14:58:42 +0200

This is an interesting discussion of the issues (well, it was, but
I deleted it to save bits). But I'm not sure that the WG has to, or
should, make a choice. The network is already telling us that both
tunnel brokers and 6to4 attract users. I guess the jury is still out
on Teredo. But I don't think it's for us to make a philosophical
decision here. We will need to decide whether to adopt Teredo, but that
should drop out of the scenario analysis as a pragmatic decision.

   Brian

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jul 2003 15:05:57 +0200 (CEST)

> should drop out of the scenario analysis as a pragmatic decision.

Brian,

You seem to be making a "the market will decide" argument with respect
to 6to4 and tunnel brokers.
Is that correct?

I find it disconcerting that you didn't want to contribute to the understanding
of the issues (with apply to all tunneling approaches - 6to4, teredo, tunnel
brokers) and instead deleted the email to "save bits". That doesn't bode well
for making forward progress.

Sigh
  Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jul 2003 15:38:19 +0200

> to 6to4 and tunnel brokers.

Not quite. My point is more that since the (so far revenue-free) market
already seems to want both solutions, I don't see that a decision is needed.
Deployment has moved on since the v6ops charter was written.

> for making forward progress.

I think you and Christian have pretty much covered the arguments, and 
I don't have anything new to add. These arguments will be very useful, 
when looking at the scenarios, to decide whether the WG should adopt Teredo 
as a work item. 

    Brian

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Alain Durand <[email-masked]>
Date: Wed, 30 Jul 2003 10:10:00 -0700

> Deployment has moved on since the v6ops charter was written.

Well, I think there is a lot of confusion in that space.
We have a number of early adopters who are using both techniques.
However, the number of 6to4 relays and tunnel brokers on the planet is 
still very small,
and the traffic is marginal. I think it is still early in this process.
IMHO, the jury is still out for many ISPs who would like to offer some 
kind of sparse,
commercial IPv6 service without deploying a full scale native 
infrastructure.
So I think it is still pertinent for the IETF to have an opinion on the 
matter
and to recommend one approach versus the other, or maybe both if it can 
be proven
that there are technical reasons to do so.

	- Alain.

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jul 2003 23:08:06 +0200 (CEST)

> Deployment has moved on since the v6ops charter was written.

Given that this group is supposed to:
1. Solicit input from network operators and users to identify
  operational or security issues with the IPv4/IPv6 Internet, and
  determine solutions or workarounds to those issues.  

it sounds like it should gather information about the issues when deploying
existing transition mechanisms, and not just do nothing as you seem to suggest.
 Christian said:
> This is pretty close to recommending operational procedures, and frankly
> that is not what the IETF does best. The IETF shines when it produces
> sound specifications, or thorough technical analyses. But operation
> practices are better left to practicians, which may be another way of
> saying "to the market."

And the charter has:
The IPv6 Operations Working Group (v6ops) develops guidelines for the
operation of a shared IPv4/IPv6 Internet and provides guidance for
network operators on how to deploy IPv6 into existing IPv4-only
networks, as well as into new network installations.

So there seems to be disconnects between both of your views and 
the charter.

  Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 Jul 2003 10:38:32 +0200

Erik,

First of all let me apologise for the tone of my "deleted to save bits"
comment, which sounded dismissive of the discussion between you and
Christian. That wasn't my intention - in fact I have saved that discussion
with every intention of referring to it in the future.

Secondly, I do think that the v6ops charter is probably slightly out
of date - which is good news, since it means that IPv6 deployment
has made progress. I don't think the out-of-dateness is serious
enough to open a rechartering discussion now. 

We should certainly perform the critical review of existing solutions 
and improve them if we can. And even though it's not in the charter,
that should probably include tunnel brokers IMHO.

What I think lies outside the IETF's power is to tell network
operators which solutions to adopt, although of course we can
choose which ones the IETF specifies.

     Brian