[RFC] resolvconf(8) interface id

[Aleksandr Rybalko]

Hi,

On Wed, 15 Jun 2011 20:21:15 +0000
"Bjoern A. Zeeb" <bzeeb-lists at lists.zabbadoz.net> wrote:

> On Jun 15, 2011, at 4:53 PM, Hiroki Sato wrote:
> 
> Hi,
> > ...
> > My proposal is adding a string representing the information source
> > to the interface id which is used for resolvconf(8).  Specifically,
> > I would like to propose to use the following syntax throughout
> > utilities that update /etc/resolv.conf via resolvconf(8):
> > 
> >  ifname:origin[:unique]
> > 
> > "em0:dhcpv4" for dhclient, "em0:slaac" for rtsold, for example.
> > Using this string as an interface id, resolvconf(8) can handle
> > multiple RDNSS entries on a single interface without overwriting
> > each other.  Furthermore, priority control can be done with
> > resolvconf.conf and "origin" and/or "unique" keyword in the string.
> > 
> > To adopt this naming scheme, patches are needed for dhclient(8),
> > rtsold(8), and all of other resolvconf(8)-aware utilities.  There is
> > almost no user-visible change; the difference is that multiple RDNSS
> > entries on a single interface are aggregated and added into
> > /etc/resolv.conf after patching them.
> > 
> > Any objections to this?  I am working on the necessary changes for
> > utilities in the base system and planning to commit them if there is
> > no strong objection.
> 
> having helped some friends running penguin OS in the past I have been
> confronted with what OpenSuse does.  Apart from a completely over
> engineered framework they have the ability to sort entries by ifname
> or regex at least, which I am not sure our current openresolv.conf
> provides.  I think all policy should go into that one config file as
> in order of interfaces and order of programs.
> 
> I am not entirely sure I like "slaac" or "dhcp4".  I wonder if
> progname would be sufficient in call cases either (I could well see a
> "dhclient" or another "fooapp" that can handle both v4 and v6) but in
> that case it would probably be a matter of third order -- address
> family.
> 
> Example:
> 
> prefer v6
> intorder "tun* gre* gif* wlan* em*"  or similar (maybe classes lik
>        "wired" or similar.  not sure how easily we could do that). 
> progorder "dhcp* rt*"

Maybe better to add default but changeable preference for each iface,
like STP do:
1000Base - 20
100Base - 200
PPP - 2000

sources able to give IPv6 info for as we can give more preference
(1000Base w/ IPv6 info - 19, 100 w/ v6 - 199, etc.)

> 
> But then we also have the static manual config which would always go
> in from the config file.
> 
> In short:  yes I like the general idea.  Details can be shaken out
> later. Priority more likely in the config file eventually rather than
> coded into programs.
> 
> Have you discussed that with $upstream vendor as well or do we
> consider further changes to be simple enough to merge them in?
> 
> /bz
> 
> -- 
> Bjoern A. Zeeb                                 You have to have
> visions! Stop bit received. Insert coin for new address family.
> 
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"

Embedded world wait for it, to make FreeBSD based routers better than
others :)

-- 
Aleksandr Rybalko <ray at ddteam.net>