Re: refocusing: Re: [v6tc] Issue 2: service discovery: automaticormanual?

Jeroen Massar <jeroen@unfix.org> Tue, 18 January 2005 11:25 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13510; Tue, 18 Jan 2005 06:25:07 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqrjE-00057D-Al; Tue, 18 Jan 2005 06:40:56 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqrPa-0005lB-M4; Tue, 18 Jan 2005 06:20:38 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqrKS-0003YU-Mt for v6tc@megatron.ietf.org; Tue, 18 Jan 2005 06:15:20 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12685 for <v6tc@ietf.org>; Tue, 18 Jan 2005 06:15:13 -0500 (EST)
Received: from noc.sixxs.net ([213.197.29.32] ident=postfix) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqrZd-0004sw-Oy for v6tc@ietf.org; Tue, 18 Jan 2005 06:31:02 -0500
Received: from localhost (localhost [127.0.0.1]) by noc.sixxs.net (Postfix) with ESMTP id D229EC2247; Tue, 18 Jan 2005 12:15:03 +0100 (CET)
Received: from noc.sixxs.net ([127.0.0.1]) by localhost (noc [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17994-06; Tue, 18 Jan 2005 12:15:01 +0100 (CET)
Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by noc.sixxs.net (Postfix) with ESMTP id BB12DC222A; Tue, 18 Jan 2005 12:15:00 +0100 (CET)
Subject: Re: refocusing: Re: [v6tc] Issue 2: service discovery: automaticormanual?
From: Jeroen Massar <jeroen@unfix.org>
To: miguelangel.diaz@consulintel.es
In-Reply-To: <013701c4fd3e$1fae41d0$1100a8c0@consulintel.es>
References: <00b501c4fd30$5e598880$1100a8c0@consulintel.es> <013701c4fd3e$1fae41d0$1100a8c0@consulintel.es>
Organization: Unfix
Date: Tue, 18 Jan 2005 12:14:58 +0100
Message-Id: <1106046898.14179.58.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.2 (2.0.2-6)
X-Virus-Scanned: noc.sixxs.net - http://www.sixxs.net
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78
Cc: v6tc@ietf.org
X-BeenThere: v6tc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: v6tc.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>, <mailto:v6tc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/v6tc>
List-Post: <mailto:v6tc@ietf.org>
List-Help: <mailto:v6tc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/v6tc>, <mailto:v6tc-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0489154793=="
Sender: v6tc-bounces@ietf.org
Errors-To: v6tc-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 995b2e24d23b953c94bac5288c432399

On Tue, 2005-01-18 at 10:14 +0100, Miguel Angel Diaz wrote:
> >> IMHO if we wish a broad and fast deployment of IPv6 the answer is that an
> >> automatic discovery mechanism is definitively required. 
> > 
> > There is already Teredo and 6to4, what more is needed?
> > Teredo on it's own already solves most if not all problems.
> > The only issue with Teredo _could_ be that one does not get the most
> > local relay. But I think M$ can be easily pursuade to add a update to
> > windowsupdate that will reconfigure the default teredoserver to an
> > anycast address.
> > 
> 
> Thousands (even millions) of users over the world can't use the
> current servers that M$ has pre-configured for 6to4 and Teredo
> implementations on the OS, which are 6to4.ipv6.microsoft.com and
> teredo.ipv6.microsoft.com.

Did you notice the following:
6to4.ipv6.microsoft.com has address 192.88.99.1
6to4.ipv6.microsoft.com has address 131.107.33.60
6to4.ipv6.microsoft.com has IPv6 address 2002:836b:213c:1:e0:8f08:f020:8

If it isn't known, that first one is the 6to4 anycast address, which is
also the first thing that XP tries, after that it might fall back to the
microsoft provided relay.

They (6to4 and Teredo) work perfectly fine from the several places where
I have tried them. The only thing was the latency and throughput, which
is logical as the Teredo box is hosted in the US, which is not where I
am, but fortunately it uses those nice bubbles to locate a more local
server which then causes the traffic to be optimized a bit.

Any real argument why these millions of users can't use Teredo according
to you?

> It is assumed that every ISP willing to offer IPv6 services to their
> customers will deploy a TEP infrastructure on its own network, either Teredo,
> 6to4, or whatever. The TEP discovery on the ISP network is the point.

Of course they want that, just like this is expected from 6to4.
There is a very simple solution if you want this: anycast prefix for
Teredo. Does not require any weird mechanisms, no weird stuff in DNS
nothing. But to call this 'discovery', why bother with that ?

> > Now if I would live in Tokio I could live with this assumption, but
> > unfortunately, unless I go to Akibara myself or import the stuff I will
> > not be able to buy these cool toys (yet).
> > 
> > Also, the router in the house should provide this, not the camera, that
> > should simply RA. Next to that does the word 'security' say anything?
> 
> The point is that "today" we are working on the networks for "tomorrow" and in the near future,

In the future there will be native IPv6 to the home, today there is need
for some tunneling. But in ~5 years it will be mostly native.

> I think we all are agree that many home devices will support IPv6. Such devices could implement
> methods to work with IPv6 even although only IPv4 (so not RA available) is available on the
> home network during the early deployments. In this scenario an automatic discovery method is required.

Thus you want every small device to implement tunneling and thus create
how many security holes in how many places?

You'd better start writing the security section of the draft like 3
years ago if you want to cover all the possible problems you will be
creating here.

Remember the following very simple thing: There will most likely be at
least one computer (XP, BSD, Linux, other 'router') that supports IPv6
in such networks. These are more than capable handling this and are also
way easier to make centrally secure/firewalled.

If you really want that you can plug in a IPv6 camera, which will then
also do IPv4 for the tunneling even though it is a IPv6-only cam, then
also remember the security problems.

> >> So, IMHO the answer is that we can't live with methods that require users to enter any URL or data.
> > 
> > I know of almost 3500 happy users who lived with this perfectly fine and
> > there are a number of other organizations who claim to have way more
> > users.
> > 
> 
> I guess we are thinking of different type of users. I sure that expert users (at least with some
> technical knowledge) are happy with that situation, but I'm thinking of thousands of users that
> aren't TI experts.

I am quite sure that most of those happy users are completely clueless
in what they are doing and just followed that nice article they found on
the internet or in that Computing Magazine For Dumbo's and are happily
downloading the newest movies/music and other warez they can find.
This is where the internet is used for and this already works.

> My father might be a good example: he likes just plug-and-play devices because
> he has no technical knowledge at all, so he would like just plug its IPv6 camera (with transition
> mechanisms implemented) on the home network (IPv4) and see its house while traveling around the world.
> He wants that the camera itself is in charge of all the required configuration (TEP discovery included) to work.

He is quite likely to not even want to know how it works, he wants it to
work, but without having his neighbor and that Brazilian kid and the
burglar watching his house for him too... or are you going to explain
him what security is? ;)

Next to that, implementors of small devices don't like to implement
multiple IP stacks and replicate work which should be done by other
equipment. Note that all the current IPv6 toys are IPv6-only and do not
have anything to do with IPv4. There is a reason for this: they don't
want to be bothered with IPv4 in the first place as those devices could
not communicate globally in the first place and they where sick of
building NAT workarounds.

Maybe a picture helps to illustrate this all:
 http://www.ibiblio.org/Dave/Dr-Fun/df200306/df20030604.jpg

Greets,
 Jeroen

_______________________________________________
v6tc mailing list
v6tc@ietf.org
https://www1.ietf.org/mailman/listinfo/v6tc