Interface aliases have a few niggly problems, and I've been
experimenting around in an attempt to determine a rhyme or
reason to them. I'm not sure if these are bugs in all 4.4BSD
derived systems or are only present in NetBSD.

In my examples, the following state will have been setup on the
machine:
	# ifconfig lo0 inet 127.0.0.1
	# ifconfig ed0 inet 131.170.1.1 netmask 0xffffff00

If any of the problems I highlight are to be expected, then I
believe that we should document this in the appropriate manual pages
(most likely the 'alias' section of ifconfig(8)).


Problem 1:
----------

If an alias is added to ed0 without specifying a netmask,
the netmask used for the alias address is the default for
the class of the new address. E.g
	# ifconfig ed0 inet alias 131.170.2.1
results in a entry in the routing table like:
	Destination    Gateway    Flags  Refs  Use   Mtu  Interface
	131.171        link#1     UC     0     0     -    ed0

I believe the default netmask for an alias should be the same as the
primary address. This problem is probably solvable by hacking ifconfig(8).
Thoughts/comments?


Problem 2:
----------

If an alias is added to a subnet that another interface is already
configured on, an error will occur. E.g:
	# ifconfig ed0 inet alias 131.170.1.2 netmask 0xffffff00
	ifconfig: SIOCAIFADDR: File exists

I believe this is because of the lines in
sys/net/route.c::rtrequest() :-
		if (rn == 0) {
			if (rt->rt_gwroute)
				rtfree(rt->rt_gwroute);
			Free(rt_key(rt));
			Free(rt);
			senderr(EEXIST);
		}

Whilst this is probably correct (otherwise configuring up aliases for
the same subnet on different interfaces would require multiple copies
of the same route to different interfaces, which is illegal), the
error is confusing to the user.


Problem 3:
----------

Aliases configured in the same subnet as an existing one (see
Problem 2) don't get the 'automatic route addition to localhost'
feature (refer to: sys/netinet/if_arp.c::arp_rtrequest(),
case RTM_RESOLVE:)

An explicit 'route add <aliasaddr> localhost' is required so that
the machine can send packets out on the interface...


A user-level work-around for Problems 2 and 3 is to use a netmask of
0xffffffff for interfaces that are on the same subnet as existing
addresses. This results in routing table entries of the form:
    Destination     Gateway            Flags  Refs  Use   Mtu  Interface
    131.170.1.2     00:00:de:ad:be:ef  UHL    0     4     -    lo0 =>
    131.170.1.2/32  link#1             UC     0     0     -    ed0

Side effects of this workaround include:
	* The address doesn't respond to broadcast pings on the same
	  subnet as other interfaces do. This is to be expected, due
	  to differing netmasks.


Problem 4
---------

When an alias address is deleted the following things don't get
cleaned up:
	* the route 'automagically' added to localhost isn't removed
	* the permanent arp entry added because of the above isn't
	  removed.

The problem with this are if you create an alias to masqerade as an
address for a while, and then take it down to let the original machine
have its address back, the current machine won't be able to contact
the other address because of bogus route and arp entries.

I'm not sure if this exists in 4.4 or is an artifact of our newarp
code, but I don't have access to a 4.4 derived machine that isn't
running NetBSD's newarp code.

Can someone check this out on BSDI or FreeBSD?


Summary
-------

The modifications I made to /etc/netstart a while ago (to configure
lo0 before other interfaces to take advantage of the 'automagic route
to localhost' feature of 4.4) solved a couple of problems I was having
with the networking code, but it appears that interface aliases still
need some work...