Subject: Tunneling scenarios and mechanisms evaluation

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Mar 2004 08:23:33 +0200 (EET)

Hi,

The presentation on tunneling scenarios and mechanisms has now been 
converted to an Internet-Draft.  Some additional text was also added; 
some other minor modifications were made.

As it apparently didn't get announced on Wednesday, it's available 
here:

http://www.ietf.org/internet-drafts/draft-savola-v6ops-tunneling-00.txt

Abstract
   This memo analyses the v6ops scenarios/analysis work (Unmanaged,
   3GPP, ISP and Enterprise) for their requirements for tunneling
   solutions, and analyses the proposed mechanisms on how they might fit
   in these requirements, and discusses possibilities for choosing
   solution(s).

-- 
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: Pekka Savola <[email-masked]>
Date: Thu, 11 Mar 2004 10:13:36 +0200 (EET)

Whoops -- forgive my slip.  The address below was where it WILL be 
available.  For now, it's at:

http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-tunneling-00.txt

Sorry -- and thanks to Tim for pointing the obvious! :)

On Thu, 11 Mar 2004, Pekka Savola wrote:
[...]

---

From: Alain Durand <[email-masked]>
Date: Thu, 11 Mar 2004 15:30:22 -0800

On Mar 10, 2004, at 10:23 PM, Pekka Savola wrote:

> some other minor modifications were made

Couple questions/comments:

1)
Section 4.3:
    Therefore we get that Teredo and STEP is the lowest common
    denominator, after having to take a few tough issues in the
    consideration, with Teredo and TSP coming somewhat behind.

Is there a typo here? Teredo is listed twice.

2)
This draft makes a big issue about direct connectivity and bases
the some underlying recommendations on this.

let me ask: is this really a requirement or yet another nice to have?
What will break without direct connectivity? (in any of the scenarios)
If nothing really breaks, but things are just sub-optimal, then I would 
say this
is not that bad. remember that we are talking about transition 
mechanisms,
they DO NOT NEED to be perfect, if not we will never deploy fully 
IPv6...
So, in a certain sense, suboptimal transition mechanisms can be good in 
the long run ;-)

3) this document acknowledge the importance of things that have been 
implemented
and deployed but treats TSP and STEP as equal. I think this comparison 
is biased.

To be fair, one should compare Tunnel broker & STEP as TSP is a 
particular
implementation of the tunnel broker model that has incorporated UDP 
tunneling.
There are a huge number of users of the many variant of tunnel brokers, 
so it is
a model that has been proven. On the other hand, the document recognize 
that STEP
has never been implemented.

4)
I was not at the last two IETF meetings for family reasons, so I might 
miss something.
However,  here is what I take from the analysis done in this document:

1- There is a clear need for some assisted IPv6/UDP/IPv4 tunnel 
management.
The tunnel broker model seems to work fine as demonstrated by TSP, 
which I regard as an existence proof.
This area need to be standardized, by advancing TSP or an evolution of 
it on the standard track.
Note: With regard to TSP, we are not in a situation of take it or leave 
it. If the ban on developing tools is lifted,
I'm convince that we could design something very quickly if the detail 
analysis of TSP shows
improvement are necessary.

2- Teredo is only necessary when direct connection is mandatory and 
there is no help from the ISP.
if the wg thinks that direct connectivity is absolutely necessary and 
this is a valid scenario, then we should
advance Teredo on the standard track. If not, publication as 
experimental is always an option.

3- Isatap is really interesting in sparse deployment, which are early 
scenario.
If this wg takes another 4 years to look at it, then its value would 
have long been
depreciated...

5)
what about the others, like 6to4? Do we still need this despite the 
issues with the relays?

	- Alain.

---

From: "Jeroen Massar" <[email-masked]>
Date: Fri, 12 Mar 2004 02:22:09 +0100

> Couple questions/comments:

<SNIP>

> This area need to be standardized, by advancing TSP or an 
> evolution of it on the standard track.

I'd rather see the IPv6 in UDP protocol be defined as that is not
included in a draft as it is not documented in any of the old nor
in the new draft (draft-blanchet-v6ops-tunnelbroker-tsp-00) and
I think that it is an interesting thing to have as many of those
so called "NAT-routers" don't support proto-41 forwarding but
do allow forwarding of udp packets on a certain port. This is
basically one of the things that Teredo addresses but that uses
a completely different model and also has signalling included.
The TSPC 1.0 sources provided through the Freenet6 site don't
mention anything about these UDP tunnels either. Having a
standard for these would be a good thing as then the OS's could
be made to support it also and afaik there is no such support yet.
Maybe the above is going to be addressed for -01?
PS: Marc, use 2001:db8::/32 and 192.0.2.0/24 in examples.

Currently I am using tinc in cases where proto-41 doesn't
penetrate the NAT or the firewall, btw think of IPv6 over tinc
over httptunnel's and have IPv6 everywhere you want ;)

As for automatic 'repointing' of tunnels I have written and
implemented draft-massar-v6ops-heartbeat-00 for those cases.
These types of tunnels are proto-41 mind you but the protocol
defined in that draft could easily be made to reconfigure
udp tunnels and the likes as the protocol itself only handles
either a src+dst pair or inner src+dst & outer src+dst pairs,
thus it is not tunneling-protocol bound.

> Note: With regard to TSP, we are not in a situation of take 
> it or leave it. If the ban on developing tools is lifted,
> I'm convince that we could design something very quickly if 
> the detail analysis of TSP shows improvement are necessary.

Is there a ban on developing tools based on TSP? Please elaborate.
I do have another, somewhat more of my own 'problem' with TSP
and that is that I can't seem to make it fit the model of the
SixXS tunnelbroker we are running, which is why we described
our own protocol + tools for configuring clients. Draft not
ready yet though. For configuration only the serverside of
TSP could be implemented, but I guess it would be more reading
the older drafts and the sources of tspc to make that work.

<SNIP>

> what about the others, like 6to4? Do we still need this despite the 

There seem to be a huge amount of traffic here in the Netherlands
going over 6to4, this because there is the newszilla6.xs4all.nl
box that has an open IPv6 NNTP (binary) service. People only need
to type 'ipv6 install' on their XP boxes and they can connect.
Thus I think one should not forget it even though it isn't totally
abuse proof and not easily traceable/debuggable, which is one of
the things I see as a big negative. It also doesn't cross NAT's
but proto-41 doesn't do that either unless the NAT-router is
configured correctly where possible.

Greets,
 Jeroen

---

From: Alain Durand <[email-masked]>
Date: Thu, 11 Mar 2004 18:02:02 -0800

On Mar 11, 2004, at 5:22 PM, Jeroen Massar wrote:

> I'd rather see the IPv6 in UDP protocol be defined

This too needs to happen. The point I'm trying to make is that I see
a clear need to work in the general area of assisted IPv6/UDP/IPv4 
tunneling.
A number of things need to be specified, defining IPv6 in UDP is 
clearly one of them.

> implemented draft-massar-v6ops-heartbeat-00 for those cases.

This also need to be studied further.

> Is there a ban on developing tools based on TSP?

There is a ban that was institute in the last days of NGtrans and that
was carried on in v6ops that forbid to work on transition mechanism as 
wg items
until the scenario document were finished.

I think we are due to lift this ban and restart wg activities in the
general area of assisted tunneling mechanism as it is clear now
that such work is needed to address the scenarios in scope for v6ops.
Delaying this further would be irresponsible.

> the older drafts and the sources of tspc to make that work.

As I said earlier, I view TSP as an existence proof, not necessarily as 
the final solution.
it may be, but it is not proven.

	- Alain.

---

From: Florent Parent <[email-masked]>
Date: Thu, 11 Mar 2004 22:44:49 -0500

> PS: Marc, use 2001:db8::/32 and 192.0.2.0/24 in examples.

Jeroen,
As I stated in a previous email on the list, I'm working on the -01 rev. of 
this draft which will include details on the UDP stuff. Wait a few more 
days.

As for the client source code, the web site client is outdated. Client 
source for NAT traversal is available (GPL) and will appear there at some 
point. Send me an email if you'd like a copy sooner.

Florent

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Mar 2004 09:51:18 +0200 (EET)

On Thu, 11 Mar 2004, Alain Durand wrote:
> There is a ban that was institute in the last days of NGtrans and
> that was carried on in v6ops that forbid to work on transition
> mechanism as wg items until the scenario document were finished.
> 

There has never been a "ban" on working on something.  Only, v6ops and
at the later days, ngtrans, would not take these items as WG work
items.  I don't think discussing such work on either list has ever
been explicitly forbidden (as long as it wouldn't interfere with the
rest of the work).  It has always been OK to continue working on the
proposed mechanisms as individual drafts.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Mar 2004 10:13:07 +0200 (EET)

Thanks for the feedback, Alain.  Responses inline..

> Is there a typo here? Teredo is listed twice.

This is intended.  Based on the analysis, the requirement for Teredo 
exists no matter what else we choose.  The most preferable solutions
in addition to Teredo, however, seemed to be STEP and TSP.

> What will break without direct connectivity? (in any of the scenarios)

When your ISP doesn't offer IPv6 connectivity, but you would have to 
take a "long leg" to get it, it seems that to be able to achieve 
anything useful (e.g., peer to peer connectivity), direct connectivity 
is a real requirement.

On the other hand, when your ISP/operator is offering IPv6 
connectivity, in my eyes it is *not* a strict requirement (and not 
reflected as such in the analysis), because the extra leg that needs 
to be taken is probably in the order of 1-10 ms, not 30-300 ms.  The 
former is still usable, the latter not.

> If nothing really breaks, but things are just sub-optimal, then I
> would say this is not that bad. remember that we are talking about
> transition mechanisms, they DO NOT NEED to be perfect, if not we
> will never deploy fully IPv6... So, in a certain sense, suboptimal
> transition mechanisms can be good in the long run ;-)

I agree that I don't (personally) think direct connectivity is a 
requirement, for reasons you state, when your ISP/operator is offering 
the tunnel service.  I'm not sure which context you're discussing, but 
if you're saying that direct connectivity is not a requirement in the 
cases where your ISP is not offering a service, then I would have to 
disagree due to concerns of scalability for large-scale deployment.

> implemented and deployed but treats TSP and STEP as equal. I think
> this comparison is biased.

Implemented & deployed are tradeoffs among others.  There may of
course be some bias here :).

> particular implementation of the tunnel broker model that has
> incorporated UDP tunneling. There are a huge number of users of the
> many variant of tunnel brokers, so it is a model that has been
> proven. On the other hand, the document recognize that STEP has
> never been implemented.

I have to disagree here.  The tunnel broker is just a concept.  It 
doesn't fly on its own.  It's not even interoperable, which is causing 
a lot of problems.  STEP, as a matter of fact, is also a tunnel broker 
of a kind.

My personal preference would be to create a combination of TSP, STEP
(and ISATAP, to a lesser degree) as a single tunnel server solution:  
providing simplicity of STEP when more complex setups aren't needed,
yet providing (additional, optional?) flexibility of TSP in the cases
where e.g., static prefix is desirable.

IMHO, TSP is unnecessarily heavyweight when all you need is just a
simple IPv6 address.  You don't really need to do all of that
signalling for the basic usage case..

> 4)
>
> I was not at the last two IETF meetings for family reasons, so I
> might miss something. However, here is what I take from the analysis
> done in this document:
> 

Totally agree here.

> which I regard as an existence proof. This area need to be
> standardized, by advancing TSP or an evolution of it on the standard
> track.
>
> Note: With regard to TSP, we are not in a situation of take it or
> leave it. If the ban on developing tools is lifted, I'm convince
> that we could design something very quickly if the detail analysis
> of TSP shows improvement are necessary.

Such ban does not exist, and IMHO it is clear that TSP (or the model
in general) requires a lot of improvement -- I reviewed it some time
ago, and sent feedback on the list.  So far that I'd rather start from
scratch, while keeping the model intact..  But this is something that 
would be very quickly doable, if we want to do it.

> there is no help from the ISP. if the wg thinks that direct
> connectivity is absolutely necessary and this is a valid scenario,
> then we should advance Teredo on the standard track. If not,
> publication as experimental is always an option.

Yep.  Though there was some resistance to moving it along for now in 
the meeting, calling for analysis. (It's interesting, as people were 
previously shouting for moving forward.)

> 3- Isatap is really interesting in sparse deployment, which are
> early scenario. If this wg takes another 4 years to look at it, then
> its value would have long been depreciated...

Did you mean s/really interesting/really only interesting/?

The benefit of ISATAP is providing direct tunneling between the nodes.  
This may be interesting in sparse deployment (compared to 
going dual-stack; but in sparse deployment, tunnel server is also 
fine), and some have even expressed interest in dense deployment 
(compared to dual-stack: not wanting to go there; compared to tunnel 
server: not overloading the server).  IMHO, the dense deployment 
scenario calls for dual-stack, and we should not be hacking to work 
around that.. and sparse deployment can be facilitated by a tunnel 
server.  So, personally, I'm not sure if I see much applicability in 
direct connectivity in this specific "ISP-assisted" context.

> what about the others, like 6to4? Do we still need this despite the 

Unfortunately, I think yes -- in the unmanaged case where there is no 
ISP support ...

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Mar 2004 09:25:33 +0100

Jeroen Massar wrote:
...
> configured correctly where possible.

I think this is about right. I confess that 6to4 was invented as
a provocative technology that would allow some relatively easy
IPv6 deployment without too much "official" support, and
it has succeeded... with some disadvantages as noted. But whether
"we" (v6ops) need it or not, it is there. Personally, I'm
happy to see it sit at PS for a while longer, and publish Pekka's
security addendum as Informational. It really doesn't matter
whether 6to4 is on some approved list or not.

   Brian

---

From: Alain Durand <[email-masked]>
Date: Fri, 12 Mar 2004 08:52:07 -0800

> in addition to Teredo, however, seemed to be STEP and TSP.

Ok, then it just that the sentence is a bit confusing, as you were 
looking at
4 tools, I thought that 2 of them were 'preferable' and the other 2 
were 'not so preferable'

> former is still usable, the latter not.

The length of the 'long leg' may vary. Even if your ISP does not 
provide you
with a tunnel server, this does not mean that you have to go to Canada
to get one! If this model is successful, there will be a good chance 
that
somebody near you could offer tunnel service.
I can even see that as a commercial argument to incite people to switch 
ISP!
This is an economic/deployment issue, not a protocol issue.

> disagree due to concerns of scalability for large-scale deployment.

Please elaborate on this point.  If  your ISP does not help but
a neighboring ISP offer v6 tunnels, what is the problem?

> Such ban does not exist,

In practice it does exist. TSP, for example, did not have the same 
amount of review,
collaborative work as a individual submission as if it would have been 
a wg item.

> and IMHO it is clear that TSP (or the model

Agree. Let's do it.

> Did you mean s/really interesting/really only interesting/?

Yes, typo.

> direct connectivity in this specific "ISP-assisted" context.

Agreed, I have said for about 4 years now that one could use an 
internal TB
to do this.

> Unfortunately, I think yes -- in the unmanaged case where there is no

Well, if there were deployed 'neighborhood' TB that works well, the need
for 6to4 will be somehow lower.

	- Alain.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 12 Mar 2004 15:01:25 -0800 (PST)

> Unfortunately, I think yes -- in the unmanaged case where there is no 

...and there is no IPv4 NAT.

I wonder if we can simplify things by using Teredo in the case when there is
no ISP support whether or not there is a NAT.
If that makes sense we would have to worry as much about how 6to4 and Teredo
boxes talk to each other, but only about Teredo and native talk to
each other.

   Erik

---

From: Pekka Savola <[email-masked]>
Date: Sat, 13 Mar 2004 08:08:51 +0200 (EET)

On Fri, 12 Mar 2004, Erik Nordmark wrote:
> If that makes sense we would have to worry as much about how 6to4
> and Teredo boxes talk to each other, but only about Teredo and
> native talk to each other.

Yes -- I think 6to4 is an optimization for the unmanaged case when 
there happens to be no NAT.

The chief advantage of 6to4 is its simplicity (a minimal -- but
insecure -- implementation can be about 5-10 lines of code!), and the
ability to provide a /48 prefix, instead of being run individually on
each system.  This could be useful especially in the cases where the 
(NAT) gateways would implement some form of IPv6 support.  As Teredo 
cannot support more than one address, it would not be applicable in 
this scope.

The disadvantage is that it's an additional mechanism, and not
applicable except in the space where NAT is often being used; also,
the security properties are worse with 6to4 than Teredo (due to its
simplicity).

Depending on how strongly people feel about the necessity of this
optimization and providing an easy means for (NAT) gateway vendors to
add basic IPv6 support, 6to4 could be retained, or we could try to
figure out whether Teredo spec needs to be re-evaluated for the case
when there is no NAT traversal at all.

Thoughts?

---

From: Pekka Savola <[email-masked]>
Date: Sat, 13 Mar 2004 09:23:24 +0200 (EET)

I'm only responding on direct connectivity / far-away tunnel brokers, 
as I think rest of the points are either trivial or already addressed 
in other mails..

On Fri, 12 Mar 2004, Alain Durand wrote:
> provide you with a tunnel server, this does not mean that you have
> to go to Canada to get one! If this model is successful, there will
> be a good chance that somebody near you could offer tunnel service.
> I can even see that as a commercial argument to incite people to
> switch ISP! This is an economic/deployment issue, not a protocol
> issue.

AFAICS, the commercial argument is the other way around.  That is, if
another ISP close by is offering free service, there is no incentive
to switch to that ISP in the first place.  On the other hand, if an
ISP is offering the service to only its own customers, the others
don't get it anyway, causing the long leg to a first "free" server.

The economics and deployment issues are unfortunately very much
against the 3rd party tunnel server model... even more so than 
deploying e.g. 6to4 relays.

And deployment issues seem to be the fundamental part of the business
of this WG.  There is no use depending on a specific model, if it
seems like that that model would have trouble in getting deployed.

> a neighboring ISP offer v6 tunnels, what is the problem?

The problem is that the neighboring ISP won't offer v6 tunnel to you 
because you're not his customer.

There has been very little 6to4 relay deployment.  And that's even
better for the ISPs to deploy, because the abuse etc. that happens
doesn't come from you 2001:f00::/32 address space.  The ISPs in
general *don't* want to offer their production space address space to
every John Doe that comes knocking on their door.  

Having followed this relay / tunnel deployment for a while, it seems
like that offering these kind of services to outsiders is not seen as
very interesting thing to do.  Sure, there are some who do it in any
case, but more often than not, they're rather far away (and to
optimize that, a "broker discovery" mechanism would not hurt) because
they're so scarce.

If Internet was still this co-operative, non-profit environment, this
kind of "open for all" tunnel broker model would be very efficient..  
but this is not the case, unfortunately..

---

From: Rob Austein <[email-masked]>
Date: Sat, 13 Mar 2004 02:39:45 -0500

> cannot support more than one address, it would not be applicable in 

The 6to4 edge routers I've been using for the last two or three years
do this.  I for one would be unhappy to lose this capability.

> the security properties are worse with 6to4 than Teredo (due to its

With all due respect, the second clause of that sentence is a cheap
shot.  6to4 can be implemented well or poorly and can be used well or
poorly.  Packet filtering works just fine on an edge router if one
bothers to turn it on.  I do not believe that giving 6to4's job to
Terado would really solve any security problems; at best it would
transform them, and in some cases it would probably make them worse by
replacing a simple solution with a more complex one.

> when there is no NAT traversal at all.

Terado is excessively complex for the case of a user who wants IPv6
capability from an IPv4-only ISP and has the ability to replace the
NAT box.  Yes, Terado could probably be used in this case instead of
6to4; pigs also fly just fine, given sufficient thrust [RFC1925], but
that doesn't make either of these a good idea.

Please retain 6to4.

---

From: David Malone <[email-masked]>
Date: Sat, 13 Mar 2004 11:33:16 +0000

On Sat, Mar 13, 2004 at 09:23:24AM +0200, Pekka Savola wrote:
> There has been very little 6to4 relay deployment.

Hating to bang on about it, but I've written up my count of 6to4
relay routers. I'd written it in a style that might suit the Cisco
IPJ, but I'm not sure how well suited it is. I guess it might be
of interest to the working group, if it were in a different format?

Any comments welcome.

	David.

Counting 6to4 Relay Routers
David Malone, CNRI, Dublin Institute of Technology.

Introduction
------------

In the IPv6 world, significant effort has been spent devising ways
for people to use IPv6 in the absence of a complete IPv6 infrastructure.
Maybe the best known example of this involves forming a virtual
point-to-point link by encapsulating IPv6 packets in IPv4 packets
and sending them from one point in the existing Internet to another.
This is technology that we can all relate to: it looks just like
any other point-to-point link.

Some issues have become apparent with the use of point-to-point
tunnels. First, they have properties like the traditional links on
which they are based: they need the agreement of parties at either
end regarding configuration details and arrangements must be come
to over addressing and routing. The second issue is that, unlike
real point-to-point links, a tunnel can stretch between arbitrary
points in the Internet resulting in highly unpredictable link
properties. This can lead to packets taking a scenic route, and
so people now prefer to only use tunnels between topologically
close sites.

6to4 is another way of routing IPv6 packets over the IPv4 Internet.
6to4 has been described elsewhere[1], so we will just give a flavour
of it here. Much like point-to-point tunnelling, sites using 6to4
have a router responsible for decapsulating and encapsulating
packets. However, 6to4 assigns IPv6 addresses based on a public
IPv4 address of this 6to4 router. Thus, when a 6to4 aware node gets
an IPv6 packet destined to any 6to4 address, it immediately knows
which IPv4 address the packet should be tunnelled to. 6to4 aware
nodes that are willing to perform this tunnelling advertise a route
to 2002::/16, the IPv6 prefix containing all 6to4 addresses. These
nodes are known as 'relay routers' and form a bridge between the
IPv6 and IPv4 Internet.

This explains how packets make their way from the IPv6 Internet to
6to4 networks, and also how packets are routed between 6to4 networks
associated with different IPv4 addresses. The remaining part of the
puzzle is how packets from 6to4 networks get back to the IPv6
Internet. Originally, you had to know the IPv4 address of a relay
router[2] and you would configure your 6to4 router to encapsulate
any traffic to the IPv6 Internet and send it to a specific 6to4
router. Naturally it would be better if this could be done
automatically, without having to choose a relay. In a similar way
to how relay routers advertise themselves in the IPv6 network, a relay
router can now advertise itself in an IPv4 network by advertising
the address 192.88.99.1[3]. This is an IPv4 anycast address that
could be thought of as representing the IPv6 Internet in the IPv4
network.

6to4's design does work around some of the problems that have come
up with point-to-point tunnels. First, it can be automatically
configured once you have a public IPv4 address without any configuration
to be performed "at the other end". Second, it uses the existing
IPv4 and IPv6 routing infrastructure to find the nearest 6to4 relay
router, providing some automatic adaptation to the state of the
network. Note that this may not completely eliminate scenic routing
as the relay router may be some distance from the packet's eventual
destination.

From this picture of 6to4, it should be clear that the relay routers
are essential to the operation of 6to4, in a similar way that the
DNS root servers are essential to the operation of DNS. The more
relay routers that are available throughout the network, the smoother
and more reliable the operation of 6to4 will be. Consequently, the
the number of 6to4 relay routers available is something that impacts
on the ability of 6to4 to provide IPv6 connectivity.

How to count relay routers
--------------------------

There are a small number of 6to4 relay routers that make themselves
very obvious by advertising themselves in the IPv4 BGP routing
tables using the anycast address 192.88.99.1. Perhaps the best known
of these is the one at SWITCH, the Swiss Education and Research
Network, but on any day there are a number of networks offering
6to4 relay services. One snapshot from the Route Views project[4]
shows the following autonomous systems (ASs) advertising 192.88.99.0/24:

	AS559   SWITCH
	AS1741  FUNET
	AS3246  SONGNETWORKS
	AS8379  CYBERNET-AG
	AS9033  ECIX-AS
	AS12859 NL-BIT
	AS17832 SIXNGIX-AS-KR
	AS30155 KLU

However, this is not the whole story. To begin with, the list of visible
relay routers in IPv6 BGP may not be the same, for example, by looking at
several IPv6 looking-glasses we see the following ASs advertising routes
to the 6to4 prefix, 2002::/16:

	AS109   CISCOSYSTEMS
	AS559   SWITCH
	AS786   JANET
	AS9264  ASNET
	AS12859 NL-BIT
	AS17715 CHTTL-TW
	AS24895 FUBAR

More interesting is that some network providers may choose to provide
a 6to4 relay that is only available internally, by advertising the
192.88.99.0/24 and/or 2002::/16 within their own AS (or possibly
only to selected BGP peers). In these cases it is less likely that
these routes will ever be visible in a project like Route Views.
However, if 6to4 turns out to be a popular method for the connection
of IPv6 end sites, it seems a significant number of 6to4 users could
be supported by such private relays.

So, how can we estimate the number of 6to4 relays that are actually
in service? The ideal way would be to traceroute to 192.88.99.1
from various points in the Internet and see where those traceroutes
lead. Similarly, tracerouting from points in the IPv6 Internet to
some address in the 2002::/16 range would reveal the IPv6 side of
6to4 routers. This could be undertaken using a facility like
PlanetLab[5].

However, a practical way presents itself that does not require any
special facilities. Consider what happens if we traceroute in with
a source address that is a 6to4 address. As packets (ICMP TTL
exceed) are sent from each hop, they will make their way to the
nearest relay router accepting packets for 2002::/16. This router
will encapsulate the packet and send it to the appropriate IPv4
address. By collecting these IPv4 packets at their destination and
examining the source address used for encapsulation, we will get
the addresses of the 6to4 relays along the path we are tracerouting.

Targets for such a traceroute are relatively easy to find. In the
IPv6 world a network provider is generally represented by a single
prefix in the global IPv6 BGP tables. This routing table is still
relatively compact, containing less than 1000 prefixes. By
tracerouting to the first address in each range, it seems likely
that a packet will make its way into the organisation's network and
the ICMP message will make its way to the nearest relay to that
organisation.

Doing the count
---------------

Performing the count described above is relatively straight forward.
A list of prefixes can be obtained from your nearest friendly IPv6
BGP speaker. Packets can be collected on a target 6to4 host using
tcpdump, and traceroute can be run with appropriate options. The
IPv4 addresses can then easily be extracted. The whole process can
be completed in a few hours without stressing a modest DSL connection.

In practice, most of the returned packets are accounted for by a
rather small number of encapsulating IPv4 addresses. Among these
is 192.88.99.1, which obviously may account for a number of relays.
As an anycast address, 192.88.99.1 should probably not appear as a
source address, however for reasons related to both operational and
software it does.

Trying to resolve the relays replying using 192.88.99.1 seems
important, as it may account for a significant number of relays.
This can also be done with traceroute. Consider a node that traceroutes
to a 6to4 address - the last hop before the decapsulating router
will be the relay router. Just as with IPv4 loose source routing,
IPv6 provides a way to traceroute via a particular node (using
routing headers). So, by tracerouting via nodes whose relay router
replied using the the anycast address, we can find IPv6 addresses
associated with that relay router.

Note that a single relay router may have many IPv4 and IPv6 addresses.
Manual inspection suggested that IPv4 addresses (other than
192.88.99.1) represented distinct single relays. This is probably
due to source address selection being applied consistently for a
fixed IPv4 destination when encapsulation takes place on a particular
router.

For the relay routers that replied using the anycast IPv4 address,
we also determined their IPv6 addresses. This list contained groups
of addresses that obviously belonged to the same router. This is
due to the traceroute replies being generated by a particular
interface, probably the one on which the expiring packet arrived.
To account for these duplicates, only the first 32 bits of the IPv6
address was considered, and then these were checked in the whois
database to eliminate duplicates caused by relays that use both
6bone (3ffe::) and production (2001::) prefixes.

Results of the count
--------------------

The first count was performed in July 2003 and produced a list of
26 different IPv4 addresses, including 192.88.99.1. Trying to
resolve 192.88.99.1, using the technique we described above, produced
a list of 12 /32s. Of these 12, two were SWITCH. This gives a total
of 37 different relay routers identified by the count. One relay
router was systematically missed because it was within two hops of
the node performing the count.

The count was repeated in January 2004 and again produced a list
of 26 different IPv4 addresses. However, this time a 18 different
/32s were found behind the anycast address (without the duplication
of SWITCH). Interestingly, a number of distinct relays were found
in the same /32, in space assigned by RIPE to IXPs. This suggests
a figure around 44 relay routers. In this second count, two relay
routers were missed because they were within two hops of the node
performing the count.

The following breakdown was produced by attempting to assign relay
routers to countries using whois. The breakdown includes the relays
that were systematically missed.

		July '03	January '04
AU		1		1
CA		0		1
CH		1		2
CZ		1		0
DE		4		9
EE		1		1
ES		0		1
EU		0		2
FI		2		2
GR		0		1
IE		3		3
IT		0		1
JP		2		1
KR		3		2
LT		2		2
LU		0		1
NL		4		1
NO		1		1
PT		1		2
SE		2		2
TH		1		3
TW		2		1
UK		3		4
US		4		2
Total		38		46

Conclusions and Remaining Issues
--------------------------------

It seems that, in addition to the handful of publicly advertised
6to4 relays that are available, there are also quite a number of
additional private relays in operation. This is good news for
people using 6to4, meaning they are more likely to get a router
close to them.

The list of countries does seem to be biased towards Europe. At
least part of this is likely to be systematic bias - the count was
performed from a European IPv6 network, and packets are more likely
to take transit through European networks, and so find European
relays. It is also possible that the deployment of native IPv6 is
further ahead in other parts of the world, and consequently 6to4
relays are consequently less common.

What isn't clear from this count is how wide the domain of attraction
for each of these relays is, how many clients each serves and how
the traffic load is distributed between them. As commented earlier,
a large number of packets are being returned through a small number
of relays, particularly one relay in Japan.

Perhaps the biggest weakness of this count is that it is possible
(though unlikely) that the relays that take packets from the IPv6
Internet to the IPv4 Internet are completely unrelated to the relays
that send packets in the opposite direction. Some asymmetry has
already been noticed in this area, where publicly advertised
relays often see much more traffic going from IPv4->IPv6 than
IPv6->IPv4. A reasonable explanation for this is that many sites
with native IPv6 connectivity also have some IPv4 connectivity, and
so can run a private relay. Consequently, it would certainly be
interesting to know how many hops the average user has to go to
find a machine listening on 192.88.99.1.

References
----------

[1] Connecting IPv6 Routing Domains Over the IPv4 Internet
Carpenter, Moore and Fink,
Cisco Internet Protocol Journal Volume 3, Number 1, March 2000

[2] Public 6to4 Relay Routers
Sayer,
http://www.kfu.com/~nsayer/6to4/

[3] An Anycast Prefix for 6to4 Relay Routers
Huitema,
RFC 3068, June 2001.

[4] University of Oregon Route Views Project,
Advanced Network Technology Center,
http://www.routeviews.org/

[5] PlanetLab,
http://www.planet-lab.org/

---

From: Tim Chown <[email-masked]>
Date: Sat, 13 Mar 2004 11:39:38 +0000

How do you know how many relay routers exist?   All you can count are ones
that ISPs/NRENs choose to advertise beyond their borders?

Tim

---

From: bill <[email-masked]>
Date: Sat, 13 Mar 2004 03:50:07 -0800 (PST)

> Pekka Savola

	reading the above sentence... its the most humourous thing
	i've read all week. perhaps what Pekka intended to say was
	that the security properties of 6to4 are more knowable than
	Teredo due to its simplicity.  Most folks believe that if
	you can know the properties of some bit of code, its more
	secure than code that is too large/complex to understand well.
	Or perhaps Pekka ment something else...

--bill

---

From: "Jeroen Massar" <[email-masked]>
Date: Sat, 13 Mar 2004 14:14:02 +0100

Pekka Savola wrote:

<SNIP>

Giving some insight on this as seen from the SixXS project...
If you think this is marketing hype thing alike skip this message
there is no commercial thing in the project and it is all on a
free/goodwill basis with the main target of providing IPv6 deployment.

> because you're not his customer.

In general this is actually what we are doing. The red line though
is that people should provide full contact address information and
that their endpoint has a latency of less than 100ms.

> every John Doe that comes knocking on their door.  

I personally think that that is actually one of the things *against*
6to4, it is totally untraceable/debuggable as one never knows where
packets are going to flow to/from as there just might be one or even
more hidden 6to4 relays along the route.

Next to that apparently many users *demand* RIR space, they think
it is cooler or works better. There are even people who are proud
to have inet6num's ;)

As for abuse, in case of SixXS, it has been at an all time low
fortunatly and we haven't heared a complaint for quite some while
(*knock on wood*) but that could be because of the quite strictness
with which users are accepted and the fact that they know that they
are out and are kept out of the system when they have commited it.

> optimize that, a "broker discovery" mechanism would not hurt) because

The 'discovery' mechanism we use for the SixXS project is quite simple
though absolutely not automated: users signs up through the website
and gives it's details, thus we know his address+country + IP, then
after being approved they can request a tunnel, again we get an IP.
Then the system 'asks' the POPs who is willing to serve that IP.
The POPs that want to serve the user then display them selves and
the user can select it, again a manual approval based on lowest
latency/least hops and some other criteria. The approvals are
web or cli based thus admins only select from some default answers.

> but this is not the case, unfortunately..

SixXS currently has 11 POPs across europe and for the exception of
two of those they are all open and providing IPv6 to quite a number
of users who seem to be very happy about the service, you only
hear them complain when it breaks, which happens only about once
a year when there is some odd hardware failure. Generally a POP
only serves the users of that country, unless it is the closest
POP for a user where there are no POPs in the country.

Or in numbers: (http://www.sixxs.net/misc/usage/)
The 1747 users span 44 countries.
The 1649 tunnels span 35 countries.
Currently there are 923 subnet delegations over the tunnels.
In the these numbers deleted and disabled tunnels are not counted.

I do have to add that we are apparently in quite a unique
situation as as far as I know of there are not that many
public Tunnel Brokers in the US/Asian parts of the world.

First 27 pages of a google on "tunnel broker", sorted on
region and order of appearance in google:

US:
 1 Hurricane (http://ipv6.he.net)
 2 Freenet6 (http://www.freenet6.net)

Europe:
- - BT Exact (http://tb.ipv6.btexact.com)
- - Dolphins (http://tunnelbroker.as8758.net)
- - XS26 (http://www.xs26.net)
- - ngNet.it (http://tb.ngnet.it)
- - Estpak (http://www.ipv6.estpak.ee)
- - Euro6ix (http://www.euro6ix.org:8080/tb/)
- - FCCN/IPv6-TF.pt (http://ipv6-tf.com.pt/tunnel/)
- - SixXS (http://www.sixxs.net)
- - Berkom (http://fix.ipv6.berkom.de/cgi-bin/tb.pl)
- - Netgroup.dk (http://noodle.ngdc.net/~hroi/tb/)
- - Coredumps (http://tb.coredumps.org/)

Asia/Australia:
- - Manis (Beta; http://tbroker.manis.net.my)
- - SingNet (http://tunnel-broker.singnet.com.sg)
- - AARNet (http://broker.aarnet.edu.au)
- - SJTU.edu.cn (http://tb.sjtu.edu.cn/)
- - ASCC (http://tb.ipv6.ascc.net/)
- - NGIX (http://tb.ngix.ne.kr/cgi-bin/tb.pl)

19 and there are probably a couple of others, as to
how and if they work and how stable they are that is
up to their respective users. It might be interresting
to know how many active/used tunnels are being used
around the globe though as that might indicate a bit
if there is a demand and how it could be fulfilled.
Statistics on how these TB's are used could also prove
interresting. Policies of these brokers might differ
btw to be open or closed or they only might serve to
a certain region and have other regulations in hand.
Next to that there are bound to be private TB's which
are not to be found in google.

Greets,
 Jeroen

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sat, 13 Mar 2004 17:28:56 +0100

There is one more TB at 
http://tb.consulintel.euro6ix.org
and http://www.6sos.org

Regards,
Jordi

----- Original Message ----- 
From: "Jeroen Massar" <[email-masked]>
To: "'Pekka Savola'" <[email-masked]>; "'Alain Durand'" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, March 13, 2004 2:14 PM
Subject: RE: Tunneling scenarios and mechanisms evaluation

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Pekka Savola wrote:
> 
> <SNIP>
> 
> -----BEGIN PGP SIGNATURE-----
> Version: Unfix PGP for Outlook
> Comment: Jeroen Massar / http://unfix.org/~jeroen/
> 
> iQBGBAERAgAQCRApqihSMz58IwUCQFMJGgAAlwcAnisbsI75IPYnbnVTs1SqwxkV
> USPPAJ9MwuxWg52PZTeaxtuixjrbGzZAqA==
> =h9IU
> -----END PGP SIGNATURE-----
> 

**********************************
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: David Malone <[email-masked]>
Date: Sat, 13 Mar 2004 19:31:51 +0000

> that ISPs/NRENs choose to advertise beyond their borders?

It is explained in the writeup - you look for people who are willing
to encapsulate packets destined to 6to4 addresses by tracerouting to
various parts of the 6to4 network and seeing who encapsulates the
ICMP TTL unreachables.

	David.

---

From: David Malone <[email-masked]>
Date: Sat, 13 Mar 2004 19:45:54 +0000

> various parts of the 6to4 network and seeing who encapsulates the
                       ^^^^^ IPv6

---

From: Pekka Savola <[email-masked]>
Date: Sat, 13 Mar 2004 22:37:15 +0200 (EET)

Hi,

I think this message was useful; let me try to respond to some 
comments inline..

On Sat, 13 Mar 2004, Jeroen Massar wrote:
> In general this is actually what we are doing.

Sure; I didn't want to say that such nice folks don't exist.  I just
was arguing that they aren't that commonplace, may be difficult to
find (especially to those not familiar with IPv6!), may not use the
same mechanisms at the tunnel broker (making client software
deployment a mess), etc.

Remember, our goal is not get IPv6 deployed to those guys who are
reading this mailing-list and can do a lot of technical stuff to set
things up.  The target audience (which I have in mind at least) is
much more "dumber" than that.  I'd like to aim for the case where the
most the user would have to do is click an "activate IPv6" icon on the
desktop or network settings -- and not necessarily even that.  That
function should try to send route solicitation on your link, find a
free tunnel broker provided by your own ISP, or set up 6to4/Teredo all 
else failing.

> more hidden 6to4 relays along the route.

From one perspective, yes.  From the ISP perspective, maybe not.  
That is, 6to4 is rather an anonymous mechanism: you can provide it to
third parties without them getting your IP addresses, without you
getting complaints about abuse, etc.  -- it's much simpler to set up
for outsiders in many ways than a tunnel broker.

> it is cooler or works better. There are even people who are proud

Certainly, the users want RIR space.  But the question was what the
ISPs want to *GIVE* to folks that are not their customers.  We, as an
ISP, certainly don't want to give 3rd party users *our* address space.  
Many tunnel brokers today that exist operate with 6bone address space,
or are some kind of "pilot service", which may be less of a problem in
some sense.

> after being approved they can request a tunnel, again we get an IP.

Yep -- but that assumes the users must first know that such tunnel 
brokers exist, can find them in the web, install the software, fill in 
the forms, etc.

I.e., it's OK for techies, but looking at wider deployment, it's 
unacceptable.  But I guess it depends on who are you aiming the 
mechanism for; if we standardized a solution in this space, I think it 
would certainly have to be much simpler than that administratively.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sat, 13 Mar 2004 22:03:58 +0100

Pekka,

See in-line.

Regards,
Jordi

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "Jeroen Massar" <[email-masked]>
Cc: "'Alain Durand'" <[email-masked]>; <[email-masked]>
Sent: Saturday, March 13, 2004 9:37 PM
Subject: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]

> free tunnel broker provided by your own ISP, or set up 6to4/Teredo all 

Agree, as said in a previous message, this is more or less what we are doing, and hopefully could present in San Diego (we call it auto-transition):
- Native
- 6to4
- TB with 6in4 if a public IPv4 address is available
- TB with proto-41-forwarding if NAT supports it
- TB with UDP encapsulation
- Teredo
- others (even IPv6 over HTTP in the worst case !)

The order not necessarily is what I wrote down, as it may depend on the "best performance" solution for every client, and even change if the client or network change.

The "activate IPv6" should not be needed if we can manage to have the process automatically, and alternatively we should offer the "deactivate IPv6", hopefully, if for whatever reason, the user choose to ;-)

The auto-transition might propose the user, if the IPv6 performance in a given situation is very bad, to use IPv4 (hopefully with the time less and less often).

The discovery process might be not simple, specially because we want to ensure the best possible performance at any time.

> or are some kind of "pilot service", which may be less of a problem in

My feeling is that this is no longer true, and more and more TBs offer RIR space, and even the change to have it statically even when the user is moving.

> would certainly have to be much simpler than that administratively.

That's why we are looking for automatic discovery as part of the auto-transition "toolset".

---

From: "Jeroen Massar" <[email-masked]>
Date: Sun, 14 Mar 2004 03:28:08 +0100

Pekka Savola [mailto:[email-masked]] wrote:

<SNIP>

> desktop or network settings -- and not necessarily even that.

If they can use MSN, which requires one to sign up with
MS Passport and then fill in quite an amount of data, then most
people, anyone age 13 and up, should be able to sign up with a
number of tunnelbroker systems. The average 13 year old uses
KaZaA and a number of other odd systems to download all the
things they want which usually come into multiple pieces,
zip inside rars inside other weird package formats etc.
And apparently those users all seem to have a lot of
fun playing the newest games, listening to the newest
music and watching movies. How hard can it be for them
be to click a couple of times and fill in their info's?

Many of the users on the dutch POPs have IPv6 solely for
one simple purpose: access to IPv6 news servers.
Apparantly it is easy for the people wanting to use it.

For Freenet it only requires installation of their client.
For SixXS it even has nice clickety click stuff thing which
should be simple enough. It would be nice if those things would
be standardized though, if there is one we will adapt to it.

> That function should try to send route solicitation on your link, find a
> free tunnel broker provided by your own ISP, or set up 
> 6to4/Teredo all else failing.

As you are mentioning a 'discovery' type of service, I don't
think that is really possible as TB's are more like virtual
ISP's and like real ISP's it's the clients who want it.

The only thing that can be auto-discovered+configured is
currently 6to4. If we (ietf) would want to have a
autodiscovery feature for TB'sit would have to rely on a
anycast address which the ISP announces the same way as
the 6to4 address and basically one would get 6to4.

 - user enabled the IPv6 knob in $os
 - host builds tunnel to anycast address
 - normal ND/Ra procedures delegate the addresses.

This won't work with non-static IP's and getting the same
prefix back though, thus we require another thus another option would be:

 - user enables the IPv6 knob in $os
 - host contacts the anycast address port <n> over TCP*
 - sends it's user login/password
 - retrieves it's configuration data.

On error (eg user doesn't exist, not configured) it could
return a URL of the closest POP for that TB service.
The anycast service could also be used to redirect people
to the closest TB or a list of TB's of course.

* = yes I wrote anycast, but for the short lived communication
of a config protocol it should work even using TCP, retries
can always be re-tried if the communication fails but I guess
that won't happen that often and quick to even consider.

> for outsiders in many ways than a tunnel broker.

As far as I heard the Hexago Migration broker box is just a
'buy' 'enter config data' 'start' procedure, but I haven't seen it yet.
As for SixXS it is just 'contact [email-masked], install a unix box,
enter config data, upload the software, enable the POP, done'

All depends wether you want to reinvent the wheel or not ;)
 
> ISP, certainly don't want to give 3rd party users *our* address space.

In case of the SixXS model that would simply be feeding it the
prefixes that you would want to serve, as what happens with
the Data Telecom and the M"Net POPs. This would disallow them
from using those boxes. In case of the above anycast service
only your customers would get service from you as those would
get the anycast address response due to it being in their
routing system. Other users would possibly get a public TB.

> or are some kind of "pilot service", which may be less of a problem in

Au contraire, Hurricane gives out RIR space, Freenet does 6bone,
AARNet does RIR space and for SixXS 2 do 6bone and 9 RIR space.
Notez bien, that the problem of 6bone will be resolved in about
2 years time, no more need for ip6.arpa/int discussions either ;)

But I understand your point.

> brokers exist, can find them in the web, install the software, fill in 

They found MSN, Yahoo, Google, KaZaA etc. Friends tell that is the
trick to it, if there is interresting enough content even 13 year
olds can configure it. Again my example of newszilla6.xs4all.nl for
which a number of 'how do I configure my box to do IPv6 FAQ's'
exist on the net and people are using it for specifically that
purpose. The same goes for KaZaA for which I today read an article
in a printed magazine explaining in the most extremely childish
way how to download the newest movies and that as long as you
don't offer (upload) the !copyrighted! material yourself it
was totally legal in .nl, offering/downloading copyrighted
software was different though. Odd world we live in. But to get
to the point: if users see a need for it they will get it and
the standard way of telling people things will make it happen.

It would be better though if we, ietf, have produced a standard
way of doing the above, maybe it is time to do so? See below.

> would certainly have to be much simpler than that administratively.

Indeed, I guess it would be a good idea to pursue the anycast
configuration service or a similar technique. ISP's that don't
want to allow other ISP's users on their service can always 
not announce the prefix to other ISP's and can always announce
the prefix to other users.

Having a single hostname, eg "ipv6.tunnelbroker.arpa" or something
would not work as ISP's would then have to depend on the instance
running that service to distribute the clients. Unfair competition
and other blabla comes to mind.

To sum up the features I would like to have in such a protocol:
 - anycast address or similar to choose the closest TB and
   this could quite well be the service the ISP operates or
   a friendly ISP announcing this prefix. One problem though
   there is no way of having multiple TB's this way.
   But if a user knows which TB she wants she can always go
   directly to that TB.
 - Restricting users to only certain prefixes
   using the anycast announcement, just don't announce and/or
   redirect the users to another service, never say NO...
 - user authentication (optional)
    this is mainly to track users, know who is using what etc
    it also allows giving the same prefix to the same user even
    when the user changes IP addresses.
    This could also be done using a cookie mechanism.
 - static prefix delegation
    could be done using normal RA techniques.
 - DNS server configuration for that prefix.
 - Protocol 41 at first but optionally over UDP eg
   after detecting that proto-41 doesn't work.
 - UDP mode to be able to cross a NAT.
   Every single NAT I know of can be configured to
   forward UDP packets, thus that should work.
   There is one but, the first packet must come
   from the client and there should be some packet
   flow to not zero the NAT's counter.

The above service could also announce a list of TB's
to the client and let the user pick, they seem to be
quite good at that.

This feature should then be released for all major OS's
as otherwise it still wouldn't deploy... and it will
just be the same as 6to4, a very good idea but little usage.

Greets,
 Jeroen

---

From: "Ethern M.C. Lin" <[email-masked]>
Date: Sun, 14 Mar 2004 09:47:09 +0800

I would like to give some comment about the Tunnel Broker
and 6to4 relay service in the IPv6/IPv4 transition mechanism.

We provide TB and 6to4 relay since 2001, and we use the TB from
CSELT TILAB(http://www.cselt.it/) and I think almost free TBs are
coming from there.;)

And now we only have 30 tunnels in active. We have almost 2300
registered users in our TB database, but almost are data faked or
incompleted. We are opened for the wohle world users, and we only
assign /127 to the tunnel.

Why we only open 30 active tunnels for use? Because we are afraid
of ABUSE of the users. It is quite amazing. An open service but has
its limited. The registered users are from all over the world, and some
are even untracable and uncommunicated. So if the user has something
happened, we are the one which will be complained. So that's why we open
so less usable tunnel.

We will continue to improve the TB to make it more reliable and secure.
Although our purpose is to promote the IPv6 and make the connectivity 
to the whole IPv6 world, but the most importance thing we care is the
*security* in our service.  IMHO, to provide and service and care the
consequence of service is the provider's responsibility.

We get two IPv6 prefix block, one is 3FFE:4001::/32, the other is
2001:C08::/32. We provide the tunnel with 3FFE:4001::/32 to use, since
we define the TB as the "pilot service" as right now.

Even the 6to4 relay is the same. We use FreeBSD w/ KAME to provide 6to4
connectivity, but only accessable to the ASNet. We don't open to peers
nor customers.

We only take the TB and 6to4 relay are the temporarily services for the
moment. In the future, we will focus the dual-stack connectivity.

Best Regards,

Ethern
ASCC

-- 
=============================
Ethern M. C. Lin, <[email-masked]>
Network Division
Computing Centre, Academia Sinica
Phone: +886-2-2789-9953
Fax  : +886-2-2783-6444                      
=============================

--
On Sat, 13 Mar 2004 22:03:58 +0100

>That's why we are looking for automatic discovery as part of the auto-transition "toolset".

=============================
Ethern M. C. Lin, <[email-masked]>
Network Division
Computing Centre, Academia Sinica
Phone: +886-2-2789-9953
Fax  : +886-2-2783-6444                      
=============================

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Mar 2004 17:13:26 +0100

> that doesn't make either of these a good idea.

Not surprisingly, I agree :-)

But in any case, I think it is out of the IETF's hands at this point.
6to4 will die when it no longer serves any purpose.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Mar 2004 09:03:14 +0200 (EET)

> 6to4 will die when it no longer serves any purpose.

Of course, we cannot take away what's deployed, or what will be 
deployed :-).

The relevant point, however, is
 a) what we should recommend that folks do, and
 b) how strongly we should aim for good interoperability between 
    different sets of {6to4, Teredo, Native}

If there was concensus that we shouldn't need to do 6to4, we might be
able to simplify those interoperability concerns.  At the moment,
however, there doesn't seem to be strong push for that.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Mar 2004 09:23:33 +0200 (EET)

On Sun, 14 Mar 2004, Jeroen Massar wrote:
> number of tunnelbroker systems. 

MSN is, as far as I know, rather integrated with the system, so 
setting it up is easier.

The critical point here is locating the tunnel broker.  If you just
have one or two to pick from, they may be more well-known.  Locating 
MSN is much easier than locating a tunnel broker (or even knowing that 
such brokers would exist).

Further, it's a bit different to sign up for MSN and tunnel broker 
(IMHO): the requirements for the tunnel broker owner in terms of 
bandwidth, etc. are probably much higher.

> currently 6to4.

And Teredo, and ISATAP, if you count on them being here yet.

>  If we (ietf) would want to have a

Anycast for interdomain discovery; DNS, or DHCP would work if the goal
is to auto-discover when your local ISP is offering service.

> This won't work with non-static IP's and getting the same prefix
> back though, 

Sure; but this would probably be sufficient for the average John Doe, 
right?

> thus we require another thus another option would be:
> 

Anycast w/ user authentication would probably be out of scope, due to
the problems you describe.  The only thing that _could_ be done is to 
create a discovery process which would indicate where the closest 
broker w/ authentication is available.

> to the closest TB or a list of TB's of course.

That would require that there is some form of agreement/knowledge of 
all the other TB's in the responding service.

> All depends wether you want to reinvent the wheel or not ;)

Yet, this misses the point.  I don't think the problem is the
complexity of setting up the mechanism (especially for 6to4 relay,
might be for the tunnel broker at the moment), but rather whether the
ISP would want to offer such service in the first place.  Many don't.
See the next point.

> routing system. Other users would possibly get a public TB.

Such internal tunnel brokers only have sense to participate in the
"SixXS" model to gain publicity (i.e., their own customers know
they're offering the service) or to give better service to their
unaware customers (i.e., if the tunnel broker at SixXS redirects them
to the private broker based on some shared information, like "we know 
this one is best for you, use that!").

But the real problem here is that we can't really create (or at least, 
I'm having trouble visualizing such a system..) a global tunnel-broker 
network, like SixXS, which could be used by anyone in the world to 
learn the closest and "best" tunnel server available to them.  And all 
the tunnel servers, public ones at least, but also private ones if 
they aren't discovered using a different process, would be connected 
to that...

> olds can configure it. 

Right. If we assume IPv6 would have killer applications which would 
make the users really eager to get it, sure -- everything would 
probably be simpler.  But in the absence of such, we need to forward 
without them :-).

[ I've snipped the parts about a tunnel broker discovery mechanism to 
another thread ]

---

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

Taking the "auto-discovery" part of the thread apart from the rest...

I think one should soon try to write a draft about different tradeoffs
of tunnel service discovery procedures (inter-domain anycast,
intra-domain anycast, DNS (at least two methods), DHCP, manual config
ec.).  This might help us a lot in trying to figure out what we
actually want in this space.

Maybe someone(s) in the WG would be interested in drafting such a
document in a fast-track fashion (e.g., within a week or two at
most)..

> and other blabla comes to mind.

Yes, single hostname wouldn't work, I think.  However, one could say
that you could check for the local tunnel broker by looking up e.g.  
'ipv6-tunnel-server.' appended with your DNS search path, right?

That would work just fine in certain scenarios: if the broker doesn't
exist, you get negative reply and use a different mechanism (e.g.,
anycast or manual config); if positive, you use that.  This has
drawbacks in the cases when you're mobile/nomadic (i.e., have to re-do
the DNS lookup, not just re-route by anycast, but as the prefix when
moving would change as well, this might not be a significant
drawback).

One item I'd like to know more is how large ISPs which offer e.g., DSL
service, in different geographical areas, configure the DNS search
paths.  That is, whether the DNS search path trick would be sufficient
in finding the closest broker, or whether anycast would have to be
used on the side (note: nothing of course prevents you from anycasting
the IPv4 tunnel broker address that gets returned from the DNS).
 
The main question here is, I think, whether there would be pushback in
the DNS community for standardizing such "special-case local names".  
I recall there is precedent for doing something like this, but I'm not
fully certain.  This would have to be investigated in advance..

>    But if a user knows which TB she wants she can always go

Precisely.

>    redirect the users to another service, never say NO...

Yep.

>     This could also be done using a cookie mechanism.

I think this should probably be out of scope for anycast mechanism, at 
least in some sense.

That is, 
 - the anycast service must not lead to a tunnel server, which 
   requires user authentication; that is, "zero-configuration" must 
   always be possible.

 - the user might try to perform user authentication with the tunnel 
   server, but if the tunnel server does not know the user, the user 
   would not have other fallbacks than manually selecting the tunnel 
   server.

I think it might even be better that the anycasted services would not
offer any kind of user auth -- because if the closest server changes,
the authentication won't work anyway (or you'd have to redo it), and
it's just wasted effort.

>     could be done using normal RA techniques.

This would probably depend on user authentication or some kind of
identification being there.  If it isn't, the prefix can be only as
stable as it is (i.e., until the IPv4 address or IPv4 address + port
changes).  So, in my book, "static" is not a requirement.  I'd rather
tie the requirement to the staticity of the v4 address and or UDP port
(if coming through a NAT).

Are you referring to advertising a /64 and doing something like 
ND-proxying, something like draft-bykim-ipv6-hpd-01.txt or what?

Without ND-proxy I don't think prefix delegation would work with 
currently specified mechanisms except for DHCPv6.

>  - DNS server configuration for that prefix.

You mean reverse DNS.  Delegation and/or full configuration (e.g., a
wildcard record for the whole prefix)?

>    after detecting that proto-41 doesn't work.

Yep.

>    flow to not zero the NAT's counter.

Yep.

> to the client and let the user pick, they seem to be

Clarification: are you referring to TB's controlled by the 
anycast-replying entity (e.g., a large ISP having a dozen 
geographically distributed tunnel servers), or referring to other TB's 
as well?

The former doesn't make sense with anycast, as there is no need for 
that.

The latter doesn't seem to be feasible, as it would require sharing 
information with about all the tunnel brokers in the world.  How would 
one do that?  Not manually I hope.  So, this seems equally problematic 
as well.

> just be the same as 6to4, a very good idea but little usage.

You never know.. it could be little usage, but if implemented and used
by e.g. Microsoft, you would immediately have 5+ million IPv6 users
through a tunnel broker.. for the good or bad :)

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Mar 2004 13:05:18 +0200 (EET)

I'm replying to only one issue, under a new subject line, because I
think the others have been sufficiently addressed..

I think this mechanism selection work is also important, and it would
be nice to have something written out very soon so that we wouldn't
get stalled too soon.  If folks are interested in writing up something
quickly, please do line up.. :)

On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote:
> > Remember, our goal is
> > not get IPv6 deployed to those guys who are reading this
> > mailing-list and can do a lot of technical stuff to set things up.  
> > The target audience (which I have in mind at least) is much more
> > "dumber" than that.  I'd like to aim for the case where the most
> > the user would have to do is click an "activate IPv6" icon on the
> > That function should try to send route solicitation on your link,
> > find a free tunnel broker provided by your own ISP, or set up
> Agree, as said in a previous message, this is more or less what we
> are doing, and hopefully could present in San Diego (we call it
> auto-transition):

Yes, this is very useful work, but something that should be done much 
sooner than San Diego (IMHO).  Draft out within a week or two would be 
a good goal :-).  Actually I think this has already been discussed 
quite a bit (e.g., the "unmanaged bar gathering" at Minneapolis at 
IETF58), but not written out and fleshed out entirely.  It would be 
very useful to get that at least started and something written out 
soon.

Another related subject which needs to be worked at also is the 
coexistance of all of these mechanisms.  It's not just what you're 
using yourself, but what you should do to enable the others to use v6 
to talk to you (e.g., local 6to4 or Teredo relays).  This may be out 
of scope for this idea, but something to keep in mind in any case.

> - TB with UDP encapsulation

It may be worth noting that discovery of TB's is a rather delicate 
process (see the other thread), and a subject which may be very 
difficult to do properly.  But we can try...

> - others (even IPv6 over HTTP in the worst case !)

Well, I'd leave that "even" out from here.. :-)

> The order not necessarily is what I wrote down, as it may depend on
> the "best performance" solution for every client, and even change if
> the client or network change.

True, though "perfomance" is hardly an easily measurable unit, so
difficult to use in practice algorithmically.
 
> The "activate IPv6" should not be needed if we can manage to have
> the process automatically, and alternatively we should offer the
> "deactivate IPv6", hopefully, if for whatever reason, the user
> choose to ;-)

Sure.

> The auto-transition might propose the user, if the IPv6 performance
> in a given situation is very bad, to use IPv4 (hopefully with the
> time less and less often).

That's possible, yes.  In most cases, the performance is actually
worse, but there are different ways to count it (e.g., v4 connectivity
through for P-2-P through a server vs. direct v6 connectivity; and 
good v4 latency vs bad v6 latency).  This is probably something that 
would be impossible to measure properly.  So I have doubts about this 
being all that useful -- but one could certainly use this to say "hey, 
the tunnel broker is 200 ms off on the other side of the globe -- 
maybe it's not a good idea to use it?"

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Mon, 15 Mar 2004 17:56:29 +0100

Ok. We will work hard to have it lets say in 3-4 weeks at maximum (with the goal in mind to have it in only two weeks, even if is preliminary).

Regards,
Jordi

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Mon, 15 Mar 2004 17:49:46 +0100

Pekka,

The "auto-discovery" feature is part of the work that we are doing as "auto-transition", and we will an I-D on this in a few weeks, hopefully.

Regards,
Jordi

---

From: Alain Durand <[email-masked]>
Date: Mon, 15 Mar 2004 09:29:00 -0800

> Sure; but this would probably be sufficient for the average John Doe,

What John Doe wants is irrelevant. What the IPv6 applications require 
is.
Now, are you telling us that the potential IPv6 'killer apps' will not 
need stable addresses?
Making this assumption is very dangerous, IMHO.

> probably be simpler.  But in the absence of such, we need to forward

In the absence of such, what is the justification of IPv6?

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Mar 2004 20:07:32 +0200 (EET)

> What John Doe wants is irrelevant. What the IPv6 applications require 

Also, on the other hand, IPv6 is rather irrelevant unless we can make 
the assumption that it will be used by John Doe.  I.e., if we want to 
change the Internet, we need mass.  Guys like John Doe are the key to 
obtaining that critical mass.

> Now, are you telling us that the potential IPv6 'killer apps' will
> not need stable addresses? Making this assumption is very dangerous,
> IMHO.

I'm not saying that at all.  I'm just saying that there are limits to 
the requirements for the duration of such addresses.  For example, 
must John Doe's address stay stable if he shuts down his home PC, and 
leavs for 1-week trip to Tahiti, and then returns?  

It might not hurt, but the applications and the systems must IMHO be
designed to deal with the situation that when they (re)start, the
address might be different. I.e., the lifetime of the address does not
*necessarily* have to be longer than the lifetime of the application
process.

On the other hand, as long as John Doe's home PC stays powered on and 
connected to the Internet, his address should stay stable.

> In the absence of such, what is the justification of IPv6?

I'd rather not open this can of worms, but leave it as an exercise of 
the reader.

As some have pointed out, we wouldn't have needed anything other than
dual-stack (or the like) if we assumed that there will be strong
killer app.  When such app would appear, everyone would just upgrade,
end of story, happy end.  Unfortunately, IMHO, we need to move forward
without making an assumption that such an app would miraculously
appear; there will probably be ones (e.g., some p2p apps) which will
help to drive the transition along, but again, this is something we
should be counting on.

---

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

> *necessarily* have to be longer than the lifetime of the application

The "application" may be more complex than just one process.
Stable addresses across reboot may be necessary.
I want to be able to build apps that take advantage of the large IPv6
address space and consider that addresses are stable.

> connected to the Internet, his address should stay stable.

I suppose that you are aware of ISPs that change DHCPv4 allocated
addresses every 24 hours...
If John Doe's computer build its v6 address form those volatile v4 
addresses,
its v6 address will also change very 24 hours, and this even though 
John Doe
has not rebooted his PC. Not good.

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Mar 2004 23:11:35 +0200 (EET)

> The "application" may be more complex than just one process.

Agree.

> address space and consider that addresses are stable.

So, you want to build a simple application.  Don't we all.. :)  But I
don't think this is something we can guarantee even with native
access.  ISPs just aren't offering static v4 addresses today even when
they'd have technical means to do so.  So, counting on static v6
prefixes would IMHO be cutting corners too much.

The problem is worse with transition mechanisms, especially the ones 
which traverse NATs, but the situation may improve as soon as we can 
get rid of them.  In any case, such mechanisms can provide a stable 
as long as they can keep the NAT/IP mappings stable -- which is, for a 
properly designed application, maybe sufficient.

> addresses every 24 hours... If John Doe's computer build its v6
> address form those volatile v4 addresses, its v6 address will also
> change very 24 hours, and this even though John Doe has not rebooted
> his PC. Not good.

Yep, I know this -- unfortunately.  But there is little that can be
done to fix ISPs which want to enforce the users not to do Foo
(whatever Foo may be).  We can hardly fix the misbehaving ISP problem
at the IETF.. as you're probably well aware :)

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Mon, 15 Mar 2004 23:31:55 +0100

To be honest, unfortunately, even if we have a "killer" application, I don't think, at least not initially and quickly, we will have access networks with native IPv6 support.

The backbones, yes no problem for most of them, but access will take some more time. One of the problems is that we don't have cheap xDSL or cable CPEs with native IPv6 support (but are on the way).

So I expect that initially even actual applications, that don't get wide usage with IPv4 because the limitations, NAT and so on, will come to live with IPv6. I actually use one of these, as I've all the devices, lights, windows, alarm, ... accessible with IPv6, so I can even provide water to my dogs, and look at them with IPv6 cameras. In San Diego I can show it in the v6ops session or the coffee break if someone is interested ;-)

That was impossible with IPv4, but easy with IPv6.

Regarding the ISPs that keep changing the address, this can be easily solved with our "auto-trans" idea..

Regards,
Jordi

---

From: Alain Durand <[email-masked]>
Date: Mon, 15 Mar 2004 21:38:37 -0800

> properly designed application, maybe sufficient.

I'm not sure I want to follow you here. If an application needs to be 
written to
handle interface renumbering to benefit from IPv6 end to end 
connectivity,
this is putting the bar fairly high.

> at the IETF.. as you're probably well aware :)

In this scenario, we are already trying to fix the issue of ISP not 
cooperating
to deploy IPv6... so I do not think it is unreasonable to seek to fix 
the
address volatility problem at the same time if it is possible.

	- Alain.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Mar 2004 11:37:04 -0800 (PST)

> properly designed application, maybe sufficient.

I guess I don't understand what "such mechanisms" refer to above.
I don't know if mechanisms like Teredo can provide a stable IPv6 address 
when the nat mappings change, but doing TB/UDP for nat traversal should be
able to provide stable IP addresses/prefixes in this case.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Mar 2004 16:16:48 -0800 (PST)

> that doesn't make either of these a good idea.

Since I feel responsible for triggering Pekka's question let me
try to explain myself.

In a world with native, 6to4, and teredo we need to be concerned with
the operational issues of gettting relays deployed to enable communication
between the 3 different universes:
 - native to/from 6to4
 - native to/from teredo
 - 6to4 to/from teredo

Can we simplify the deployment of these so that we can reduce the likelyhood
of ending up with a partitioned IPv6 Internet?
A possibly way to simply this would be to have a single type of relay which
can relay between all three.
Using the same relay hopefully doesn't change how deployed 6to4 routers
work.

   Erik

---

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Mar 2004 16:25:59 +0200 (EET)

> able to provide stable IP addresses/prefixes in this case.

The point is to keep the NAT (etc.) mappings open as long as possible
so that they don't change -- and if they change, that'd be due to ISP
trying to enforce the user to a specific policy (e.g., changing v4
addesses on the fly) -- and I'm not sure if it's worth trying to
outsmart ISPs.  Stupidity always wins, with the customer in even a
bigger mess in the end.. :-/

As for what Christian said about Teredo reacting to these on-the-fly
address changes -- the spec says nothing of the sort, but may be of
course done by the implementation.  Might not hurt to add some text on
that specific case.

---

From: Florent Parent <[email-masked]>
Date: Wed, 17 Mar 2004 10:39:34 -0500

--On Wednesday, March 17, 2004 16:25:59 +0200 Pekka Savola 
<[email-masked]> wrote:

>> when the nat mappings change, but doing TB/UDP for nat traversal should
>> be able to provide stable IP addresses/prefixes in this case.
>

No one is trying to "outsmart" ISPs. To add to Erik comment: whether it's 
the nat mapping or whatever event occurs that changes your IPv4 
address/port, the point is that TB + nat traversal can guarantee that the 
user will have a stable IPv6 address/prefix. The user IPv6 address is tied 
with the user identification, not to its (temporary) IPv4 address (and port 
number).  This feature (stable IPv6 address/prefix) is an important benefit 
to the end-users, IMHO.

Florent

---

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Mar 2004 18:11:06 +0200 (EET)

> number).  This feature (stable IPv6 address/prefix) is an important benefit 

There are tradeoffs to consider here, of course.. e.g.:

 - signalling overhead required when tying the v6 prefix to something 
else than IPv4 address, port or something like that.

 - user authentication overhead and management complexity.

 - the recovery time; i.e., how long does it take to detect something
bad has happened?  How long does it take to recover from this
incident?  Note that unless this is very quick, the result may
actually be pretty close to IPv6 address changing (if e.g. the TCP
connections get broken in the meantime) -- and all we might not
actually gain much in the "ISP is changing the address on the fly"  
-case.

---

From: "Jeroen Massar" <[email-masked]>
Date: Wed, 17 Mar 2004 18:35:23 +0100

>  - user authentication overhead and management complexity.

What the solution I propose here and am already using is that
we seperate the above into two sections:

 - Authorisation + Tunnel Configuration & Setup
 - Notifying to the Tunnel _Server_ of the current IP.

The first part is currently handled by a non-drafted, but
protocol as described on http://www.sixxs.net/tools/configservice/
We are working to moving this to TSP which should become
the defacto standard in tunnel setup and configuration.

The second part can and is being solved using draft-massar-v6ops-heartbeat-00
for proto-41 tunnels. Though this can also be applied to the
IPv6-over-UDP protocol which Hexago is proposing in their
TSP client, though the latter could better support the
same kind of authentication the heartbeat protocol uses
inside the UDP packet itself.

Signalling overhead is about 200 bytes every heartbeat including
IPv4 and UDP headers. This only has an advantage IMHO as it does
have quite a good means of authentication, thus avoids spoofing.

> actually gain much in the "ISP is changing the address on the fly"  

Changing of IP's can be notified immediatly to the POP using
the heartbeat protocol. Typically the heartbeat is set to be
sent every 60 seconds and/or when the client detects an IP change.
OS's like Windows have API interfaces for this, unices mostly
have to rely on the dhcpcd notifying the client.

Greets,
 Jeroen

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 17 Mar 2004 14:14:13 -0800 (PST)

> bigger mess in the end.. :-/

I still don't understand what you were trying to say in the first paragraph
above.
That paragraph doesn't take into account that one can build
tunnel broker UDP tunneling schemes where the IPv6 address/prefix
is stable when the NAT mapping changes.
Was that paragraph only talking about Teredo? I read it as attempting to
make a more general statement.

On the third paragraph above, the NAT mapping might change for
multiple reasons - one of them being the ISP forcing a new external IP
address of the NAT box. Others being the NAT state timing out for various
reasons (having lived 3 years behind a ISDN NAT box which looses the UDP
port mapping when the ISDN line is dropped due to lack of traffic
I've seen this).

   Erik

One can build

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 17 Mar 2004 14:21:32 -0800 (PST)

> actually gain much in the "ISP is changing the address on the fly"  

FWIW RFC 3519 seems to do a reasonable job of accomplishing this
in the context of MIPv4.

Refreshing the NAT mapping and detecting when it might have been changed
can be done using ICMP echos to the tunnel server. When a failure is suspected
the host can redo the registeration protocol.

In genenral you can't detect the failure (mapping change) without sending
and receiving packets, but that is just a case of quick failure recovery
having a cost.

So I think the rocket science has already been invented in RFC 3519 - just need
to carry it to a different registration protocol.

   Erik

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Mar 2004 12:07:47 +0200 (EET)

> is stable when the NAT mapping changes.

Of course -- but such technology will have additional complexity in
terms of signalling (the most important one: user must be
authenticated/identified -- in the case of more or less anonymous
service, this may not be feasible).  

The point is that there can be mechanisms which tie the stability of
v6 prefix to the stability of the v4 address [/port].  This seems to 
be sufficient for a less advanced user, for a transition mechanism.  
The v6 prefix stability irrespective of v4 address[/port] would be an 
optional, additional signalling method, to be used where user 
authentication is feasible.

> make a more general statement.

Teredo is currently an example of this; STEP in ad-hoc mode is
another.  This is a more generic issue, especially if we want to
ensure zero-configured IPv6 deployment in ISPs' non-upgraded access
networks.
 
> port mapping when the ISDN line is dropped due to lack of traffic

Of course; the point is avoiding loosing the mapping.  But if it gets
lost, you either renumber (v6 and possibly v4) or reconfigure the
tunnel end-point (if supported and possible).  Depending on quickly
you are able to detect this, you may or may not be able to prevent v6
TCP connections failing during the failure period.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Mar 2004 12:19:57 +0200 (EET)

> FWIW RFC 3519 seems to do a reasonable job of accomplishing this

Sure.  There is no dispute of that.

But MIPv4 has assumptions which I do not agree with.  It assumes you 
have an authenticated association with the Home Agent.  Here, the 
respective element is the tunnel server.

I do not want to require such authenticated association -- which is 
required if you want to have a stable v6 prefix which is independent 
of v4 address [/port].  I think this is a useful additional mechanism 
which can be used when authentication is available, but when it isn't 
-- there is no use requiring it!

In that case, all you can do is somehow tie the prefix to an 
address[/port] or some magic token transmitted in the packet.  But 
unless it's carried in every packet, this is something that has to be 
remembered by the server.

> Refreshing the NAT mapping and detecting when it might have been
> changed can be done using ICMP echos to the tunnel server. When a
> failure is suspected the host can redo the registeration protocol.
> 

Agree with all of that -- and we already have mechanisms on the table 
doing something like this.

> So I think the rocket science has already been invented in RFC 3519
> - just need to carry it to a different registration protocol.

Yep -- or something like that.  I guess 
draft-thubert-nemo-ipv4-traversal-01 is already doing that in v6 
context; but again, that builds on top of MIP[v4].

I think the critical point here is whether we require this
registration protocol / user authentication in the mechanism, or
whether it's an optional step.  IMHO, we must not require that.

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 19 Mar 2004 18:08:46 -0800 (PST)

> -- there is no use requiring it!

You appear to be looking for a free lunch.
Sufficiently secure, operationally robust, direct paths, and no
need to "register".
That is an overconstrained problem IMHO.

I personally prefer "sufficiently secure" over the "no need to register"
given the world we live in today.
And lots of people seem to think it is ok to register to get
a free email account at yahoo, hotmail, etc.
Why do we think asking them to do the same thing to enable the cool
applications running on IPv6 is out of the question?

> whether it's an optional step.  IMHO, we must not require that.

I actually think it is a mistake to define mechanisms that are *not
capable* of doing registration with the same type of "tracability" that
is done to sign up for a free email account.
Whether different ISPs want to *use* that mechanism would be up to them.
But without them in the specifications and as mandatory to implement
we can easily end up with IPv6(transition) being perceived as less secure
than IPv4.

  Erik

---

From: "Jeroen Massar" <[email-masked]>
Date: Sat, 20 Mar 2004 03:32:04 +0100

Erik Nordmark wrote:

<SNIP>

> applications running on IPv6 is out of the question?

Requiring a signup and user address/info details cuts down
on the abuse with huge hops. Indeed it is very easy for
most people to sign up for things like Yahoo/MSN/... etc
thus signing up for a TB service shouldn't be that hard either.
I also think that that is more like a political thing and
not a protocol thing. We could look at it from a protocol side
by creating a protocol which standardizes registration and
then having a standard tool that does that part for them.
But many services would not like that as they want to
show their big flashy spammy logo's just to advertise themselves
even though the service is free you want some feedback.

> capable* of doing registration with the same type of 
> "tracability" that is done to sign up for a free email account.
> we can easily end up with IPv6(transition) being perceived as 
> less secure than IPv4.

ISP's should decide for themselves if they want to require
user authentication and registration. Freenet6 for instance
is quite public and anonymous and thus has a big load of
users. SixXS requires that every single user that wants a
tunnel supplies us with full name and address details including
a valid phonenumber, we decided on this for one prime reason:
cutting down on the abuse. It's simply not feasible in our eyes
to run a public and free service when jane doe can come in and
abuse it, mostly happening on IRC, which will only make ones
service unusable and thus totally useless. Many TB's have
disabled port 6600-7000 connectivity because of that too.
At least that is my point of view.

Thus: a protocol should make it possible to have anonymous
_and_ authenticated mechanisms, per choice of the entity
deploying the mechanism. The anonymous mechanisms could use
some kind of cookie method to allow the user to 'autoregister'
and when they come back present the cookie and allowing them
to get their former prefix back, add a lifetime to that and
we have a transition-dhcp protocol. Cookies should not rely
on the IPv4 address as that might change. I am a proponent
of stable addresses btw, thus having the above for anonymous
users helps dealing with that. Also rfc3041 is not for me ;)

Greets,
 Jeroen

---

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

> That is an overconstrained problem IMHO.

That certainly is; but I am do not want to solve "direct paths" in 
this kind of "tunnel server" solution -- and then I do not think the 
problem space is over-constrained.

As a matter of fact, Alain Durand reminded that "stable prefix"  
scenario introduces stricter security requirements in a sense -- as
noted in your multi6 security presentation on 3rd party bombing.  
You'll basically have to do (at least) return routability when you're
doing any actions associated with the v6 prefix.  If you tie the v6
prefix to the address/port you use, there is no need for that.

> applications running on IPv6 is out of the question?

I think it is important to enable a process where this could be done
transparently -- and easily enough.  Whether they would still want to
do authentication is a separate issue.

Many (most?) people don't know how to subscribe a free email support
(much less find one -- which is another difficult problem!), but we
want to enable IPv6 at their desks as well :).

> is done to sign up for a free email account.

This type of traceability is available from the tunnel server logs, 
similar to traceability of someone sending emails off such an account 
(many of which do not show the IP address of the sender).

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 22 Mar 2004 21:06:56 -0800 (PST)

> deploying the mechanism. 

Agree completely. We shouldn't need two separate protocols/mechanisms
for this.

> The anonymous mechanisms could use

Good idea to look at a cookie approach.
Presumably the provider of the tunnel service would decide when to reuse
prefixes - a cookie might be used once and never again so some garbage
collection mechanism is needed. But that is probably the case
for manually registered tunnel users as well.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 22 Mar 2004 21:27:24 -0800 (PST)

> problem space is over-constrained.

Sorry about "direct paths" - but "stable prefix" was missing from the list.
Perhaps Jeroen's idea about a cookie which can be created when autoregistering
is a way to provide a stable prefix and sufficient security for the
anonymous case.

> prefix to the address/port you use, there is no need for that.

Agreed.
But as you've pointed out elsewhere, it might make sense to require
an IPv4 return routability check as part of tunnel establishment
to prevent a single packet with a spoofed IPv4 source address from
creating a bogus tunnel.

> (many of which do not show the IP address of the sender).

But that would require the operator to run an abuse line which
will go look for the IPv4 addresses (and email address if the tunnel
was not autoregistered).
An alternative might be the freenet6 approach of sticking this
information in the reverse DNS entry so that a smart complainer can bypass
the tunnel provider to more quickly get towards the offender.

  Erik