Date: Wed, 01 Oct 1997 00:18:58 +0930 From: Mike Smith <mike@smith.net.au> To: hackers@freebsd.org Subject: Interface configuration : call for ideas. Message-ID: <199709301449.AAA00810@word.smith.net.au>
next in thread | raw e-mail | index | archive | help
In the light of various issues I've been considering the way that
network interface configuration is handled from user-space.
Currently, interface configuration is handled by /etc/rc.network at
startup for static network interfaces, by /etc/ppcard.ether for PCCARDs
and by assorted internal configuration magic for PPP and SLIP links.
In many cases this diversity is undesirable. It doesn't handle adding
such extra interface attributes such as static routes in a consistent
fashion, and it is difficult to configure.
To address some of these concerns, a model along the following lines is
proposed. Please note that there are undoubtably problems with this
model, and the author would appreciate vigorous criticism of any
percieved weaknesses.
If this is swallowed reasonably well, a proposed '/etc/rc.interface'
and accompanying details will be put forward. Comments?
= = = = = = = = =
The arrival of an unconfigured interface is viewed as an event. The set
of consequences of this event should include:
- Startup script(s) for the interface and address families being run.
- The interface being given address details, possibly for more than
one address family.
In order to achieve this, the following information may need to be
available or inferrable:
o An association between an interface name or type and an address.
This may be effected by allowing interface address details to be
attached to an interface name or type. On interface arrival, if no
address details are attached to the name of the interface, details
should be retrieved from the first association to the interface type.
One means of achieving this would be to evolve from the current
rc.conf parameters. For example, consider :
ifconfig_ed0="inet 10.2.3.4"
ifconfig_lan="inet 10.5.6.7"
The arrival of the interface "ed0" would result in it having the
address 10.2.3.4 configured. If the interface "fxp0" were to
arrive, there would be no address directly associated with it.
In this case, as "fxp0" is of type "lan", the generic "lan"
address 10.5.6.7 would be assigned to it.
Notes: It might be seen as desirable to have more than one of these
generic type-associated addresses available, however it is
not clear how it could safely be determined which interface
should obtain which address.
"Address" should be considered to include "address
solicitation technique" (eg. BOOTP, DHCP).
o An association between the specific arrival event, interface name
and address details. Such information may be attached to the
arrival event, as it is likely to have been derived as part of the
arrival process (eg. PPP negotiation, SLIP login, etc.).
o Locations to be searched for startup scripts.
The departure of an interface is viewed as an event. The set of
consequences of this event should include:
- Shutdown script(s) for the interface and address families being run.
- Address details being taken from the interface, if it still exists.
In most cases, the removal of an interface automatically cleans up
behind itself. Shutdown would only be relevant if there were daemons
associated with the interface which needed to be cleaned up.
The arrival of new address information on an interface is viewed as an
event, with the following possible consequences:
- Routing alterations being made to accomodate the new interface.
A specific set of routing directives should be associated with an
given interface address, or possibly indirectly via the interface name
or type. This might be achieved by adding a directory etc/routes
containing files named after interfaces, interface types or interface
addresses, or possibly definitions in rc.conf. There are a number of
possiblities for feature-creep here (eg. matching to a range of
addresses).
The departure of address information is viewed as an event, with the
following consequences:
- Routing information for the interface being removed, if it still
exists.
This should normally be taken care of by the removal of the interface
iteself.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709301449.AAA00810>