Date: Thu, 16 Jun 2011 14:28:34 +0900 (JST) From: Hiroki Sato <hrs@FreeBSD.org> To: bzeeb-lists@lists.zabbadoz.net Cc: net@FreeBSD.org Subject: Re: [RFC] resolvconf(8) interface id Message-ID: <20110616.142834.63956571381923731.hrs@allbsd.org> In-Reply-To: <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net> References: <20110616.015317.781291617533474654.hrs@allbsd.org> <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Thu_Jun_16_14_28_34_2011_922)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> wrote in <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net>: bz> I am not entirely sure I like "slaac" or "dhcp4". I wonder if progname bz> would be sufficient in call cases either (I could well see a "dhclient" bz> or another "fooapp" that can handle both v4 and v6) but in that case it bz> would probably be a matter of third order -- address family. bz> bz> Example: bz> bz> prefer v6 bz> intorder "tun* gre* gif* wlan* em*" or similar (maybe classes lik bz> "wired" or similar. not sure how easily we could do that). bz> progorder "dhcp* rt*" Our openresolv currently supports $interface_order with shell pattern matching only. What I thought was interface_order="lo lo[0-9]* *:ppp *:slaac *:dhcpv4 [a-z]*[0-9]*:*" or something like this. Actually the interface name in resolvconf(8)'s command line argument does not have to be the same as real interface names because it is used just for distinguishing the information source. My primary purpose is to prevent multiple RDNSS information on a single interface from overwriting /etc/resolv.conf anyway. It can be realized by just adding some additional label. Priority control based on ifname and/or protocol (or progname) needs no modification to the resolvconf(8) itself if we use this "interface name + label", and it looks flexible enough to me. What we need is a consistent expression for that and reasonable default value of $interface_order. Anyway, the main point here is whether adding an additional label to interface id is reasonable or not. AFAICC, there is no side effect by adding the ":origin" part. bz> Have you discussed that with $upstream vendor as well or do we consider bz> further changes to be simple enough to merge them in? No, I haven't discuss with the upstream yet because supporting ":origin[:unique]" part need no change on the resolvconf(8) side (I may be missing something here, though). An experimental patch for rtsold is [1] (note that this includes some noises) and one for dhclient is [2]. Basically these patches are just for adding ":origin" part. [1] http://people.allbsd.org/~hrs/FreeBSD/rtsold_aggr_20110616-3.diff [2] http://people.allbsd.org/~hrs/FreeBSD/dhclient_resolvconf_20110616-1.diff Note that it is possible to have multiple RDNSS sources on a single interface in the rtsold case (i.e. multiple routers sending RAs on a link). So "em0:slaac:[RA-source-address]" is used as the interface id for that. -- Hiroki ----Security_Multipart(Thu_Jun_16_14_28_34_2011_922)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk35lIIACgkQTyzT2CeTzy3tpACg2Xo7LntnObVCVMPjNxs2IVNl m8kAoMGVD2qzpMh5YAWHeqy1ek534XJC =xoyO -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Jun_16_14_28_34_2011_922)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110616.142834.63956571381923731.hrs>