Subject: Fw: [v6tc] Issue 2: service discovery: automatic or manual?

From: "Miguel Angel Diaz" <[email-masked]>
Date: Fri, 14 Jan 2005 19:49:59 +0100

----- Original Message ----- 
From: "Jeroen Massar" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 13, 2005 11:12 AM
Subject: Re: [v6tc] Issue 2: service discovery: automatic or manual?

[...........................................]

> I am still convinced that anycast is the way and that a 'anycast
> service' prefix would be the best thing to have.
> 
> Greets,
> Jeroen
> 

I partially agree with your point. I also support the idea of an anycast address if:

1) each transition mechanism has its own anycast address
2) the anycast address scope is global, I mean, it is applied not only to the ISP domain but the whole Internet.

even under this assumptions there are several barriers which would prevent that the anycast service will work on the whole Internet and for all the transition mechanisms (see http://www.consulintel.euro6ix.org/ietf/application_of_anycast_for_tb_implementation_v1_0.pdf). However if we compare the advantages vs. the drawbacks, IMHO the balance will be positive in favor of advantages.

However if the anycast scope is only local, that is only into the ISP domain, then other approaches like forward DNS has less drawbacks and then it should be considered rather than anycast. 

Regards
Miguel

_______________________________________________
v6tc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/v6tc

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 17 Jan 2005 16:24:40 +0100

> 1) each transition mechanism has its own anycast address

Why? Just setup a Transition Mechanism Server or whatever, eg a simple
webserver and a special URL on that box would retrieve the information
which allows the client utility to figure out what to do or where to get
the real information. Don't waste resources, there 'might' be enough,
but then still you don't have to waste it.

Reread what I wrote (and also wrote last year in april): Service Anycast
Prefix. Which is just so you can reach a box which can tell you 'there
is the service for you' and from then on you can do anything possible.

> 2) the anycast address scope is global, I mean, it is applied not only
> to the ISP domain but the whole Internet.

Why? If the service prefix is only announced to the local ISP, then only
those will receive service from that instance. Announce it to the world
and you give the world service. That is how anycast works, simple and
easy.

> even under this assumptions there are several barriers which would

Which barriers?

> prevent that the anycast service will work on the whole Internet and
> for all the transition mechanisms (see
>
http://www.consulintel.euro6ix.org/ietf/application_of_anycast_for_tb_implementation_v1_0.pdf). 

A few comments:

Defining anycast address as a tunnel endpoint for traditional Tunnel
Brokers is silly, especially because that is simply a normal, well
established use of server failover. If you meant to do global anycast
deployment, please stick to 6to4 as you do not want the hassle of
managing that. Next to that you might be interrested in an alternative
approach as presented by XS26 (http://www.xs26.net) who use multiple
tunnel servers and allow people to use multiple tunnels, thus giving
them complete failover possibilities.

Btw, when was this paper written, because it mentions 'current' a couple
of times, but there is no publication date in the paper. And please be
free to translate to spanish on page 9 and I won't fall over the various
broken sentences (it actually reads like it has been translated by
babelfish or something similar). I am also quite sure that there is no
TB around that changes the users forward DNS zone, even though that is
implied on the first page. Reverse in some cases, but even that is not
likely.

The reason btw that TB's are around and used, is that that is the only
way to get IPv6 at the moment in most cases that is not severely broken,
like 6to4 is in most cases. Also do remember that most users use IPv6
for two simple reasons IRC (because reverse DNS can be configured most
of the time for IPv6 prefixes they get allocated) + NNTP. Only a
fractional number of people tend to use it for stuff like webservers,
ssh and other somewhat normal protocols.

Scene 1 mentions that "most of the TB's belong to the academic or
research scope". FreeNet6 _was_ indeed Canarie, but is now fully
commercial based at Hexago, Hurricane Electric is a commercial company
as well, and out of the 13 SixXS POPs only 2 are 'academic'. From this
small and quite complete list, I think the majority is thus actually
commercial unlike what you are mentioning in your paper. Though they do
offer free service, that is correct. But why not? It is for getting
people going with IPv6. As for a TB with 'poor performance', as long as
you don't pick one on the other side of the ocean you should be fine.
I've not encountered one which was congested yet. There is not that much
IPv6 traffic yet anyways. You also imagine that people get everything
for free. The reason why there are free TB's is because of the fact that
giving a good TB service the users will value the ISP and are likely to
maybe buy other services from them. Scene 1 is thus quite bogus because
it is based on false assumptions and a lot of missing background.

Scene 2 assumes that people want to roam. This is normally solved with
MIPv6 thus should also be in the cases of TB's. It is then of course not
so odd to see Figure 2 matching the standard Mobile IPv6 figure ;)
I can also tell you that I can very easily solve Scene 2 with a tool
like AICCU. Freenet6's TSP client can also do it, but they do not have
that many POPs.

Scene 3 is already done by several deployed Tunnel Brokering systems.
Without the need for the word anycast, though as mentioned the Tunnel
Server or the Tunnel Broker could easily be anycasted as a normal form
of loadbalancing/failover.

The solution mentioned in 3.1 is what SixXS does and guess what it works
very well. The only people that I know of who complain are the ones who
can't make use of the service anymore after they tried to abuse it. The
users who use it normally though are very happy.

3.2 mentions that DNS is not centralized, tell that to the panix.com
people ;) Also in any case if you want to do it, it will need a special
application made for your great solution. Thus do not claim that "it
would avoid that users would run special applications..." as that is not
true. If this application is a script or some other magic it is still
something which is not commonly available, thus don't claim that.
I wonder why you even mention the Cisco DistributedDirector as it is a
device targetted at something completely different as you mention in the
paper yourself and then you also mention that it is not good for your
purpose because it is proprietary. I don't like Cisco that much either
but putting it in a document in that way, nah.

In 3.3 you mention www.tunnel-broker.net though you are talking about
anycast, should that part not go under 3.2, where you just mentioned
that it will not work for your purpose because of caching?

Rounding section 3, called solutions, you fail to mention any solutions
as you try to describe them and then directly put them down without any
evidence.

The rest I only skimmed because I actually got a bit tired of reading
the broken english and thus having to reread the sentences multiple
times before they where understandable. If I had any knowledge of
spanish I would ask for the most likely original spanish version, which
I guess is much better to read than this version. I did notice a lot of
loose references to things that totally made no relation at all to the
subject and a lot of misassumptions. Routing for instance does not
change every 5 seconds when staying inside the same ISP. You might be
interested in taking a look at RIS (http://ris.ripe.net) or maybe
playing around on the real internet with some BGP tools.

Next to all of that, ever thought how much overhead reconfiguration of
say 10k tunnels on say 50 TS's will be when you really want to keep it
tight the way you specify? The overhead of all of that really is not the
worth the trouble. Simply setting up 50 boxes in clusters of 2 with a
standard VRRP failover protocol and you are done(tm). No new problems
and it will just magically work(tm). Even one box can work perfectly
fine until some hardware parts fail. MTBF is your friend here.

The biggest point you are missing btw is the problem of abuse. How are
you going to trace abuse in the setups you propose. Remember that you
are proposing a service which grants anonymous IP connectivity to
anonymous users. Guess which service will not have access long to
several key parts of the internet as the abuse from that service becomes
to large to even bother yelling at the abuse line of that service...
The newest fun of these people seem to be hacking a box, getting a IPv6
in IPv4 tunnel, or just 6to4 and then playing the anonymous bastard from
there. Welcome to the world of Anonymous Cybernet ;)

Btw, already checked how much valid traffic/non-bogus is going over your
open relay?

> However if we compare the advantages vs. the drawbacks, IMHO
> the balance will be positive in favor of advantages.

> However if the anycast scope is only local, that is only into the
> ISP domain, then other approaches like forward DNS has less drawbacks
> and then it should be considered rather than anycast. 

Thus, if the anycast scope is local, it is worse than DNS?
I am quite sure it is the other way around.

Greets,
 Jeroen

PS: I wonder why your paper misses out two of the largest and oldest
TB's in the world, it's not that it is a big list or something, but
those two do a lot more than the ones you named and actually solve the
concerns you mention in your paper, though that could be just me.

---

From: Tim Chown <[email-masked]>
Date: Mon, 17 Jan 2005 16:14:32 +0000

> it is based on false assumptions and a lot of missing background.

For info, when we surveyed European NRENs in 2004, 75% operated a 6to4
relay while 25% operated a tunnel broker.   One NREN has turned its broker
off (UNINETT).

[Ref: D2.2.3 at www.6net.org]

But I don't think we're suggesting that (say) UKERNA would expect home
DSL users to pick its broker by the automated TEP discovery method, you'd
expect to find the broker of the home DSL ISP (e.g. BT Openworld).
However, the "go to a web page and execute a script" method works well
enough for the clueful existing TB users, and thus we've muddled through
on that basis until now.   I guess some users would want to use a named
TEP though, rather than an autodiscovered one.

Tim

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 17 Jan 2005 18:39:49 +0100

On Mon, 2005-01-17 at 16:14 +0000, Tim Chown wrote:
> relay while 25% operated a tunnel broker.

The doc mentions that there are 25+ NREN's in total, of which 18 where
connected to 6net. out of that 75% had a 6to4 relay, thus for the
complete European community (how many connections are that?) there where
12 NREN's with 6to4 relays, which is thus only a low 50%. Not bad but I
wonder if 1Gbit/s is enough for such a large community, assuming that
each box only has a 100mbit card.

> One NREN has turned its broker off (UNINETT).

NREN's are of course all non-commercial and politically are not to
deliver to endusers, and wasn't this what the automatic discovery was
intended for ? :)

Next to that 6net is now fortunately getting turned off, only few
countries left, which saves a lot of problems in the IPv6 world ;)
Btw, funny that none of the 6net participants ever had linerate (Gig and
up) native IPv6, one would have hoped that the various hardware vendors
would have done playtesting by now.

6to4 has one problem, which Teredo does not have: NAT's.

> TEP though, rather than an autodiscovered one.

Indeed. Thus a 'if configured don't touch' but otherwise try to do it,
is very useful. And we already have that in Windows XP for instance ;)
Thus why invent the wheel again? Or is this just another 'it has a MS
stamp and that ain't good enough for the world' kind of thing?

Greets,
 Jeroen

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 Jan 2005 11:21:54 +0000

> each box only has a 100mbit card.

Hmm, 12 of 18 is 75% not 50% :)

The points herea re that 6to4 relays were three times as popular as brokers,
but of course that's on the provider end, there may be far more users of
brokers, using services like freenet6 (even with a huge RTT).   But we just
don't know.

Regarding throughout, as you've said most usage is for chat-type apps, 
rather than streaming/mirroring/etc and the types of sites running that
would probably have a manual tunnel or native link.    Home users would
be limited to 512K or similar anyway.

> deliver to endusers, and wasn't this what the automatic discovery was

They are there to support their users, so yes they should offer 6to4 or
brokers, but it's hard to control access to 6to4 outside your domain.
I, personally, would rather use my university's broker than whichever
"random" one appeared to me when in a hotspot or home network, at least
while in the UK/Europe and knowing the latency is low.   I guess our target
"market" with v6tc is the Joe Broadband user though.
 
> countries left, which saves a lot of problems in the IPv6 world ;)

What do you mean "fortunately", I don't understand?

> would have done playtesting by now.

I don't understand again.  We had native 1Gig to our door.   We were not
alone in that.   The lines used between 6NET PoPs were 155Mbit/s due to
budget reasons,  but the GEANT links that were established maybe 18 months
ahead of schedule due to 6NET work of course are 10Gig+.   Not that anyone
is generating Gigs of v6 :)

> 6to4 has one problem, which Teredo does not have: NAT's.

Our users running 6to4 at home use proto41 forwarding to get around that,
but Joe Broadband wouldn't.
 
> stamp and that ain't good enough for the world' kind of thing?

I don't understand again where you're coming from here, sorry.

-- 
Tim