Subject: RE: Going forward with zero-config tunneling requirement

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Fri, 1 Oct 2004 15:31:40 +0200

Erik, Pekka, All

It is true that some, me included, 
find Isatap to be an adequate solution for 3GPP. 

It is, however, not so that the 3GPP requirements/goals in zeroconf are
specified with Isatap in mind. 

In any case not more so that in the complex process of distinguishing
nice-to-have from need-to-have things then one, of several, things that 
you may squint at is what is known to be achievable, and in this respect 
the features provided by Isatap is _one_ example of the latter. 
But as the authors of zero-conf can testify then we have been extremely careful
with not adding something as a requirement simply because it is achievable - and 
likewise the other way around.

The background behind the 3GPP requirements document, read zero-conf, is the following:

For some time now 3GPP has asked for the support of the IETF
to produce a standardised, solid tunnelling solution that
meets its needs.

Isatap has been identified by some as a potential solution, 
and have been successfully deployed in 
proto-type like 3GPP deployment environments.
Consequently people have pressed for the standardization of Isatap and
by standardisation here then I do not mean "rubber stamping" of the draft but
about qualified technical challenging, tie of loose ends, adjustments of possible
problems - all the things that the IETF normally do when making a "standard".

v6ops have been reluctant to do so, and the answer has been a mixture of the following:
* must wait until all scenarios have been considered, should find unified solution that fits all
* the requirements of 3GPP aren't clear - why do you think Isatap is good for you ?
* Isatap is limited, bad, not the right solution

Here it is probably important for me to emphasize that I absolutely agree that 
finding one unified solution and/or limiting the solution space the best we can, 
would be great, from a pure technical, from an implementation as well as from
a deployment perspective.
 
The problem we have, however, is the following:

No adequate standard has been produced which suits the needs of 3GPP and without a trusted and
consolidated IETF solution then in turn the transition scenario and its solution 
space risk being completely written out of the 3GPP releases (to the extend that is hasn't already been suppressed
as a feasible and recommendable scenario).
Release 6 still include the transition scenario, but the absolutely HARD deadline
of this is November something. Furthermore, Ipv6 and Ipv6/Ipv4 transition 3GPP
deployment trials are starting up, the latter obviously also in need of
a solution, preferably a committed IETF solution.

Zero-conf aims to specify requirements of a simple tunnelling mechanism, which
would suit the needs of 3GPP (possibly also other scenarios).
Now that the requirements at least are written down,
the hope was this could facilitate and speed up the process towards finding a solution.

It has been discussed how to proceed from here and an attempted resolution was
to split the 3GPP requirements in one separate document and produce another one which would
detail the other scenarios needs in the area of zero-configuration tunnelling.

The objective of isolating the 3GPP requirements is not because the same
split is envisaged as automatically mapping over to the solution space. It is done 
first and foremost because of the following:

* The timing requirements of 3GPP are very harsh and it was thought that we could not afford to loose time
by potentially blurring the requirements by the addition of various other aspects to the document.

That being said, it is clear, of course, that in order for us to be able knowingly to choose a solution which 
applies not only to the 3GPP scenario, but also to e.g. the simple enterprise scenario, then the requirements work
of these other scenarios must move very fast too.

BR, Karen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Erik Nordmark
> Sent: Thursday, September 30, 2004 9:37 PM
> To: Pekka Savola
> Cc: [email-masked]
> Subject: Re: Going forward with zero-config tunneling requirement
> 
> 
> Pekka Savola wrote:
> 
> > I was saying that with s/mechanism/requirements/
> > 
> > I.e., having requirements in separate documents, allowing 
> them to be 
> > developed separately, does not mean that the solutions need to be 
> > different.  Similarly, if all the requirements for 
> different scenarios 
> > were in the same document, it wouldn't mean that one solution would 
> > have to fulfill all the requirements.
> 
> But you were excluding the "simple" from the assisted tunneling 
> requirements, and I don't understand why. If this is all about
> allowing different communities needing to express their 
> requirements in 
> a separate document, then don't exclude things from the documents.
> 
> 
> > (Completely personal opinion below)
> > The critical thing will be whether the IETF 'honors' the 3GPP
> > deadlines for a [standards track] solution (November this year).  As
> > you write, doing so would be very counterproductive.  On the other
> > hand, it could be also considered practical and admitting 
> the reality.  
> > However, as such ISATAP will already go for Experimental 
> RFC, so there
> > will exist some documentation to create interoperable 
> implementations
> > in any case.  There doesn't seem to be any particular reason to move
> > it to standards track just because of 3GPP.
> 
> If the purpose of the 3GPP requirements is solely to convince the IETF
> that they will use ISATAP (which they might have already 
> decided), why 
> are we wasting time on a 3GPP requirements document?
> A requirements document makes sense when multiple answers are 
> acceptable, but you seem to be saying that only one answer would be 
> acceptable.
> 
> I don't have a problem with an experimental RFC describing ISATAP as 
> currently implemented, and perhaps a separate document describing its 
> limitations.
> 
>     Erik
> 
>

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 01 Oct 2004 09:26:41 -0700

> problems - all the things that the IETF normally do when making a "standard".

1. 3GPP wants quality output from the IETF.

> by potentially blurring the requirements by the addition of various other aspects to the document.

2. 3GPP needs it by November.

> of these other scenarios must move very fast too.

3. We would all want to avoid too many mechanisms i.e. try to have 
mechanisms which apply for multiple scenarios.

1-3 is an overconstrained problem.
I would argue that 2 is incompatible with 1.

Why can't 3GPP just define a way to carry the IPv4 address of a tunnel 
endpoint in the 3GPP protocol which configures the IPv4 address of the 
terminal (whatever this protocol is called)?
That would provide one solution which satisfies #2.

Then we have time to work on a solution which satisfies #1 and #3.

   Erik

---

From: Fred Templin <[email-masked]>
Date: Fri, 1 Oct 2004 11:23:59 -0700 (PDT)

> 2. 3GPP needs it by November.

The only reasons I could see for such a hard-and-fast deadline would be if:
a) there were near-unanimous agreement that the best possible solution
was in-hand, and the issue becomes one of time-to-market, or: b) a better
(and perhaps inevitable) technical solution were looming on the horizon,
and some would try to block it from happening to protect selfish interests.
 
I have received quite a bit of feedback about ISATAP - both positive and
negative. But, I have not seen compelling evidence to support a) - only
evidence to the contrary.
 
If the nature of the push is instead about b), and the b) people get their
way, then the enduring legacy of the IETF will be one of having snatched
defeat from the jaws of victory.

> mechanisms which apply for multiple scenarios.

I may have been one of the first to use the phrase: "no one-size-fits-all"
in relation to transition mechanisms almost exactly 2 years ago. I did
not know what I was talking about at the time, and (like the bad dog
that gets his nose rubbed in it) have spent the better part of these past
2 years eating those words through a painful discovery process.
 
It seems to me that there is a unified solution on the horizon that can
apply to all scenarios. I'm still not 100% certain as to whether ancillary
mechanisms are needed, but if they are then: 1) they are *very* few
in number, and 2) the big picture has to be about the unified solution;
*not* the ancillary mechanisms.
 
Thanks - Fred
[email-masked]

---

From: "Chen Yan" <[email-masked]>
Date: Tue, 5 Oct 2004 17:12:23 +0800

Dear All,

I am just a newer to study Linux for IPV6.

My linux core is 2.6.I want to add usagi to support IPV6 appication. But I try several usagi such as: usagi-linux26-s****.tar.bz2, all are unavailable.
Whould you please tell me why and what I should do ?

And another question:
How can I add a 6to4 tunnel? 

Thank you !

Yale
RRS716
CS Department
HKBU

---

From: shogunx <[email-masked]>
Date: Tue, 5 Oct 2004 04:27:15 -0400 (EDT)

> Whould you please tell me why and what I should do ?

You simply need to compile v6 support into your kernel, which is native to
the 2.6 series of kernels, meaning that you do not need to patch the
kernel.

> How can I add a 6to4 tunnel?

Please search google for "ipv6 tunnel broker."  You can then choose
which tunnel broker you would like to tunnel to.  The broker you choose
will forward you a script for tunnel setup.

Scott

> HKBU

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/

---

From: "Chen Yan" <[email-masked]>
Date: Wed, 6 Oct 2004 18:34:01 +0800

Thank you very much!
Your tunnel-broker is very easy to use!
But I think what I need is not to use tunnel toker.

My task is to set up 6to4 tunnel mechanism (RFC 3056). I think it is default supported in linux 2.6 kernel.
I have three PC,all have supported ipv6. one has been configured to be ipv6 router.(by IPV6FORWARDING=yes)
the other two are hosts which are in different v6 subnet with different netmask.

Now my problem is 
1: configure ipv6 router to be 6to4 router.How to do it?or it is default 6to4 router because linux2.6 support RFC 3056 default.right?
2:set up 6to4 tunnel on one host. I have done it refering to "LINUX IPV6 HOWTO",but it doesn't work. I really don't know how to do!Would please help me?

Thank you 

Yale

  ----- Original Message ----- 
  From: Miguel Angel Diaz 
  To: [email-masked] 
  Sent: Wednesday, October 06, 2004 3:46 PM
  Subject: Re: why the usagi-linux26-s****.tar.bz2 is unavailable?

  Why don't you try our tunnel-broker? http://tb.consulintel.euro6ix.org/in/index.php

  It is friendly and easy to use. Let me know any issue you have about it.

  Regards

  ************************************
  Miguel A. Diaz
  Telecommunication Engineer
  Support and R&D

    ----- Original Message ----- 
    From: Chen Yan 
    To: [email-masked] 
    Sent: Tuesday, October 05, 2004 11:12 AM
    Subject: why the usagi-linux26-s****.tar.bz2 is unavailable?

    Dear All,

    And another question:

    Thank you !

    Yale
    RRS716
    CS Department
    HKBU

  **********************************
  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.