Subject: (ngtrans) reconsidering the Tunnel Setup Protocol (TSP) as an ngtrans project

From: Bob Fink <[email-masked]>
Date: Wed, 19 Dec 2001 11:09:30 -0800

ngtrans folk,

Marc Blanchet has requested the ngtrans chairs to reconsider the two drafts 
on a Tunnel Setup Protocol (TSP). There was not much show of interest in 
them at the London ngtrans meeting. We chairs believe there is merit in 
Marc's request.

<http://search.ietf.org/internet-drafts/draft-vg-ngtrans-tsp-v6v4profile-00.txt>

<http://search.ietf.org/internet-drafts/draft-vg-ngtrans-tsp-00.txt>

Though the TSP provides a similar service to the Tunnel Broker, it 
represents a next step beyond the web-based tunnel broker to get around 
problems users were having. My own experience of user interactions with the 
existing Tunnel Broker shows strong usage and support for it, but that 
users are having the very problem that TSP addresses.

 From the v6v4profile ID

>     A Tunnel Broker implementation with a web interface revealed many
>     practical problems :
>
>     o  Using Web interfaces for Tunnel Broker limits the scalability of
>        deploying IPv6 networks and hosts at very large scale over
>        Internet.  Web interface requires manual operation from end-users.
>
>     o  End-users that uses dynamic IPv4 addresses must go back manually
>        to the Tunnel Broker's web interface each time their IPv4 address
>        changes
>
>     The Tunnel Setup Protocol (TSP) approach proposes a negociation of
>     tunnel parameters between Tunnel clients and Tunnel Servers.  The
>     proposed protocol is able to handle different kinds of tunnel over
>     IPv4 such as IPv6 configured tunnel, DVMRP tunnels over IPv4 for
>     multicast and others.  In the current document, examples of the
>     protocol are focused on IPv6 configured tunnel.

In addition, client implementations have already been included in 
distributions of freebsd and linux.

The Tunnel Broker has been important to transition activities to date in 
getting early users connected to the 6bone, and the TSP is quite likely to 
be even more widely supported over time.

Thus we propose accepting this work as an Experimental RFC effort to help 
promote the usage and to see if it warrants future Standards Track effort.

Comments to the list please.

Bob Fink, Alain Durand, Tony Hain
ngtrans co-chairs

---

From: Alain Durand <[email-masked]>
Date: Wed, 19 Dec 2001 22:54:46 -0800

>promote the usage and to see if it warrants future Standards Track effort.

The Tunnel Broker is a generic model. It has been implemented through a web 
interface
so far, but this is not the only solution suggested by RFC3053.
This proposal is to develop a protocol to make dialog between Tunnel Client,
Tunnel Broker and Tunnel Server more automatic.

I think the working group need to answer two questions:

A. Does the working group need to do work in that space
or are the current tunnel brokers sufficient for early adopters?
Isn't the general problem that this proposal address already solved by 
other means? (6to4)
My reading of the London meeting discussions was that current tools were 
sufficient.
Marc wanted to ask again the question, so the discussion is now in the
mailing list to see if there is active support or not for work in that area.

B. In case the answer to the first question is we need to define something 
in that space,
the second question becomes: is this proposal the right approach?
Tunnel set-up is a very general problem that span way beyond IPv6 transition.
First thing that comes to mind is VPN setup.
Maybe some other working groups are interested or are looking at a solution.
I'm not sure this working group should engage in standardizing a generic tunnel
set-up solution, but I would like to see other feedbacks.

My personal take (chair hat off) is that this is not absolutely needed
but may be worth some experimentations.

         - Alain.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Dec 2001 10:14:33 +0100

Alain Durand wrote:
...
> but may be worth some experimentations.

What I am beginning to hear from potential users is "Pleeease, no
more transition techniques, we have too many to choose from already."

I think we should just stop, unless an absolute need is identified,
and concentrate on bringing all the existing solutions to product
quality (or declaring them Historic, as I suggested for 6over4 in
the meeting).

   Brian

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 20 Dec 2001 09:34:36 -0500

> more transition techniques, we have too many to choose from already."

I hear that too. and our tutorial slides on transition is pretty thick 
these days... ;-))

However,
- does the fact that this is one of the last ones to be submitted, mean 
that it is not a good tool?
- does this comment mean that all new ideas that come will be withdrawn?
- in fact, our work is not a new technique, it is an enhancement of the 
tunnel broker technique.

Marc.

> quality (or declaring them Historic, as I suggested for 6over4 in

------------------------------------------
Marc Blanchet
Viagénie
tel: +1-418-656-9254x225

------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
http://www.normos.org: IETF(RFC,draft),
  IANA,W3C,... standards.
------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 Dec 2001 17:00:42 +0200 (EET)

> >     A Tunnel Broker implementation with a web interface revealed many

These problems don't have to be problems.

> >        Internet.  Web interface requires manual operation from end-users.

There could be a very small implementation, using telnet, even, which 
gathers this information off a web site automatically.  I believe many 
have done it with lynx or equivalent.

> >        to the Tunnel Broker's web interface each time their IPv4 address

When dynamic IPv4 address changes, the operating system usually alerts it 
in some way or another.  Or one could watch these events.  Then, the 
procedure could be redone, from above.

> >     protocol are focused on IPv6 configured tunnel.

It's good to be generic, but there is little need for genericity in this 
case; only IPv6 is needed to some extent right now.

(arguably, free multicast tunnels would be an interesting thing also, but 
could more easily result in loops I fear).

> distributions of freebsd and linux.

This may be a little misleading statement.
 
From other mails:

> more transition techniques, we have too many to choose from already."

I agree.

(for example, tunneling with BGP was another idea here which might be 
interesting, but there are too many mechanisms already).

General comment:

IMO, tunneling can be dangerous and should be avoided especially between 
untrusted parties.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Dec 2001 16:54:11 +0100

> that it is not a good tool?

No (nor does it mean the opposite:-)

> - does this comment mean that all new ideas that come will be withdrawn?

Not really, but it means we need a really solid reason to accept a new idea.

> - in fact, our work is not a new technique, it is an enhancement of the

Fair comment.

   Brian

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 20 Dec 2001 11:01:04 -0500

> case; only IPv6 is needed to some extent right now.

then ipv4overipv6, then ipv6overudp-ipv4, ...

> This may be a little misleading statement.

http://www.freebsd.org/ports/ipv6.html#freenet6-0.9.5

> IMO, tunneling can be dangerous and should be avoided especially between

tsp works with authentication before establishing the tunnel. So we agree, 
right?

Marc.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Dec 2001 18:34:18 +0100

In your previous mail you wrote:

   However,

=> the problem is different: it seems some old mechanisms shall be
withdrawn from not technical criteria. For instance I still argue
that 6over4 is superior to ISATAP when multicast is locally available
even if 6over4 is not currently supported by Microsoft & Cisco.

=> so the no new things if not far better argument doesn't apply.

Regards

[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 20 Dec 2001 11:03:21 -0800

Francis,

> even if 6over4 is not currently supported by Microsoft & Cisco.

For the record, ISATAP currently supports a limited multicast capability:
it allows ISATAP hosts to send RS's to the 'All_Routers_Multicast' address
such that they will be received by an ISATAP router. ISATAP can easily be
extended to support a full IPv6 multicast capability when IPv4 multicast
routing is enabled within the site, but up to this point work has focused
on:

 1) making the NBMA mechanisms work
 2) keeping ISATAP as simple as possible

In my opinion, adding IPv6 multicast support for IPv4 multicast-enabled
sites would be consistent with 2) without impacting 1). But, it is not
clear whether this should be a goal for the draft. Comments?

Fred Templin
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Thu, 20 Dec 2001 14:02:04 -0800

>that it is not a good tool?

No. It means it has to explain what problems it solves that is not already 
solved
one way or another. Being "somehow" better is not good enough anymore.
Being significantly better or solving a problem that is not already 
addressed are
good criteria to accept new project.

>- does this comment mean that all new ideas that come will be withdrawn?

No. See above.

>- in fact, our work is not a new technique, it is an enhancement of the 

Yes, it is a enhancement of an existing technique, but it introduce a 
completely new protocol.
The question is where does this fit in the global picture.
We already have existing tunnel brokers that works well with their 
configuration tools
for very sparse deployment, we also have 6to4 for completely automatic tunnels,
and even ISATAP when you want some automatic tunnel set-up within a site.

         - Alain.

---

From: [email-masked]
Date: Fri, 21 Dec 2001 11:27:53 +0900

>- in fact, our work is not a new technique, it is an enhancement of the 

	I understand the feeling that we have too many tools in our toolbox.
	I agree in general.  However, I find it useful to document this
	particular instance of tunnel broker framework.  Since Marc's proposal
	uses machine-parsable protocol exchange it should be documented
	somewhere (otherwise non-interoperable implemeneitations will appear).
	It is also heavily used (at freenet6.net) and known to work well.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Dec 2001 11:49:08 +0100

Fred,

> clear whether this should be a goal for the draft. Comments?

I don't see the point, since 6over4 is actually a trivial amount of code
and solves the problem elegantly. We specifically chose not to solve
the NBMA problem in 6over4, since it is so much harder.

The issue with 6over4 is that the set of sites supporting IPv4 multicast
and wanting to deploy IPv6 appears to be too small to justify investment
in supported products. On that evidence, you would waste your time by
adding multicast to ISATAP.

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Dec 2001 16:39:23 +0100

I am afraid that the indisputable superority of 6over4 for multicast
is only a good argument on the paper. Obviously this point has no value
for transition mechanism, of course the fact that native multicast IPv6
is far from to be available has to be taken into account...

Regards

---

From: "Fred L. Templin" <[email-masked]>
Date: Fri, 21 Dec 2001 09:21:29 -0800

Francis,

Brian Carpenter's feedback was that he didn't feel we should go to any
length to support multicast in ISATAP due to lack of ubiquitous IPv4
multicast deployment - other opinions?

BUT:

Francis Dupont wrote:
> is only a good argument on the paper.

I would dispute this claim, since ISATAP can handle multicast as follows:

  1. Define a function F that maps IPv6 multicast addresses to a number of
     IPv4 multicast addresses reserved for this purpose. (F can be exactly
     the same function as that defined in Appendix A of RFC 2529).

  2. When the ISATAP pseudo-interface sends an IPv6 multicast packet, it
     performs function F on v6_dst to derive v4_dst. It then performs
     IPv6-in-IPv4 encapsulation, using v4_dst as the destination address
     for the encapsulating IPv4 header. Addresses are as follows:

        v6_src: an IPv6 address assigned to the ISATAP pseudo-interface
                (by definition, this will be an ISATAP-format unicast address)
        v6_dst: the IPv6 multicast address
        v4_src: an IPv4 address assigned to the IPv4 link to which the
		ISATAP pseudo-interface is bound
        v4_dst: F(the IPv6 multicast address)

  3. For sites that have IPv4 multicast deployment, normal RFC 2461
     mechanisms now work exactly as specified when 1. and 2. are
     implemented.

Obviously, other details would need to be worked (i.e. when to use
IPv6-in-IPv4 multicast vs. when to use NBMA unicast.) But, I claim the
core mechanism I described above is at least as elegant as 6to4.

> Obviously this point has no value

Fred
[email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 21 Dec 2001 10:45:25 -0800

Francis,

6over4 is a technically sound approach which is not viable in the
general case because IPv4 multicast has not been widely deployed. We
can't fix the IPv4 multicast deployment issues, so keeping 6over4 around
only serves to further confuse those who are trying to figure out a
transition plan. It is our responsibility to provide a clear path, not
simply a toolbox.

Tony

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 21 Dec 2001 14:48:17 -0500

-- vendredi, décembre 21, 2001 10:45:25 -0800 Tony Hain <[email-masked]> 
wrote/a écrit:

> transition plan. It is our responsibility to provide a clear path,

well, then maybe I would suggest another approach for the wg and chairs:
- identify (with the help of some process to be defined) the 
recommended-by-the-ngtrans-wg transition techniques, and promote them 
standard track
- have all the others being experimental/informational. This will leave 
people who believes in a technique which is not in the restricted set to 
use it and have at least a spec where multiple implementors can use and 
have a minimal interop between them.

I do agree that we have too many on the plate for the generic cases, and we 
need to identify a smaller set. However, the way to handle the "others" 
might be instead to have one "roadmap" document that clearly identify the 
smaller set and leave the others as outside of this roadmap document.

a suggestion.

Marc.

> not

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 21 Dec 2001 13:09:05 -0800

Marc Blanchet wrote:

> - have all the others being experimental/informational.

This is fundementally what the updated ngtrans charter is about.

> This will leave

Agreed with the minor caveat that if a specific approach has been found
to cause a really bad interaction with the existing network (like IPv4
compatible addresses causing route table bloat) that we may want to move
them to historic rather than simply take them off the stds track.

> smaller set and leave the others as outside of this roadmap document.

It will probably be a set of documents, each with a specific focus. The
approaches used in an enterprise are likely to be very different from
those used in a 3G network, so putting them in the same document may not
do much to lower the confusion.

Tony

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Dec 2001 20:12:42 +0100

=> I agree: the days of multicast are to come (if they'll come).

   
=> you are losing your time (first you don't convince anybody,
second it doesn't matter).

=> 6to4? If this is a typo in 6over4 you have nothing to do for multicast,
i.e. you get it for free... and you have no usage of it.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Dec 2001 20:19:36 +0100

=> this is an argument to not advance it, not to make it "historic".
The clean path is the role of introduction document
(draft-ietf-ngtrans-introduction-to-ipv6-transition-xx.txt).

Regards

PS: if you'd like to clean the house before the spring (:-),
I suggest to move automatic tunnels and IPv4-compatible IPv6
addresses to historic ASAP.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Dec 2001 14:45:49 +0100

I think having a roadmaps (plural) document is the best approach to
deconfusing users (and vendors). It is quite possible that some
solutions will turn out to be roadkill, but then there are hundreds
of Proposed Standard RFCs lying at the edge of the road already.

Retrurning to the original subject of this thread - I should
make it clear that I am actually agnostic about TSP - frankly I
haven't studied it enough to have an opinion. I didn't mean to express
the opinion that TSP should not become an NGTRANS project; just that
it's time to think carefully about the number of recommended mechanisms.

   Brian