> > 	... or ip_mroute.c should be converted to use encap_attach{,_func}()?
>That would be another way, yes.  However...
>The vifs are only used by mrouted(8) to create v4-in-v4 tunnels per the
>`tunnel' keyword in mrouted.conf.  We could conceivably rip the `tunnel'
>support out of mrouted(8) completely, use `gif' interfaces exclusively to
>configure the tunnels, which should work using mrouted.conf's `phyint'
>keyword.
>...this would certainly clean up some code that is in desperate need
>of cleaning up.

	are you sure that mrouted is the only customer of vif?  i'm not
	an multicast (specifically, v4) expert, but there could be someone
	using it, so i thought that rewriting ip_mroute.c is better than
	rewriting mrouted.

> > 	the current code (encap4_input) has last-resort fallback case at the
> > 	end, so there should be no problem.
>Right, the issue is when something else (e.g. `gif') adds a tunnel that
>conflicts with an MRT tunnel or vice-versa ... if two conflicting `gif's
>are configured, and error is returned, but the check is not done if a
>conflict is caused by MRT, so the MRT path silently fails.
>(Although it may `work' by sheer coincidence, now that I think about it :-)

	I can think of two differences (maybe more):
	- m->m_pkthdr.rcvif will be different
	- sanity check logic is different (gif is more strict)
	other than those, they should work okay even if we configure the
	same address pair for vif and gif.

itojun