From owner-freebsd-rc@FreeBSD.ORG Tue Feb 7 14:47:11 2012 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BC2E106567B for ; Tue, 7 Feb 2012 14:47:11 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id F27948FC18 for ; Tue, 7 Feb 2012 14:47:10 +0000 (UTC) Received: (qmail 84608 invoked from network); 7 Feb 2012 14:51:10 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with CAMELLIA256-SHA encrypted SMTP; 7 Feb 2012 14:51:10 -0000 Message-ID: <4F31396C.2060507@erdgeist.org> Date: Tue, 07 Feb 2012 15:47:08 +0100 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Hiroki Sato References: <4F304F54.4020802@FreeBSD.org> <20120207.072925.1861639312875773760.hrs@allbsd.org> <4F3088C8.9090505@erdgeist.org> <20120207.170255.161251905285915806.hrs@allbsd.org> In-Reply-To: <20120207.170255.161251905285915806.hrs@allbsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@FreeBSD.org Subject: Re: Proposal ipv6_addrs_common X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 14:47:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07.02.12 09:02, Hiroki Sato wrote: > Ah, I see. This looks good. I will give it a try and investigate > corner cases. I did not want to put the burden of implementation on you. I'm doing shell scripting for a living and can surely help with that. I just need some directions, pitfalls that have been found earlier and that I should avoid. > This is because it is unclear that which address family will be > used to recognize an address without AF keyword. In most cases > network-related utilities/scripts assume IPv4 by default and > require a modifier or option for the others. It works, but > sometimes it requires a complex and inconsistent address handling > in utilities/scripts. Appending AF keyword burdens users a bit > but simplifies multiple address family support in more consistent > manner. So to put that in the grand perspective, the ifconfig_IF_aliases knob is solely to configure additional aliases to the interface as opposed to the ifconfig_IF knob which can contain other more complex parameters to pass to ifconfig? Do we need to handle more cases than plain ipv4, hex ipv4, plain ipv6 addresses, ipv6 mapped v4 and hostnames? - From the ifconfig's man page I take at least "ether", "ipx" and "atalk". It does not make sense to support re-setting link level addresses in the ifconfig_IF_aliases knob. For the atalk address family ifconfig recognises "range" modifiers that work like netmasks, but it looks not very common to configure additional atalk address to a single interface. Maybe someone with IPX knowledge can comment if we need to take special care. To sum it up: the handler for the ifconfig_IF_aliases knob should just pass each space separated value to ifconfig $IF $v (-)alias , unless a) it is prefixed with any of the address family names know to ifconfig, in that case the family should be remembered and next value be parsed and passed to ifconfig $IF $family $v (-)alias b) it matches RANGE.RANGE.RANGE.RANGE(/\d{1-2})? for RANGE in \d{1-3}(-\d{1-3})? with at least one dash. In that case it is expanded and each expansion passed to ifconfig $IF $family $expansion/$mask (-)alias with mask set to 32 after the first address in each subnet. For an address family already specified we could check for conflicts here or leave that to ifconfig. c) it matches *-*:*:*(/\d{3})?, *:*-*:*(/\d{3})?, *:*:*-*(/\d{3})? (So we're sure not to interfere with link level addresses.) In that case it is expanded and each expansion passed to ifconfig $IF inet6 $expansion/$mask (-)alias here we should check for collision of the address family. Also I am not sure if you have to alter the netmask. d) it matches ::ffff:RANGE.RANGE.RANGE.RANGE(/\d{1-2})? with at least one dash. In that case it is expanded and each expansion passed to ifconfig $IF inet6 $expansion/$mask (-)alias with mask reset 128 after the first address in each subnet. Done ;) erdgeist -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAk8xOWwACgkQuN1wFypsMNN9XgCeIKx2nk9sQvcTuQEMRYxhk82G Wi4An3XPssuX/+eQpaz1uOkOlsBME3vv =sI94 -----END PGP SIGNATURE-----