Subject: Re: updated v6ops agenda, presentation of way forward

From: Syam Madanpalli <[email-masked]>
Date: Wed, 10 Nov 2004 12:07:06 +0000 (GMT)

Hi Pekka,

This move looks good. And I have a question on the proposed new
Tunneling WG.

We are going to develop an entirely new protocol based on the ZCT Requirements?

or WG wants to start with some existing methods and form a design team to
develop

an unified method?

Thank you,

Syam

------- Original Message -------
Sender : Pekka Savola<[email-masked]>
Date : Nov 09, 2004 18:51
Title : updated v6ops agenda, presentation of way forward
Hi,

Slightly modified agenda for tomorrow (relating to the way forward and

tunneling discussions) is below and posted at:

http://netcore.fi/pekkas/ietf/61/v6ops-agenda.txt

Also, the rough slides (these will be updated a bit) are available

beforehand at:

http://netcore.fi/pekkas/ietf/61/way-forward.pdf

....

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Nov 2004 14:10:26 +0200 (EET)

> We are going to develop an entirely new protocol based on the ZCT 

If you read it carefully, the proposal goes a bit further than the 
original ZCT proposals, because the authentication scenario is also 
included. (Feedback is welcome on this.)

> develop an unified method?

That would remain to be seen.  Multiple proposals are probably also 
OK.  I would expect at least some small team is going to get together 
and try to propose at least one solution.

-- 
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: Jeroen Massar <[email-masked]>
Date: Wed, 10 Nov 2004 13:33:29 +0100

Pekka Savola wrote:

<SNIP>
>    http://netcore.fi/pekkas/ietf/61/way-forward.pdf 

8<-----------------
Propose a new WG to write a new IPv6 over IPv4 tunneling protocol
1. Based on the tunneling requirements write one new protocol
2. Work on two components of the solution:
   a) method to discover the tunnel end-point
   b) specification of the tunnel set-up protocol
----------------->8

There are three components to "Tunneling", the third is the actual
protocol, but you mention that in the first part, probably a rephrase
would be better.

Is this only about Tunneling IPv6 over something, or is it a generic
tunneling solution, the latter is called pptp and all the other variants
that already have existed for quite some time, next to that there are a
number of drafts which have been submitted for quite some time already
surrounding this subject and specifically for doing IPv6 over NAT-
crippled IPv4 hosts. I don't recall seeing a draft about Hexago's
v6udpv4 protocol though, not that it is complex but still.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Nov 2004 15:05:16 +0200 (EET)

Hi,

First, a clarification to Jim:

> For clarity.  You say multiple proposals are "probably" ok?  That 
> sounds dictatorial and I don't think you mean't it that way did you? 
> The objective of the IETF is to bring good ideas to our body?

Sorry for the word: too few words.  What I meant to say is that 
multiple proposals are of course OK, but because then the WG would 
have to apply a selection process, it would be desirable (for speed, 
etc.) not to have *too* many proposals: i.e., having multiple 
proposals doesn't have inherent value in itself :).  Selection among 
many would likely be a time-consuming process, so the attempt would be 
to try to propose one that most people would be comfortable with.

Agreed.  We'll try to do that before the final presentation.

> tunneling solution,

Only about v6 over v4[-udp].  It was felt that the focus must be on 
what we know reasonably well.

That is not to say that the solution could not be done in such a way 
that extending it would be simple later on, but that is not a goal of 
the work.

> next to that there are a number of drafts which have been submitted 
> for quite some time already surrounding this subject and 
> specifically for doing IPv6 over NAT- crippled IPv4 hosts. I don't 
> recall seeing a draft about Hexago's v6udpv4 protocol though, not 
> that it is complex but still.

Yes, there have definitely been drafts :).  It seemed that these have 
some short-comings though, so that trying to merge the best parts of 
each to one proposal might make sense.

---

From: Tim Chown <[email-masked]>
Date: Wed, 10 Nov 2004 13:34:16 +0000

I think the word "configuration" is missing up there...

"Propose a new WG to write a new IPv6 over IPv4 tunneling configuration
 protocol"

The WG name would be something like v6tc WG

Tim

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 10 Nov 2004 14:35:21 +0100

On Wed, 2004-11-10 at 15:05 +0200, Pekka Savola wrote:
<SNIP>
> each to one proposal might make sense.

I haven't seen any comments indicating such on both the AYIYA nor on the
heartbeat drafts which I submitted. Then again apparently a lot of
people seem to ignore anything with -00 or -01. I did get quite a number
of positive comments though.

On Wed, 2004-11-10 at 08:10 -0500, Bound, Jim wrote: 
> Thanks for my answer I agree and makes sense to get this done.  FYI
> early adopters are setting up tunnels now and using multiple approaches
> to discover TEPS.  The ones I am seeing dominant right now are private
> company/provider tunnel brokers with set up and hand configured TEPs,

Most tunnel brokers system (the ones I know at least) are fully automated.
Though the automation is mostly simply typing in what otherwise the user
had to type thus making IPv6 connectivity possible for the not so computer-freaky.

Also I think that many of the 'early adopters' are not 'early adopters' any more,
they are mostly around for some 5+ years already. (Freenet6 is around since 1999)
Many entities already have a lot of experience in deploying IPv6 even
though in some areas of this globe only since some goverment agency
started donating big money they started working on it.

> mannual tunnel configured TEPs at edges, and to lesser degree DHCPv6
> with custom extensions.  So a TEP discovery solution is required for
> sure.

DHCPv6? I still have to see that working ;)
Would be nice option to have though, create a tunnel, use RA or DHCP to
get the prefix on the tunnel and possibly also 

The main reason I know that we are not using RA's is that we want the
host to be ::2/64, so we can ping6 it for latency and availability and
then we can also correctly point the prefix to that ip. DHCPv6 could solve
that, but how many hosts/router platforms have that functionality again?
DHCPv6-PD would be really nice to do though.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Nov 2004 15:44:49 +0200 (EET)

Let's try to avoid going into the gritty proto

---

From: Tim Chown <[email-masked]>
Date: Wed, 10 Nov 2004 13:48:03 +0000

> of positive comments though.

As one guilty of having not read it (sorry!) I think the problem is people
have limited time, and the v6ops scope is so broad, with so many personal
drafts too.   

I'll try to circulate a list of v6ops related drafts soon so we can see the
diversity and volume... 

I agree ayiya should be on the table for discussion by the new WG, if the WG 
happens.   But the focus is on the configuration more than the tunneling itself,
as proposed.

I suspect we can draw a lot of experience from methods/tricks used by 
existing systems, e.g. heartbeat protocols to support dynamic IPv4 addresses 
on clients.

-- 
Tim

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 10 Nov 2004 15:13:47 +0100

> I think the word "configuration" is missing up there...

The 'set-up' is the configuration part, configuration is a bit clearer
indeed on what really is happening.

> "Propose a new WG to write a new IPv6 over IPv4 tunneling configuration

"Propose a new WG to define a IPv6 over IPv4 tunnel configuration
protocol"

Would be a better formulation IMHO.

> The WG name would be something like v6tc WG

Sounds reasonable to me.

Greets,
 Jeroen

---

From: Xiao Bing Guo <[email-masked]>
Date: Wed, 10 Nov 2004 22:46:45 +0800

Maybe I did not catch your words. Why should only one solution("at most one

solution") be standarded in the v6tc? I think the goal is to solve the
existing problems. Of course redundant mechanisms should be avoided.
However, is there possible to summarize an "omnipotent" solution? Why we
should guarantee such a limitation before beginning the work.

In addition, when I go through the justification for the IPv6 Tunnel
Configuration work, I find that there is already one and only one proposal
that could meet all the identified requirements. The sole survival is STEP.

I hope it is just a coincidence, or it can answer the question mentioned in

the 1st paragraph.

Best Wishes,

Guo, Lenny

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 10 Nov 2004 16:08:40 +0100

On Wed, 2004-11-10 at 22:46 +0800, Xiao Bing Guo wrote:

> Configuration work, I find that there is already one and only one
> proposal that could meet all the identified requirements. The sole
> survival is STEP. I hope it is just a coincidence, or it can answer
> the question mentioned in the 1st paragraph.

If you mean STEP as in:
http://www.netcore.fi/pekkas/ietf/draft-savola-v6ops-conftun-
setup-02.txt (because it has expired from the id-dir already)

this primarly only defines the problem and mentions some of the various
solutions that can be taken, but no final word is given on actually
doing it, let alone any implementation.

The appendices name a number of other protocols which actually do the
work. IMHO it thus fills some gap between the other problem statements
and solutions documents; While the real problem is more: who are you are
trying to give connectivity, what do you have now and how would you like
to do it. And there is no single solution for that problem, especially
when considering that some ISP's want to use it as an upgrade path to
native lines, without having to renumber their clients later on and of
course with as less possible changes in their infrastructure. Custom
solutions based on a number of predefined solutions is thus probably the
answer, but a single solution, not IMHO ;)

Greets,
 Jeroen