Subject: IETF59 minutes and presentations

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

Hi,

(co-chair hat on)

The minutes and presentations have been made available at:

http://www.6bone.net/v6ops/minutes/index.htm

Please send corrections, omissions, etc., to the chairs within a week
(by Mar 19).

Thanks!

---

From: Fred Templin <[email-masked]>
Date: Fri, 12 Mar 2004 11:11:58 -0800

Pekka,

I just wanted to clarify one remark that was (correctly) attributed
to me during the Thursday session:

> Fred: If the question is must we have one solution, then I am cautious. but 
> can we find one solution, I would say yes.

By "one solution", I was referring to the possibility of a
_unified_ solution which might include aspects of several
mechanisms, i.e., not necessarily just a single mechanism.
(Perhaps this is the same as what Pekka referred to as
a "hybrid" solution?)

While I believe such a unified solution is possible, I have
no way of predicting a timeframe and believe it is important
that we continue to gain experience with mechanisms at-hand.

Fred L. Templin
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Fri, 12 Mar 2004 15:09:37 -0800

From the minutes:
    - Unmanaged user wants to do p2p with another
     Direct "short-cut" connectivity very important
     If no support from the direct ISP
       Automatic tunneling works automatically: Teredo requires "Server" 
with
       low b/w reqs
       Tunnel broker would help, if the users could find a free broker 
nearby
       If there would be incentive for broker deployment, a "nearest 
broker
       discovery"
         process would also help
       Unless the user is really determined, the user is lost without
       automatic tunneling

==> I do not see how this scenario is fundamentally different
from the road warrior using IPv4 on a dial-up modem.
In many cases, he can call a well known centralized 1-800 number
that will create a suboptimal long path or he will have a phone number
for a local PoP, that will hopefully provide shorter RTT.
There is no 'find me the nearest PoP' protocol here.

If we look at a tunnel broker as a virtual IPv6 ISP,
can someone point me how things are different?

	- Alain.

---

From: Alain Durand <[email-masked]>
Date: Fri, 12 Mar 2004 16:01:09 -0800

> http://www.6bone.net/v6ops/minutes/index.htm

Dear wg chairs,

I just read those minutes on the hesitations for one vs many transition 
solutions.

Have we made much progress since Minneapolis march 2002? (ban on 
Ngtrans work on tools)
Have we made much progress since Grenoble interim meeting (Feb. 1999)
were we tried to go down to one transition mechanism and failed...

Yes, we now have some scenarios, but they are far form being all 
completed. And at the end of
this exercise, we are still trying to answer the same questions, do we 
need automatic vs assisted
mechanisms and how much should we rely on the infrastructure put in 
place by ISPs.
But still no simple recommendation on how to do transition.

	- Alain.

---

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

Hi Pekka,

Regarding the minutes:

- Actually I said something like  "... every client has IPv6 connectivity available even when moving thru different networks. I'm having this problem when traveling and I can sort it out most of the time because have the expertise, but this is not the case for regular users. We need a kind of auto-transition feature that choose the right protocol from a set, no needed user intervention, but ensure connectivity even if this is bad (worst case, for example, IPv6 over HTTP, of course I will not suggest it, only in very extreme cases)."

- After "Not so sure how many mechanisms must be specified.", I indicated "There are many possible networks, many possible scenarios, I insist that we must ensure that the client can have IPv6 connectivity in any case, automatically, a kind of auto-transition, of course, trying to use the best possible solution".

- In my presentation, I used "nomadic" instead of mobile. I believe is important the distinction, to avoid mixing the concept with IP mobility. Also "visited networks". I didn't said should deal with IDS, it was more a could (to learn about possible attacks and protect against them, even requiring a security policy update).

Regarding my last point on the IPv6 distributed security issue, the design team, we have already started to work, and have decided a set of milestones, expecting to have them documented for the next meeting. If someone is interested, please let me know directly, or use the list ([email-masked]).

Last but not least, if possible use Jordi instead Palet (I hate this one !, worst case Jordi Palet), if possible (in any case, we should uniform the minutes in this sense).

Regards,
Jordi

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 12, 2004 10:17 AM
Subject: IETF59 minutes and presentations

> Please send corrections, omissions, etc., to the chairs within a week

**********************************
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: Sat, 13 Mar 2004 07:41:32 +0200 (EET)

> were we tried to go down to one transition mechanism and failed...

Actually, the point about one vs many was completely misunderstood by 
the WG (or completely misrepresented by me).  Stay tuned for a 
clarification.

The point was basically -- could we cut down the number of mechanisms 
to configured tunneling, 6to4, Teredo, and XXX.. where XXX would have 
to be picked or defined somehow... or would we need MORE than these 
four.

> completed. And at the end of this exercise, we are still trying to
> answer the same questions, do we need automatic vs assisted
> place by ISPs. But still no simple recommendation on how to do
> transition.

I think the scenarios themselves, except for enterprise, are quite 
near to completion.  The difficult part, always, has been trying to 
cut down the number of transition mechanisms, or to find a a very low 
number of common mechanisms.

The scenarios could have completed a year or two ago if we accepted
that the total number of transition mechanisms was something like
5-6...

-- 
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: Sat, 13 Mar 2004 07:59:39 +0200 (EET)

> can someone point me how things are different?

Road warrior has made a contract with an ISP, which is his back-up
long-distance number.  If we assume that all the users would have to
make a contract/signup/whatever with a long-distance virtual IPv6 ISP,
then this would probably be the case.

What I'd like to get is when the local ISP is offering the tunnel
service, the user would get directed there automatically, and would
become aware of it so that he could start using that service instead
(instead of using long-distance service).

That is, I think we want to avoid these "long-distance calls", and we
want to make it easier for the user to notice whether there is support
in the local ISP.  Additionally, the configuration of tunneling IMHO
should be close to zero-config.  (Looking up tunnel server addresses,
signup forms, or whatever in the web is unacceptable -- and that's one
reason why the tunnel broker model hasn't seemed to fly so well so
far..)

If we want to make this easy for the users, that seems like something 
that would have to be done.  Especially if we insisted that we 
wouldn't need Teredo.

Hopefully I answered your question..

---

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

Hi Pekka,

I agree with your point of view, indeed we are working on this approach (more TBs, more "local") and for the "auto-location" of the TB, we are already working on several ideas, and will try to present something at the next meeting.

Regards,
Jordi