From owner-freebsd-net@FreeBSD.ORG Thu Jun 16 05:28:58 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A012E106564A for ; Thu, 16 Jun 2011 05:28:58 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 27B1E8FC08 for ; Thu, 16 Jun 2011 05:28:57 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p5G5ShKi092003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 14:28:53 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p5G5SekV004463; Thu, 16 Jun 2011 14:28:42 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 16 Jun 2011 14:28:34 +0900 (JST) Message-Id: <20110616.142834.63956571381923731.hrs@allbsd.org> To: bzeeb-lists@lists.zabbadoz.net From: Hiroki Sato 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> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Jun_16_14_28_34_2011_922)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Thu, 16 Jun 2011 14:28:55 +0900 (JST) X-Spam-Status: No, score=6.4 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: net@FreeBSD.org Subject: Re: [RFC] resolvconf(8) interface id X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 05:28:58 -0000 ----Security_Multipart(Thu_Jun_16_14_28_34_2011_922)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Bjoern A. Zeeb" 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)----