route cacheing for gif(4) should be optional

[Andre Oppermann]

Gleb Smirnoff wrote:
> 
> On Thu, Nov 25, 2004 at 09:55:10PM -0500, James wrote:
> J> On Thu, Nov 25, 2004 at 05:06:41PM +0300, Gleb Smirnoff wrote:
> J> >   Back to this problem:
> J> >
> J> > http://freebsd.rambler.ru/bsdmail/freebsd-net_2004/msg01305.html
> J> >
> J> > I've found two more people who dislike this feature of gif(4).
> J> > So I'd like to make it optional.
> J> >
> J> > We already have LINK2 flag removing sourceroute filter from gif(4),
> J> > which is commonly used in asymmetrically routed networks. I suggest
> J> > to use this flag also for disabling route cacheing, since asymmetricity
> J> > often appears in dynamically routed networks, and if one runs dynamic
> J> > routing, he probably wants to remove route cacheing, too.
> J>
> J> I'd think we should create a separate option for removing the route
> J> cache. Sometimes, certain people want to use the tunnel at the highest
> J> maximum performance possible with both sourceroute filter disabled
> J> and tunneling routes allocated at their creation time. Perhaps link3 is a
> J> good place for this option?
> 
> There is no LINK3 flag :)
> 
> However, gif(4) does not use LINK0 flag. It was used in past. We can utilize
> it now. Any objections?

IMO you should scrap it altogether.  However there have been reasons for
storing the rtentry pointer in struct gif.  In the old days ip_output()
required an rtentry pointer to be passed on, this is no longer the case.
And it was sort of a safe-guard to make it harder to send the gif encapsulated
packets back through the same gif interface.  That didn't work really well
and as I say it should be scapped instead of rigged on somewhere else with
yet another obscure option. ;)

-- 
Andre