In the past gif(4) had a multi-destination behavior.  One did
'ifconfig link0', and the gif had two behavior changes:

a) incoming packets were accepted even if the source address did not
match the configured destination (which was INADDR_ANY I think), and

b) the outer destination address of outgoing packets was taken from a
gateway route sockaddr obtained from the lookup the inner destination
(that pointed to the gif in the first place).

So, you could 

  route add 192.168.0.1 10.0.0.30 -ifp gif0

to cause packets for 192.160.0.1 to be encapsulated to 10.0.0.30.  For
one such route, this doesn't make any difference, since the
destination could have been set with ifconfig tunnel, but if one wants
to have large numbers of such routes, and to accept packets from
(possibly unknown) such peers, it is very useful; the routing table
scales better than the interface list.

The multi-destination behavior was removed in 2001:

  http://mail-index.netbsd.org/tech-net/2001/05/12/0000.html

I need to resurrect this behavior or something functionally equivalent
for the implementation of a Mobile IP-like system.  The actual code
changes are about 25 lines. 

One can think of multi-destination gif as Ethernet-like, where
point-to-point gif is like, well, a point-to-point interface.
The set of all multi-destination gif machines on the Internet form a
NBMA subnet for exchanging packets.  This is like stf(4), except that
stf(4) has the mapping rules built-in instead of getting them from the
routing table.

So, how do people feel about multi-destination gifs?  Clearly wanting
to have an interface that has this functionality is reasonable, but
perhaps there is a notion that it shouldn't be part of gif(4)?

Itojun objected to the layering violation, since the outer destination
was taken from the gateway sockaddr.  This is the AF of the inner
address, and the normal semantics of gateway are that the packet is
sent to the lladdr of the gateway.  So while he is certainly right
that this is odd, a case can be made that in gif-land the 'lladdr' of
the gateway is the IP address - an IP header is added rather than an
Ethernet header.

An alternative which is more pleasing from a layering point of view
would be to have a route which has the llinfo flag set, and a sockaddr
as llinfo which is the AF of the gif's outer addresses.  This has the
same behavior, but might require a bit more changes to allow IP
addresses in llinfo sockaddrs (or hopefully, IP sockaddrs stored with
the llinfo flag, to be type-safe).

One could also consider that in the gif world that a host has an IP
address and a "GIF link-layer address" which is the same.  So one
could view the old behavior as exactly correct, with the addition of a
code-free mapping step from the IP address of the gateway to the
link-layer address of the gateway.  This approach does have the likely
minor limitation that the gateway and the inner addresses have to
match families.

I'm going to bring the old behavior forward for my own use in any
case.  If doing it differently (without lots of extra time...) would
mean the changes are more likely to be accepted, I'd be happy to do
that.

Comments?

    Greg Troxel <gdt@ir.bbn.com>