Subject: RE: Treating Tunnels similar to routing entries.

From: Richard Draves <[email-masked]>
Date: Tue, 6 Jul 1999 15:22:57 -0700

> >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, som
> >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.
> 
>   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.

MSR IPv6 also uses this approach for configured tunnels. Indeed it works
fine. But as we work on support for dynamic routing protocols, we'll
probably change to representing configured tunnels as interfaces.

I think the specs should allow both implementation strategies.

Rich
--------------------------------------------------------------------
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: Tue, 06 Jul 1999 18:31:30 -0400

>probably change to representing configured tunnels as interfaces.

  The netproc stuff I've been working on mostly for IPsec purposes provides a
viable way to do dynamic routing protocols without the need for tunnel
interfaces. A lot of the routing people have decided that they need tunnel
interfaces and are writing specs that way. I've tried to unconfuse them and
get them to see what it is that they really need (which is to know where a
tunnelled packet came from and to be able to send it back the same way), but
haven't had a whole lot of luck at it.

>I think the specs should allow both implementation strategies.

  I think so, too, but that's not the way that some of the specs have ended up.
If you want to be strictly conformant, you have to implement tunnel interfaces.

									-Craig