In message <199708240603.QAA18628@goanna.cs.rmit.edu.au>Luke Mewburn writes

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

>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?

I don't agree, I think  the defaults for aliases should be the same
as for primary addresses, unless otherwise specified.

I have hosts on net-36, with either aliases on net-10 or additional
interfaces with net-10 addresses.

I would almost buy defaulting to the same netmask as the primary
address, *if* the network part was the same.  But that assumes the
users is using a homgenous netmask on all subnet.

And think about what happens if, e.g., the netmask of the primary
address subnet changes (a routing change, not a local ifconfig
command)?  I don't think that should automagically change the netmask
of an alias -- especially not an alias on a different net!

So I really think the current behaviour is the right engineering
choice. If you don't want a class-based netmask on an alias, you
should specify it.

If I could veto this change, as proposed, I would.  I'm less sure
about the case of same-network-as-primary-address.



Problem 2/3 workaround:


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

To coin a phrase, ``Ewww''.  I would PR that if I ran into it.

I guess the underlying problem here is the gross code that
automagically adds the cloning route entries for ARP.  That code
should really go away; the 4.4BSD comments say it should, and it
breaks the proxy-arp code I did a year or so ago.


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


Yeah, I've seen this for years and years. I used to delete
the old route and arp entries by hand.  I can guarantee that
this is __not__ a side-effect of the newarp code. It goes
back to 1.2 and IIRC even to 1.1.

[is this related to newarp?]

No.  Absolutely not.