Subject: Opportunistic Tunneling

From: Pekka Savola <[email-masked]>
Date: Wed, 11 Feb 2004 20:23:34 +0200 (EET)

Hi,

As the Unmanaged Analysis document is currently at WG Last Call, the
biggest issue appears to be the so-called "opportunistic tunneling",
i.e., automatic tunneling which would be possible without set-up or
ISP support.  Examples of these are 6to4 and Teredo. (No other
specific proposals have been made.)  We need to figure out how to move
forward.  The critical questions are at least:

 1) Do we agree that this is something we need in the first place?
     * Considering user-driven deployment, maybe not.
        - example: the user says "I want to use application X" or "I 
          want to use functionality Y", where X or Y would require 
          IPv6.
     * Considering large-scale vendor-centric deployment, probably 
       yes.

 2) What are the models for deploying relays, considering the economic 
    or deployment considerations (in-host, in-site, network)?
     * And what are the implications of any approach?
     * Can we decide on the recommended model?

 3) For NAT traversing, opportunistic tunneling, are there any 
    features in Teredo which are missing or are unnecessary? I.e.,
    how good a fit would it be?  Are there alternatives?

We're soliciting input on how to best handle this situation.  Please
send feedback to the chairs or on the list.  Tentatively, we're
scheduling 20-30 minutes for discussion in Seoul, but how productive
such discussion would be would depend on the framing and the contents
of presentations and/or discussion.
                                                                                          
Please send your ideas (if any).
                                                                                          
 Thanks,
  Pekka & Jonne

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 12 Feb 2004 05:16:52 +0900 (JST)

>     how good a fit would it be?  Are there alternatives?

	4) security implication of such technology.  for instance, 6to4 relay
	   router can easily abused.  how about Teredo, and other technologies?

itojun

---

From: Pekka Savola <[email-masked]>
Date: Thu, 12 Feb 2004 00:10:38 +0200 (EET)

On Thu, 12 Feb 2004, Jun-ichiro itojun Hagino wrote:
[...]
> 	   router can easily abused.  how about Teredo, and other technologies?

Certainly, this is an important factor.  However, problem with
"security" is that we must somehow be able to quantify and evaluate
it.  How much is enough?

A couple of possibilities w.r.t. deployment have been proposed 
earlier, which mitigate this; at least:

 a) don't deploy relays at all, period.  Users of a transition
    mechanism can only talk to the users of the same transition 
    mechanism.  Creates separate IPv6 Internets, but is not 
    necessarily only a bad thing.

 b) deploy relays, if possible "internal to the node".  I.e., 
    recommend that all dual-stack nodes include some kind of 
    minimalistic relay functionality.  Similar to above, implying that 
    all nodes would act similarly has having all the transition 
    mechanisms. (This works with Teredo, but not with 6to4.)
 
 c) deploy relays inside the dual-stack sites, not in the general 
    Internet.  This might lower the abuse problems a little bit. (The 
    relay is held responsible for abuse.)

[ and the current thinking, at least with 6to4 : ]

 d) deploy relays anywhere in the Internet.

Only, options b) through d) seem to be against economic realities (see
the unmanaged analysis document) and shifting the burden of transition
mechanisms to those who implement proper dual-stack, and a) would be
creating separate Internets.

It's worth remembering my point about "user-centric" vs.  
"vendor-centric" deployment models.  With vendor-centric, a mechanism
like 6to4 or Teredo is a pretty much a must.  With user-centric,
that's not necessarily the case.

We have only bad choices, I fear.

-- 
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: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Tue, 17 Feb 2004 09:44:51 +0100

Hi all,

I believe proto-41 is also one of the proposals on the table for both unmanaged and 3GPP.

For example, TSP can make use of it. We also have a Tunnel Broker implementation that does.

Trying to answer to your questions, in my opinion, and I know other people with same or similar thoughts, this work for unmanaged, 3GPP and other scenarios is required.

When users start moving with IPv6 devices, we need to ensure that they are able to use it, despite what network they are sitting on.

I've this experience myself, traveling ... and I can solve it manually most of the time, but the users don't know how to. It should be automatic.

There are already applications that only work with IPv6, a few at the time being, but more coming, for sure. The reason is that you need addresses, for example to access multiple devices that are located behind a NAT box.

If those devices have IPv6, even with a tunnel, that's fine, it works. I can tell you as I know very well, I've my home connected like that :-)

In Euro6IX we are already working around this idea, but we don't have a draft ready for this meeting, unfortunately. Basically we call it "auto-transition". We need to ensure that the best possible transition mechanism work automatically at any time, in any network. At the same time we need to look were to deploy the 6to4, Teredo, or other relays (or equivalent), how to announce/select them even depending on their load, bandwidth, ..., for example using BGP, anycast, DNS, .... We also are studying the business case of that models (including deployment in IXs). If needed, I've a few slides about this.

Regards,
Jordi

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 11, 2004 7:23 PM
Subject: Opportunistic Tunneling

> Please send your ideas (if any).

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

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 18 Feb 2004 16:04:54 -0800

Pekka & Jonne,

>specific proposals have been made.)  We need to figure out how to move

I thought ISTAP fell into this category as well?  There have been a seres 
of drafts.

>      * Considering large-scale vendor-centric deployment, probably

Yes, it is needed.  Not all ISPs will initially offer IPv6 and having these 
tunneling mechanism will allow people to still use IPv6 without any direct 
action of their ISP.  I think this is essential to getting IPv6 used by 
people and to encourage new applications.  I also think it will have the 
effect of encouraging ISP to deploy native IPv6 once the see the automatic 
tunneled traffic growing.  I don't think we want these "transition 
mechanisms" to be around forever (or even a long time) as we know their 
limitations, but I think they are very important the beginning of the 
transition.

>      * Can we decide on the recommended model?

I think the answer to this can be found by looking at what is deployed 
now.  In any case, I didn't think the IETF needs to be discussion economic 
models.

>     how good a fit would it be?  Are there alternatives?

Given there is already a lot of operational experience we should 
standardize it now.  It can be revised later based on additional 
operational experience.  There isn't any reason to delay this further.

>We're soliciting input on how to best handle this situation.  Please

I think that these mechanisms should be standardized as soon as 
possible.  There is a need and people are already staring to ship these in 
products.  There should be open standards for the mechanisms to allow 
everyone to deploy and use them if they want to.

>such discussion would be would depend on the framing and the contents

Thanks,
Bob

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Feb 2004 12:54:56 +0200 (EET)

Hi,

Thanks for the feedback.  Two comments inline.

> I thought ISTAP fell into this category as well?  There have been a seres 

No, ISATAP is not really applicable AFAICS.  Remember that the topic
here is "opportunistic tunneling" -- with a requirement that the
tunneling works independent of ISPs, automatically.  ISATAP requires
ISATAP router and set-up.

On the other hand, when your ISP wants to give you IPv6 access using
tunneling, ISATAP could be on the table (but that was a separate
subject).

[...]
> now.  In any case, I didn't think the IETF needs to be discussion economic 

Economic models, to an extent, make deployments realistic (or not), so 
I personally think this is somewhat of a factor in the discussions 
whether to recommend some model for deployment.  Of course, the IETF 
cannot _force_ anyone to a model.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 19 Feb 2004 16:34:24 +0200 (EET)

Responding a to few points you raised..

> implementation that does.

Note that while proto-41 forwarding is probably useful in e.g. 
unmanaged scope in general, it is not really applicable to this 
specific topic, "opportunistic tunneling", where the tunneling is 
autoomatic, and requires no supporting ISPs.  E.g., tunnel brokers are 
out of scope for this topic.

Ignoring proto-41 however...

[...]
> When users start moving with IPv6 devices, we need to ensure that
> they are able to use it, despite what network they are sitting on.
> 
> I've this experience myself, traveling ... and I can solve it
> manually most of the time, but the users don't know how to. It
> should be automatic.
> 
> There are already applications that only work with IPv6, a few at
> the time being, but more coming, for sure. The reason is that you
> need addresses, for example to access multiple devices that are
> located behind a NAT box.

I totally agree (about part of your statement) that tunneling should 
just work, whether the user is behind NAT or not.

However, regarding this discussion, I'm not sure if you're actually 
taking a stance whether you you believe a mechanism like 6to4 or 
Teredo is *required*.  That is, do you think the users must be able to 
switch on IPv6, without any interaction with any ISP, and have it work 
(at least with a subset of other IPv6 users)?  Or do you think the 
user can be required to get a "tunnel broker" -like service (or 
whatever) from some ISP explicitly?
 
[...]
> In Euro6IX we are already working around this idea, but we don't
> have a draft ready for this meeting, unfortunately. Basically we
> call it "auto-transition". We need to ensure that the best possible
> transition mechanism work automatically at any time, in any network.
[...]

Yep -- this is pretty important work, and one important issue in the 
unmanaged evaluation document (spanning both "opportunistic" and

---

From: Fred Templin <[email-masked]>
Date: Thu, 19 Feb 2004 09:36:00 -0800

Pekka Savola wrote:

>No, ISATAP is not really applicable AFAICS.
>
Just to be sure we're on the same page, the current ISATAP
draft version is: 'draft-ietf-ngtrans-isatap-20.txt'.

Fred L. Templin
[email-masked]

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Fri, 20 Feb 2004 01:56:14 +0100

Hi all,

My reply in-line.

Regards,
Jordi

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "JORDI PALET MARTINEZ" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 19, 2004 3:34 PM
Subject: Re: Opportunistic Tunneling

> Ignoring proto-41 however...

It will depend on what we consider "opportunistic". For me is clear that we can have tunnel brokers that work like 6to4, i.e., no user registration. Then you use proto-41 (or other means) ... also TSP here can play the game, if no user authentication is required.

> whatever) from some ISP explicitly?

Yes, I believe 6to4 and Teredo (or equivalent alternatives), are required.

And yes, users have the right to switch to IPv6 w/o any ISP interaction.

Is the ISP business to provide a better service, add value, and gain or lose users, and hopefully they will do, but not all them will do initially until there is some number of users.

The user can also choose to access via a TB or equivalent service.

I'm not convinced however that we should have the users willing to access IPv6 isolated from the rest of the IPv6 users ...

> unmanaged evaluation document (spanning both "opportunistic" and 

I miss the end of your sentence ;-)

We will try to have something for the next San Diego meeting.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 23 Feb 2004 11:19:16 +0200 (EET)

On Fri, 20 Feb 2004, JORDI PALET MARTINEZ wrote:
> It will depend on what we consider "opportunistic". For me is clear
> that we can have tunnel brokers that work like 6to4, i.e., no user
> registration. Then you use proto-41 (or other means) ... also TSP
> here can play the game, if no user authentication is required.

I guess this could be possible in theory.  User authentication will 
probably always be there, though.  The user and the ISP have to set up 
some kind of authentication to ensure that nobody else can hijack the 
tunnel, at least -- not considering the non-technical requirements, 
such as the economic (non-incentive) for deploying such an anonymous 
tunnel service, which would probably lead to a lot of trouble in the 
long run (abuse reports from your netblock, increased traffic ~= 
bigger payments to your transit operators, etc.).

So, this approach would seem to have both technical and non-technical
constraints why its feasibility is a bit questionable.

---

From: "Jeroen Massar" <[email-masked]>
Date: Tue, 24 Feb 2004 01:39:40 +0100

-----BEGIN PGP SIGNED MESSAGE-----

Pekka Savola wrote:

<SNIP>

A small non-techy, economic story...

> bigger payments to your transit operators, etc.).

Seeing Tunnel Brokers like Freenet6, Hurricane, BTExact and SixXS being
around for more than 3 years now does seem to answer the question if
it is still feasible to provide such a service. The ISP's involved in
these projects who are donating the bandwidth, resources and probably
the most costly of them all, manpower, apparently have a benefit or
don't see it as a big economic burden to run these services.
I don't know how the other TB's are run, but SixXS is run purely on
good will, the bandwidth and hardware are sponsored by the ISP's who
run the POP. Currently it is doing about 10mbit/s in total across the
POP's we run and most traffic stays local (non-transit) as we have
multiple POP's in various countries and users get directed to the
network-wise closest POP which is better for latency and costs.

The ideal situation, like 6to4 relay's and webcaches etc. would of
course be when every ISP would run an instance of a TB or 6to4 relay
etc thus spreading the economic burden. Currently we try to keep
users as local as possible, but countries like Poland and Italy have
apparently a big userbase that want IPv6 but no (good) TB/6to4's
there, as they come to us.

Simple calculation of costs for the ISP having users wanting IPv6
and not having any IPv6 TB/6to4-relay: traffic will flow to other
ISP's, these ISP's in turn will have the cost of inbound traffic
and the cost of the TB/relay to the remote IPv6 host. When the
TB/relay is local the ISP connecting the enduser won't have much
costs as it is usually transit, when the traffic becomes transit
and larger volumes the ISP will notice. Either way the ISP's who
do not offer a TB/6to4 relay instance cheaply lift along with
the ones that do.

Thus it would be 'better' for the deployment when multiple
instances of TB's or 6to4 relays would be deployed thus spreading
the costs over these multiple ISP's. Currently there is still not
much traffic and the traffic that is there is mostly local thus
I don't think there is a big incensitive to do this for most ISP's
and that really counts for the ISP's who don't want to take some
time for even looking at IPv6 at all. But when the traffic rates
will rise and the bigger sites start being available over IPv6
it will become costly to run TB's and 6to4's for the ISP's that
are doing it for free now.

Small tech note: we need to have this done seemlessly and easy
for the enduser.

As for the abuse reports: many TB's prohibit access to IRC servers
by blocking ports 6600-7100 or something, the others handle a
'give us valid address and contacting data' and just instantly
shutdown abusers on the first warning, doing the latter does make
it more difficult to get a service but does keep the service a
quality one and keeps abuse low and almost near nill.

Greets,
 Jeroen

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 23 Feb 2004 17:35:16 -0800

> ISATAP router and set-up.

Only to get out of the routing domain. ISATAP end systems will use
opportunistic tunneling directly because ND is not required to acquire the
IPv4 (link layer) address. 

> tunneling, ISATAP could be on the table (but that was a separate

ISATAP should never show up in the public network because it allows use of
RFC1918 addresses. 

> cannot _force_ anyone to a model.

As Bob & Christian have said, the IETF is not in a position to recommend
economic models. Entire industries like cable ISPs will have economic
drivers (like the cost/operational complexity of whole-sale replacement of a
cable modem plant) that will make technologies like 6to4 & Teredo much more
attractive than they would be to a campus or transit ISP. Operating 6to4 or
Teredo relays as an integral part of a cable infrastructure provides a very
simple deployment path. At most the IETF might document that the IPv4 side
of such relays should be restricted to local customers, but even that is
really none of the IETF's business.

Tony

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 23 Feb 2004 21:04:17 -0500

-- Wednesday, February 11, 2004 20:23:34 +0200 Pekka Savola
<[email-masked]> wrote/a ecrit:

> specific proposals have been made.) 

TSP.

> We need to figure out how to move

TSP does nat traversal and does not have the same security concerns as
teredo.

in the anonymous mode of TSP, TSP is as automatic/opportunistic as
teredo/6to4/isatap. all of them requires the prior (static) knowledge of an
IPv4 address. Most of them may have some ways to get the nearest/best
service, based on some techniques.

Marc.

>  Please send your ideas (if any).

------------------------------------------
Marc Blanchet
Hexago
tel: +1-418-266-5533x225
------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 23 Feb 2004 21:07:26 -0500

> out of scope for this topic.

- why? 
- again, TSP in anonymous mode is as automatic as isatap/teredo/6to4: the
clients all need the knowledge of at least one IPv4 address. (One of them
needs two, but that is not the point).

- with TSP, you could "upgrade" to authentication which would provide you
additional functionalities, such as permanent ip address, prefix delegation
for your mobile network, etc... 

Marc.

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 23 Feb 2004 21:09:42 -0500

> bigger payments to your transit operators, etc.).

in TSP anonymous mode, one can filter TSP requests to his own autonomous
system. This is really just a management function, not related to the TSP
protocol itself. 

in TSP authentication mode, then the AAA database is used.

> constraints why its feasibility is a bit questionable.

TSP is deployed live in many organisations at this point. 

Marc.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Feb 2004 08:34:00 +0200 (EET)

> service, based on some techniques.

I think there is something in the "opportunistic" vs "tunnel service"  
distinction that I haven't been able to make clear.

TSP requires that ISPs set up tunnel servers and tunnel brokers.  
6to4 and Teredo don't.  (Teredo server doesn't pass through traffic so
a couple may be enough.)  6to4 works automatically between other 6to4
nodes; TSP does not.  Teredo works automatically between Teredo nodes
after the server has been contacted to get the public IPv6 address.

This is the distinction I tried to make with "Opportunistic Tunneling" 
vs "3GPP UE Tunneling, Unmanaged tunnel service".

The tunnel broker set-up, even in anonymous mode, could possibly be 
pretty straightforward, but nowhere near the same as 6to4. (Which 
works even with relays between 6to4 nodes.)

---

From: [email-masked]
Date: Tue, 24 Feb 2004 15:39:57 +0900

>after the server has been contacted to get the public IPv6 address.

	6to4 requires 6to4 relay routers to be present on the internet,
	otherwise 6to4 won't work (or return route will be very inefficient).
	teredo requires teredo servers/relays to be present on the internet,
	otherwise teredo client won't work.

	i don't see significant difference between 6to4/teredo and TSP.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Feb 2004 09:41:56 +0200 (EET)

> 	otherwise teredo client won't work.

Relay routers are needed to communicate with native Internet, not 
between the users of the same transition technology.

Both 6to4 and Teredo can work, to an extent, when relay routers don't 
exist.  TSP can't.

There is path optimization between 6to4 nodes and between Teredo 
nodes.  There is no such thing with TSP (for the good and the bad).  
I.e., all the traffic must pass through the server/broker.

These are the main differences with "opportunistic" vs
"non-opportunistic" methods.

---

From: [email-masked]
Date: Tue, 24 Feb 2004 16:46:19 +0900

>Both 6to4 and Teredo can work, to an extent, when relay routers don't 

	how useful is the IPv6 internet if you can talk with 6to4 users only?
	i think the argument is bogus.

>I.e., all the traffic must pass through the server/broker.

	i think it causes serious misunderstanding if we characterize this
	property as indication of "opportunistic".  optimization property
	has to be discussed under separate thread.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Feb 2004 10:41:00 +0200 (EET)

Tailed down Cc: a bit..

> 	i think the argument is bogus.

Based on the deployments of Microsoft I guess some do view this as a
sufficient first step.. because you can still use IPv4 to those native
IPv6 users.

I'm not sure whether I agree this kind of fragmentation is a good
idea, but if the intent IPv6 deployment is host-vendor -driven (as
noted in the first message of this thread), mainly based on the desire
to run p2p applications directly, this may be a real consideration.  

> 	has to be discussed under separate thread.

I believe the word, "opportunistic" was in this context coined up by 
Rob Austein, and should be interpreted in the similar way as 
"opportunistic IPsec".  That is, you can talk directly with others, 
not just a [tunnel] server.

By that definition, the "path optimization" seems to be an integral
property of "opportunistic" methods.. because there are other methods,
which require more infrastructure (e.g., tunnel service such as STEP,
TSP, ISATAP etc.) which can be basically close to zero-configured.

I agree that "opportunistic" is probably a confusing term, but I
haven't been able to think of a better one.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 24 Feb 2004 10:51:32 +0200 (EET)

I think the most interesting discussion is what you say about cable 
transition.. but I'm responding to a few other issues for 
clarification as well.

> IPv4 (link layer) address. 

Yep - ISATAP includes the concept of intra-site opportunism.  But as 
it is not opportunistic in inter-domain (which was the point here, the 
ISPs not offering service), it does not seem too interesting.

> economic models. 

I have to disagree with the way people have framed the IETF position, 
while I agree with your statement above.  But I don't think this is 
something to continue on this thread.

> Entire industries like cable ISPs will have economic

Is there anything fundamentally unworkable in the model where the 
cable modem users would use a tool such as ISATAP, STEP or TSP to 
connect to the tunnel server of the cable modem ISP for their 
connectivity?

This seems to fail in three cases only:
 1) if the cable ISP doesn't want to provide IPv6 in the first place 
(not even providing 6to4 relay or whatever).  Based on your comment, 
this doesn't seem a bad concern.

 2) if the traffic between the users at the same ISP grows so high 
that a tunnel server (or multiple servers) cannot carry all the 
traffic, i.e., path optimization would be required.  Personally, I see 
this as an indication that IPv6 would be in serious use and the cable 
ISP would want to start offering native IPv6.  So, this would only 
seem to be the case, if the cable ISP wanted to avoid transition to 
native IPv6 altogether, sticking to 6to4/Teredo for forever .. which 
is not what we want.

 3) if the mechanism (ISATAP, STEP, TSP, whatever) is not implemented 
widely enough in the host software so that it's unavailable to the 
users.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 24 Feb 2004 15:48:39 -0800 (PST)

> after the server has been contacted to get the public IPv6 address.

Pekka,
It seems odd to say that the criteria is "nodes that implement
X can talk to other nodes which implement X without extra infrastructure"
when extra infrastructure is needed for nodes that implement X 
to be able to communicate with nodes that have native IPv6 service.
That seems to forget that the goal is to move towards IPv6
and not stay with X forever.

TSP, teredo and 6to4 all need some infrastructure to be able
communicate with nodes that do native IPv6.
Why is it important to make any finer grain distinction?

   Erik

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 24 Feb 2004 09:19:43 -0500

-- Tuesday, February 24, 2004 08:34:00 +0200 Pekka Savola
<[email-masked]> wrote/a ecrit:

>> teredo/6to4/isatap. all of them requires the prior (static) knowledge of
>> an IPv4 address. Most of them may have some ways to get the nearest/best
> 6to4 

6to4 client needs a relay.
Teredo client needs both servers and relays.
they both have the property of having assymetric routing.
TSP needs a broker/server. Broker can assign tunnels to the nearest tunnel
server.

TSP configures static tunnels. static tunnels have much less/no issues
regarding security in relays and open transits.

6to4 and teredo need relays that are open for transit traffic. The client
rely on the reliability and the overall performance of those for their
traffic. However, nor the client, nor the provider of the client are able
to control these. So, user experience might be/is terrible. 

TSP gives you a production address, not bound to the IPv4 address you have
(temporarily). It also does not expose the NAT mapping in the IPv6 address.
If the node moves to a new subnet, the IPv4 address changes, so the IPv6
address. 

>and Teredo don't.  (Teredo server doesn't pass through traffic so

not quite that simple. Teredo relays are used a lot. see all the
interactions between the nodes. Teredo does not cross symmetric NATs, while
TSP does. If the node is moving to different point of attachments and one
of them is behind a symmetric NAT, no service with Teredo.

> pretty straightforward, but nowhere near the same as 6to4.

why? small piece of code. only need one IPv4 address. that is. both same
level of "straightforwardness".

> (Which

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 24 Feb 2004 09:41:10 -0500

[[ list moderator note: non-member submission to the list ]]

> There is path optimization between 6to4 nodes and between Teredo 

This optimisation is only between nodes that have same technology. Now, if
a 6to4 node wants to talk to a Teredo node, at least 2 relays will be
involved. The actual path will be much worst than with TSP in the worst
case of TSP deployment.

Moreover, for Teredo, optimisation works only with some assumptions. If two
teredo nodes are behind a NAT and are not on the same link, then no
optimisation; moreover, depending on the kind of NAT, they might not be
able to communicate at all! 

> I.e., all the traffic must pass through the server/broker.

TSP works in all cases: with or without NAT, with a symmetric NAT, etc...
Teredo does not work with symmetric NAT. 6to4 does not traverse NAT.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 25 Feb 2004 11:06:34 +0200 (EET)

Tailed down Cc: a bit.

> and not stay with X forever.

Yes, this seems odd, and is very unfortunate, causing a "transition
mechanism lock-in" of two sorts: requirement for implementing
everything, and requirement for keeping everything enabled for a long
time.  

However, unfortunately that seems to be the direction at least some of
the deployment is heading..

Do you see feasible-to-deploy methods which would allow basically
everyone to obtain IPv6 service independent of their ISP?  I'd
certainly want to see one -- as it appears, we only seem to have bad
choices. Because that seems to be the requirement (with the additional
argument, 1), below) causing the inevitability of the abovementioned
effect..

> Why is it important to make any finer grain distinction?

Thanks for bringing this up.  I think there are basically two kinds of
assumptions which argue for the more fine-grained distinction.  Let's
try to see if there are others, or if people disagree about these.

 1) that the traffic between the users of the same mechanism (or
opportunistic mechanisms or dual-stack in general, with glue)  would
be such that tunnel-brokered model would not be sufficient when the
tunnel termination does not occur close to the sources.  That is, the
prime reasons here are probably:

    - using applications with heavy bandwidth requirements, causing
load to the tunnel servers, causing increased costs to the operators
of such servers, even making it unfeasible.  With high latency (see
below), it might also be impossible to even achieve sufficient
bandwidth without major rigging of TCP timers.

    - using applications with delay requirements, implying that a 
direct path between two nodes would be preferred.  This would rule out 
tunnel broker/server -like deployments if the deployment is not 
widespread enough.  Tunnel broker in the US would be unacceptable for 
European users, for example -- and a tunnel broker in the neighboring 
EU country might even be similarly unacceptable if you wanted to do 
VoIP with your neighbor.

    So, this assumption basically implies that if we can reduce the
amount of traffic that has to go through the infrastructure, either
bandwidth or latency-wise, it might be more feasible to deploy this
infrastructure. (One might be able to compare this to the SIP model
where the control traffic goes through some intermediaries, but media
goes through a more direct route.)

 2) 6to4 and Teredo (to a lesser degree AFAIK) are pretty anonymous
services.  When someone abuses using those addresses, there is no ISP
"hosting" the service which would get abuse etc. reports, get
blacklisted if someone behaves badly, etc. -- on the other hand, if
the ISP offers the service to outsiders using its RIR address space,
this will certainly lead to all kinds of nasty administrative
actions.. sooner or later raising the question, "why are we even
providing this kind of service to outsiders for free, if we get
nothing but trouble!?!"

Actually, as mentioned in the unmanaged connectivity requirements
drafts, if we assume that third parties would be giving away tunnel
service for free to anyone, a level of anonymity is desirable (e.g.,
in our network, we do run 6to4 relay, but we will never run a tunnel
broker (well, we could consider tunnel broker for our own customers,
but that's beside the point here)).

Obviously, this requirement is different if your own ISP is offering
this kind of service, or you're entering a contract with the ISP, but
the whole point of this "opportunistic" discussion was being able to
cope in the scenario when your ISP does NOT offer IPv6 services, and
you not being required to "fill any forms" to get IPv6 connectivity.

This is why the fundamental first question in considering the
"opportunistic" tunneling is whether you consider the deployment to be
"vendor-driven" or "user-driven".

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Feb 2004 14:02:01 -0800 (PST)

> you not being required to "fill any forms" to get IPv6 connectivity.

Should I take the above to be the definition of "opportunistic tunneling"?
I'm struggling to understand the motivation for inventing this category thus
having a definition of what it means would be helpful.

Can you also clarify what "fill in any forms" means. Last time I installed
software (I think it was a new version of realplayer) I was asked to register
with name and email address. I wouldn't be surprised if the same thing
is the case when I e.g. upgrade an operating system.
So why is this considered to be too cumbersome given that users already
do it?

Based on my current understanding the "opportunistic" tunneling as a category
doesn't make sense to me.

Once I understand your perspective better I'll try to respond to your other
comments.

   Erik

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 26 Feb 2004 08:38:26 +0900 (JST)

> providing this kind of service to outsiders for free, if we get

	as mentioned in (already expired) transition-abuse draft, 6to4 relay
	routers (provided by ISPs) will get abused by malicious parties, and
	ISPs get blamed for the traffic being generated by the abuse.  i
	strongly disagree with the above statement.

itojun

---

From: Bob Hinden <[email-masked]>
Date: Wed, 25 Feb 2004 16:20:41 -0800

[[ mailing-list moderator note: non-member submission ]]

Pekka,

>"vendor-driven" or "user-driven".

I don't understand the distinction you suggest between "vendor-driven" or 
"user-driven".  Vendors will supply the products that most people will use 
independent of how the products are used.  Most "users" don't write 
specifications or write code.

Is the distinction whether the transition is driven from the middle (i.e., 
an ISP providing native IPv6) or from the edge (via automatic tunneling 
where the users ISP doesn't yet support native IPv6)?  Or something else?

Bob

---

From: Pekka Savola <[email-masked]>
Date: Thu, 26 Feb 2004 08:23:51 +0200 (EET)

> 	strongly disagree with the above statement.

As stated earlier, using 192.88.99.1 fixes some of that.  Of course,
if you source that traffic towards your neighbor, he could send abuse
report anyway ("your network is sending something weird at us!") --
which using a neutral source address obviously does not fix.

I assume you disagree with "no ISP is hosting the service to get abuse 
reports".

Because I'm sure you'll agree the implied fact that if the ISP has to 
choose between:
 1) providing 6to4 relay to anonymous outsiders, with 192.88.99.1 
address, or
 2) providing tunnel service to anonymous outsiders, with its own 
address space

1) seems to be significantly simpler to handle abuse-wise.  Many ISPs 
could do 1), but would never do 2).

This is the critical point.  If we don't do something like 6to4, there
must be a lot of anonymous ISPs offering similar, free and
easy-to-setup tunnel-broker -like service.  Comparison of 1) and 2)  
implies that that such a tunnel server model would be unfeasible.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 26 Feb 2004 08:34:16 +0200 (EET)

Hi,

On Wed, 25 Feb 2004, Bob Hinden wrote:
> "user-driven".

I tried to briefly describe this in the first message of the thread:

====
====

maybe this needs to be expanded; I have tried to describe this at more 
length below.

> Vendors will supply the products that most people will use 

Of course.

> where the users ISP doesn't yet support native IPv6)?  Or something else?

Pretty close, yes.

I think this can be looked at from the perspective of who is driving 
the IPv6 deployment.

If the user wants to use an application (or something else) which
requires or would profit from IPv6, I consider the case "user-driven".  
The user says, "I want to do X", where X requires IPv6.  As the user 
has motivation for getting IPv6 connectivity, (s)he will be willing to 
do some effort to make it happen: e.g., contact his ISP, asking for a 
tunnel or native service, contact a tunnel broker, or whatever.  This 
is the model we've started with, I think.  Automatic mechanisms can 
help here as well, but they aren't strictly required IMHO.

Now, let's look at this from the different angle.  A vendor wants to
start using IPv6 in its products for some specific reason, independent
of what the user thinks.  For example, to simplify its peer-to-peer
applications.  To be able to deploy the new version of the
products/applications in any meaningful way, the vendor requires that
IPv6 connectivity must be available to all or at least significant
portion of the user base.  As there are thousands of ISPs in the
world, with only a few offering IPv6, "managed methods" as described
above are a non-starter.  The vendor requires *something* which will
be able to kickstart IPv6 deployment.  The deployment of automatic
tunneling mechanisms is this something.

Hope this clarifies..

---

From: Pekka Savola <[email-masked]>
Date: Thu, 26 Feb 2004 08:38:53 +0200 (EET)

> having a definition of what it means would be helpful.

I'm having trouble defining it myself, but I think it's probably 
pretty close.  See also the concerns of path optimization which relate 
to this.
 
> So why is this considered to be too cumbersome given that users already

This is a good point, but I think this is obvious.  If the deployment 
is "user-driven", that's fine.  If the deployment is "vendor-driven", 
that seems unacceptable. (See the note to Bob Hinden about elaboration 
of these.)

That is, if the vendor enables IPv6 on the host, the user won't
appreciate a pop-up message, requiring him to fill in some details --
"IPv6 -- never heard of that!?!?".  Likewise, the vendor can't fill 
them either, at least without resulting to forgery or spoofing.

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 26 Feb 2004 11:10:39 -0500

[[ note: post by non-subscriber ]]

-- Thursday, February 26, 2004 08:38:53 +0200 Pekka Savola
<[email-masked]> wrote/a ecrit:

>> Should I take the above to be the definition of "opportunistic
>> tunneling"? I'm struggling to understand the motivation for inventing
>> this category thus having a definition of what it means would be helpful.
> 
> I'm having trouble defining it myself, 

then I would suggest that you write a draft.

>but I think it's probably 
>> Can you also clarify what "fill in any forms" means. Last time I
>> installed software (I think it was a new version of realplayer) I was
>> asked to register with name and email address. I wouldn't be surprised
>> if the same thing is the case when I e.g. upgrade an operating system.
> that seems unacceptable.

I'm even more confused about your statement on user/vendor. Does not seem
to me relevent to our technical discussion.

> (See the note to Bob Hinden about elaboration 
> of these.)
> 
> "IPv6 -- never heard of that!?!?".

well, yes, we all want ipv6 to not be shown on the user interface. However,
playing devil's advocate, it happens a lot in IPv4 and it happened to me on
a cell phone recently... oh well... that is "life"...

seriously, I think we agree that ipv6 connectivity and addressing should be
as transparent to the user as possible. 

However, I don't understand where you are going to. To me, the different
tools we are talking about are similar to that respect: isatap, 6to4,
teredo, TSP are all, from the user point of view (i.e. the cell phone
user), a "driver" in the operating system: i.e. they don't care and don't
have to manage it. And the infrastructure and services to make them usable
are provided by some downstream providers, either the direct one, or
another one  downstream.

Marc.

>  Likewise, the vendor can't fill

---

From: Fred Templin <[email-masked]>
Date: Thu, 26 Feb 2004 10:03:16 -0800

Hello Marc,

Marc Blanchet wrote:

>However, I don't understand where you are going to.
>

I have also been struggling to understand this distinction.

>To me, the different

I agree, however it seems that TSP takes the "high road" and negotiates
tunnel configuration via TCP connections and XML exchanges while the
other mechanisms take the "low road" and use, e.g., IPv6 ND messages.
Under TSP, the number of messages involved in setting up and tearing
down TCP connections, sending the XML, etc. can seemingly become
quite high.

So, if nodes require short-lived tunnels and/or many tunnels to many
different endpoints there could be a significant efficiency advantage
in using the "low road" mechanisms. Whether this can be seen as
a measure of "opportunism" I cannot say?

Fred
[email-masked]

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 26 Feb 2004 13:42:25 -0500

-- Thursday, February 26, 2004 10:03:16 -0800 Fred Templin
<[email-masked]> wrote/a ecrit:

>> have to manage it. And the infrastructure and services to make them
>> usable are provided by some downstream providers, either the direct one,
>> or another one  downstream.
>> 
> 
> tunnel configuration via TCP connections

or UDP. for nat traversal, it does tsp over udp.

> and XML exchanges while the
> Under TSP, the number of messages involved 

one "request" message in XML, one "reply" message in XML.

>in setting up and tearing

- udp is pretty light.

- define high?. XML takes more bytes than binary. But XML is more
extensible. TSP/XML gives you the ability to negociate things that are
useful/required for some scenarios, such as DNS names, dns delegation,
prefix delegation, etc.. Pros and cons. 

> a measure of "opportunism" I cannot say?

looks more as how many bytes you care about consuming for your control
connection. Remember that TSP is only involved at the setup of the tunnel.
So the cost is pretty low compared with the traffic itself.

Marc.

---

From: Fred Templin <[email-masked]>
Date: Thu, 26 Feb 2004 12:46:07 -0800

Marc,

Marc Blanchet wrote:

>extensible.

Yes, the tradeoff between efficiency and extensibility
is a familiar one and worth noting.

>TSP/XML gives you the ability to negociate things that are

But, these things can also be negotiated in other ways.
As you say, pros and cons.

>So the cost is pretty low compared with the traffic itself.

The key point here is amortization of the control traffic
wrt the  user traffic. For short-lived tunnels and/or dynamic
management of many tunnels to many different endpoints,
the amout of control traffic would seem to matter.

Thanks - Fred
[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Thu, 26 Feb 2004 12:18:24 -0800

[[ list administrator note: non-member submission ]]

Pekka,

>tunneling mechanisms is this something.

Actually, it doesn't.  I think they are the same.

The vendor supplies the application requires (or benefits) from IPv6 that 
the user wants to use.  The vendor can supply it so it requires the user to 
acquire IPv6 service, or it build into its product the ability to detect 
existing IPv6 connectivity on the users system and if there isn't there, 
initiate create it via one of the automatic tunneling mechanisms.

Both scenarios are vendor and user.  The only difference I can see is if 
the vendor includes the capability to automatically create IPv6 
connectivity. Both are driven by the user (wanting to use an application) 
and enabled by the vendor (including it in the product).  The vendor can't 
make the user do anything (or even buy it's products).  I don't see the 
distinction you are proposing as being useful.

More importantly in the current world, a vendor who doesn't include the 
capability to create IPv6 connectivity where it doesn't exist isn't going 
to see very much IPv6 application usage.  The number of users on the 
Internet who will know to ask for IPv6 (or anything else technical like 
public addresses in IPv4) is very very small.  How many even know they have 
a NAT....

This is also why I think that standardizing the current set of automatic 
tunneling (or whatever we want to call it) mechanisms is very 
important.  We should stop analyzing the requirements and publish the 
specifications ASAP.

Bob

---

From: Pekka Savola <[email-masked]>
Date: Fri, 27 Feb 2004 09:35:46 +0200 (EET)

> initiate create it via one of the automatic tunneling mechanisms.

(For clarification, in my mail I implied that both the app and the 
host OS is provided by the same vendor.  They could be separate as 
well, of course.  If they are separate, the process is clearly 
user-driven.)
 
> distinction you are proposing as being useful.

I think there is a distinction.  There seems to be a lot of difference 
between:

1) the vendor pushing an updated (free) product to its customers,
"forcing it down their throat for their own best", which requires IPv6
connectivity, and

2) the vendor supplying a new application, or an application developer
supplying an application, which the user may (or may not) want to use,
which would require or profit from IPv6 connectivity. (IMHO, this is
comparable to Erik's RealPlayer point.)

The former, I consider "host-vendor -driven".  The latter,
"user-driven".  (Of course, the vendor will play some role here as
well, but the role is entirely different from 1).

The practical implication I see here is that for 1), automatic
tunneling mechanisms are a strict requirement; tunnel-broker -like
models are optional, but not adequate on their own.  For 2), automatic
tunneling mechanisms may be useful, but not a strict requirement.  
Tunnel-broker -like models are a a possible way to achieve the
solution.
 
> to see very much IPv6 application usage.  

Agree.  But remembering the distinction above, the tools which might
be acceptable to create that connectivity vary depending on whether
the user wants to use an application or not.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 Feb 2004 09:35:56 -0800 (PST)

> distinction you are proposing as being useful.

Agree on all points.

I think vendors can provide the infrastructure in their software that Bob talks
about (detecting existing IPv6 connectivity and prompting the user with "cool
application X needs IPv6 connectivity - should I set up such connectivity?").
Having vendors provide a common framework for this would make their platform
attractive to 3rd party application developpers which want to take
advantage the p2p possibilities with IPv6.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 Feb 2004 09:40:27 -0800 (PST)

> "forcing it down their throat for their own best", which requires IPv6

Do you have an example where enabling this would be a desirable thing?
The examples I can come up with have big brother connotations 
hence I don't see why we need to solve this problem. 

Applications and services can drive IPv6 deployment but it requires
that the applications/services are interesting to the users.
If they are not, why should we piggyback "forcing IPv6 down the user's throat"
on somebody elses desire to "force XYZ down the user's throat"?
That doesn't seem to be in the benefit of the users that IPv6 is
intended to serve.

   Erik

---

From: Jasminko Mulahusic <[email-masked]>
Date: Sun, 29 Feb 2004 14:27:46 +0100 (CET)

> application X needs IPv6 connectivity - should I set up such connectivity?").

would such a framework be a superset of the existing tranisition
mechanisms, where the mechanism to be used would be selected based upon
.... ? or would this actually be a new mechanism?

isn't there one software vendor that is already doing something similar
when the user chooses to activate ipv6? is it something that needs to be
standardized in the ietf?

jasminko

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 29 Feb 2004 17:09:08 -0800 (PST)

> 
> > I think vendors can provide the infrastructure in their software that Bob
> talks > about (detecting existing IPv6 connectivity and prompting the user
> with "cool > application X needs IPv6 connectivity - should I set up such
> connectivity?").
> 

I don't think this is something that needs to be standardized; this
is merely an issue of how the different software components (applications
and the protocol stack) on an implementation interact.

  Erik