Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt

From: "Bound, Jim" <[email-masked]>
Date: Fri, 30 Apr 2004 08:21:47 -0400

then the document title should say that in some form in the title
because it will not be useful to users building native IPv6 networks
with IPv6 as the dominant backbone routing protocol e.g. 3GPP IMS, U.S.
DOD nets, ISPs building for IPv6 device attacments to the network, or
Moonv6 Network Pilot as examples of early adoption and deployment.  But
I thought I saw parts in the spec that did speak to IPv6 networks I will
check again?

I also agree with you this document is in a sense boiling the ocean and
that does not work.  I also right now do not believe this is possible.

/jim 

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Friday, April 30, 2004 12:16 AM
> To: Bound, Jim
> Cc: JORDI PALET MARTINEZ; [email-masked]
> Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt
> 
> On Thu, 29 Apr 2004, Bound, Jim wrote:
> > > A number of transition mechanism have been defined 
> already: Teredo, 
> > > TB/TS, TSP, STEP, ISATAP, 6to4, tunnels, etc. All of them 
> work when
> > 
> > Your missing DSTM in this analysis why is that?
> 
> I think the document is focused on obtaining _IPv6_ 
> connectivity in IPv4-only networks, not the other way around.
> 
> ...
> 
> FWIW, I personally agree with Brian's concern of too 
> ambitious goals.  
> Too ambituous goals often result in nothing getting done, 
> instead of what might have been realistic.  So, if it stays, 
> it probably needs "health warnings" or th like :)
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
>

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Fri, 30 Apr 2004 14:49:32 +0200

Jim,

You're right. Our idea is a dual stack node, with IPv4 connectivity (and with or without IPv6 native).

The point is the case when I travel to an IETF, for example, and I've native IPv6, but the performance is very poor. I can always opt for using a better transition mechanism (example a "near" TB/TS).

Will make sure to clarify it better.

As Brian and Pekka said, we are too much ambitious or not clear enough, and already working on improving the document.

Regards,
Jordi

----- Original Message ----- 
From: "Bound, Jim" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: "JORDI PALET MARTINEZ" <[email-masked]>; <[email-masked]>
Sent: Friday, April 30, 2004 2:21 PM
Subject: RE: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt

/jim 

> it probably needs "health warnings" or th like :)

**********************************
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: Pekka Savola <[email-masked]>
Date: Fri, 30 Apr 2004 15:53:56 +0300 (EEST)

On Fri, 30 Apr 2004, JORDI PALET MARTINEZ wrote:
> The point is the case when I travel to an IETF, for example, and
> I've native IPv6, but the performance is very poor. I can always opt
> for using a better transition mechanism (example a "near" TB/TS).

FWIW, I'm concerned about methods to "optimize" poor native IPv6 
connectivity.  We need to fix the native connectivity instead... :-/

On the other hand, there _are_ a few practical ways for optimization
which are rather simple: a "local" 6to4 relay, and a "local" Teredo
relay.  Those can significantly help when you're on native v6 but 
communicating with someone who isn't.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Fri, 30 Apr 2004 15:05:55 +0200

Hi Pekka,

See in-line.

Regards,
Jordi

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "JORDI PALET MARTINEZ" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 30, 2004 2:53 PM
Subject: Re: I-D ACTION:draft-palet-v6ops-auto-trans-00.txt

> connectivity.  We need to fix the native connectivity instead... :-/

I agree, it will be much better to optimize fix native connectivity, but what the users does, when he doesn't know nothing about that, and he has, of course, no control of the visited network ?

Remember that this is targeted to clients, even it could be used, for example, in CPE devices, assuming that is automatic, because the user has no technical expertise ...

> communicating with someone who isn't.

That's why we included 6to4 and Teredo as options ;-)

---

From: Jeroen Massar <[email-masked]>
Date: 30 Apr 2004 15:17:39 +0200

> connectivity.  We need to fix the native connectivity instead... :-/

Well there is this issue of 'policy' which the IETF can't fix.
For instance most of the 'educational and research' networks/NRENs
currently have IPv6 deployed and working but if you have the following
situation:

Commercial ISP <-> { IPv6 Internet } <-> NREN

Your traffic will most likely flow like:

Commercial ISP -> Transit -> NREN 

but the return route will be:

NREN -> 6net -> Commercial ISP

And guess which route the "Transit" networks take. Good example was the
"Global IPv6 Launch Event" in Brussels. Connected to Belnet, thus all
the NREN connectivity is good. But if you wanted to reach a host in the
Netherlands all the traffic would be routed directly over 6net ->
Surfnet to the Commercial ISP but all the return traffic isn't accepted
by 6net thus that was routed 'nicely' over the US...

Nice policy, but as mentioned nothing the IETF can fix except for what I
did: clickety click in my heartbeat tool and tada a perfectly working
tunnel to a dutch Commercial ISP as IPv4 didn't have the
IPv6-over-the-US problem.

This might be solved one day however when IPv6 gets more deployed and
the routes get shorted, but this example for instance makes it quite bad
when interacting between Commercial networks and NREN's. Notez bien that
between Commercial networks or between the NREN's most connectivity is
quite good actually.

> communicating with someone who isn't.

Doesn't help when the policy is stupid ;)

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Apr 2004 17:52:31 +0300 (EEST)

On 30 Apr 2004, Jeroen Massar wrote:
[...]
> by 6net thus that was routed 'nicely' over the US...

Are you arguing that one-way short-cut is bad practice (this is going
away very soon, I think), that commercial ISP's transits/peerings are
not good enough, or that NRENs should provide full two-way transit
(like Internet2 is more or less doing)?  Note that the latter is very
questionable AUP-wise.

> between Commercial networks or between the NREN's most connectivity is

This is a problem of commercial networks' lack of good transit, IMHO.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Apr 2004 17:57:03 +0300 (EEST)

On Fri, 30 Apr 2004, JORDI PALET MARTINEZ wrote:
> I agree, it will be much better to optimize fix native connectivity,
> but what the users does, when he doesn't know nothing about that,
> and he has, of course, no control of the visited network ?
> 
> Remember that this is targeted to clients, even it could be used,
> for example, in CPE devices, assuming that is automatic, because the
> user has no technical expertise ...

Let's avoid getting to the situation where native v6 would be of very
bad quality, and John Doe would have to have systems to work around
that.

I've raised concerns about the bad present considition as well (in
draft-savola-v6ops-6bone-mess-01, now probably expired), but remember
that the ISPs aren't probably going to offer native v6 to all their
customers unless they've been sufficiently well-connected first. (The
technically knowledgeable v6 enthusiasts who are using these pilot
services aren't worth looking at here.)

I don't want to see a situation for the mainstream users where you'd
have to e.g. use tunnel server (remember, that would have to be
automatically set-up as well -- the chances of its quality are not too
high either!) to get better connectivity than native IPv6...

---

From: Jeroen Massar <[email-masked]>
Date: 30 Apr 2004 16:59:27 +0200

> (like Internet2 is more or less doing)?  Note that the latter is very

I mean the latter indeed and it is a bit of a policy decision. The
NREN's do announce the commercial routes they learn for each other and
use the backpath to the commercial ISP's but they don't re-announce
eachothers networks. I hope they clear it up one time, until that time
I'll keep a couple of tunnels handy just in case ;)

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: 30 Apr 2004 17:19:18 +0200

On Fri, 2004-04-30 at 16:57, Pekka Savola wrote:

<SNIP>

> customers unless they've been sufficiently well-connected first.

Your 6bone mess has expired, but in the mean time the routing has become
much better IMHO, for proof see: http://www.space.net/~gert/RIPE/

There is also a very good document from Robert Kiessling which is being
applied by quite a number of ISP's majorily in Europe:
http://ip6.de.easynet.net/ipv6-minimum-peering.txt

This document will be handled next week at the RIPE IPv6 WG.

> (The technically knowledgeable v6 enthusiasts who are using these
> pilot services aren't worth looking at here.)

I think I have mentioned this before, but I know of quite a lot of
people who are totally not technically knowledgable but are able to
follow a few easy steps to find their way to the honeypot.

For instance:
http://www.opurk.nl/reacties.php?commentaar=1223&onderwerp=Computers

If you where able to read dutch, though some of it is really ugly
belgian stuff, you would also notice that these people help eachother
out when it isn't all that easy. This is just one of the many forum
sites that discuss these issues btw. Having quite some interaction with
these non-tech endusers have showed me that most of them can get it
working very easily and without much problems already, thus without even
the automated discovery tools. There is no KaZaA discovery method either
now is there ? And they did hit the how many million users?

Notez bien these people are doing it so they can get connectivity to a
service that they can't reach (freely) otherwise.

> high either!) to get better connectivity than native IPv6...

Native should be the defacto standard, if an ISP can't deliver a quality
internet connection then users will complain, especially when they pay.

As for Tunnel Servers, that is a Transition method, thus they should go
away at one point... sooner or later.

Greets,
 Jeroen