Subject: Treating Tunnels similar to routing entries.

From: Peter Tattam <[email-masked]>
Date: Mon, 5 Jul 1999 16:02:25 +1000 (EST)

Sorry..  me again :)

In my implementation of dynamic tunnel client/servers and integration of
tunnels into the TCP stack, it became apparent that treating tunnels as
interfaces was a bit of overkill, and that they could be more efficiently
managed as a hybrid sort of routing entry.   In fact in my latest version, some
significant code was moved out of the interface and directly managed by the
main IP packet processor.  With some minor modifications, the whole lot could
be managed as something akin to a routing entry.

Has any thought been given to this kind of treatment to the subject?  Or is it
an implementation detail that needs no further discussion.

Peter
--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Craig Metz <[email-masked]>
Date: Mon, 05 Jul 1999 02:12:46 -0400

In message <[email-masked]>, you
 write:
>managed as a hybrid sort of routing entry.   In fact in my latest version, som

  The NRL implementation has done this since 1995. It works fine. It has
certain advantages. However, the WG pretty much decided that a tunnel is an
interface; certain specs make this assumption and more or less force you to
take that approach if you want to be fully compliant.

									-Craig

---

From: Peter Tattam <[email-masked]>
Date: Mon, 5 Jul 1999 16:21:44 +1000 (EST)

> take that approach if you want to be fully compliant.

That's fine.  My code is fairly efficient anyway, and the only time the tunnel
interface is referred to in traffic processing is in the send routine.  As the
interface already has an implied route attached to it, I don't believe that
much more efficiency could be gained other than a few cycles here & there.  In
my stack, virtual interfaces can come & go as they please.

Peter

---

From: Craig Metz <[email-masked]>
Date: Mon, 05 Jul 1999 02:24:02 -0400

In message <[email-masked]>, you
>my stack, virtual interfaces can come & go as they please.

  Be careful; the basic and advanced APIs don't like interfaces coming and
going too quickly.

									-Craig

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 06 Jul 1999 06:05:40 -0500

The 6to4 proposal (which is an NGTRANS item) actually works
best if you think of tunnels as routing entries, but nevertheless
there has to be an element of interface present since 6to4 provides
a prefix and prefixes tend to go with router interfaces.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
On assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]