From nobody Mon May 22 13:43:59 2023 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QPzFS3DBYz4BSb6 for ; Mon, 22 May 2023 13:44:12 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QPzFS2dndz4bBx; Mon, 22 May 2023 13:44:12 +0000 (UTC) (envelope-from olivier@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684763052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Z52UQuH4eHHM1CGdvq/pppXmABFaWby75rNivrFQJbI=; b=F/qK26HpUdQNkdGPlkrB5913d+p5uf9eaQY/0pfGFaUDKnFq+absExhFFeg0gOHFO9LnC8 0+7JoW3UjzjHYfznC9Rd4boHO9tRqSKlA04Dn93Mh7xoLLWCW6qqxHeB28f7wZdLubbr4g XHjuRJg6H87iL8SqoCMvaO1J8aItVjvKUqXed6p+uThgHwd/AnUUzJNwP9zdhzl88EsmUY fZ4E3TT/IRBEv5YbY6u4Ugc4k0h8JzbYpEVpmLiO4wcOIj/e365sTH9h2WovRK5XwZju1N UI/BqCt9VXFoOJjkC/rgfDb0IOOE1tpuMgiWzyoKXo0r9PwXbvb5JMeheXxnPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684763052; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Z52UQuH4eHHM1CGdvq/pppXmABFaWby75rNivrFQJbI=; b=YZ1GZXX/kuHzrQF5Grvv6bgyG6bDnVUEUOhaLyGJ1zzleWInRNy56sOrFDtG3TZY2ur8Bj Ttj8U9E9FGDiJzTXS0lkLquVh6ijzgJxo/oVt6ZWR9aOaPCiLp16C37+5HHv4Q/PDdJVXf jp2vTZShoAi7VMQQwmX/0niqxqww3rlENRvtCGuvRRIz9g6C7CCQVc+C3kXCys2J8Co7sB Faf/jJmtpipJVxUYCSPG5sEQ8CBvMrmnUbUXzYHuAihQMC6A5FHMpAnDoXzHGczcNCcSpP g5EkzwqEdFwsivmdu2a9u9iByT8odpZp41g2Xjk2l+3oJ8xzk8YkCftVdp5Zfg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684763052; a=rsa-sha256; cv=none; b=UdOQ/zXxnAcnk5Nay37V/n4Lhn5/X+aLnJpH3xFfrI0ft8TKwJRJUrCWNgW/rcLszbezgr RzNyNe+LzoUhhARFDBDhpq8yp4Ly+sQ6mZrqpH6s1DQLPrEcDku9x1+PVmQeo7nIIHq8yd YRoOE1kN9IID+B2j+rBAbYdjSsT41ORH/0FVQyMREwhMb0RzoeVW4hsSPSpQ6aB0+cc+fG /DO8E11YebvUnHAcLR4yFFL/k3rQbYhCD9G6YvXOUfgZBV4Kt0oCMPDFRHk5eU3PZXDc6O bRhHdp6211cph4TSeBsrocPyL31eZmjfZj+yNqanaea+hCV7a4d77yKMEKRYvA== Received: from mail-qv1-f43.google.com (mail-qv1-f43.google.com [209.85.219.43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QPzFS1ZQJz14rq; Mon, 22 May 2023 13:44:12 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-qv1-f43.google.com with SMTP id 6a1803df08f44-6239b45765eso34212456d6.2; Mon, 22 May 2023 06:44:12 -0700 (PDT) X-Gm-Message-State: AC+VfDwS/QVGXq5efsbGnBJvBeobxuvbGPmFhD0pFp9JG6jaxcB92zZO ci6RlxO8XlwMdUoQCobEoR3HzwJYItt/Mga/xQw= X-Google-Smtp-Source: ACHHUZ7VEFyk/NtvNp/3SVVr8MAlEHxT/2ZfPO/3u3nKB/48w3FFJrDoEjkjTjFjd36bOWtbzhkSXMiscpEVW8RTzEE= X-Received: by 2002:a05:6214:627:b0:5ef:4254:d6f0 with SMTP id a7-20020a056214062700b005ef4254d6f0mr15714539qvx.36.1684763051632; Mon, 22 May 2023 06:44:11 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 References: <6D75034B-6F14-49BE-ACFA-522D39D49490@FreeBSD.org> In-Reply-To: <6D75034B-6F14-49BE-ACFA-522D39D49490@FreeBSD.org> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Mon, 22 May 2023 15:43:59 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: ::1/128 and 127.0.0.1 address creation ownership To: Alexander Chernikov Cc: net@freebsd.org Content-Type: multipart/alternative; boundary="000000000000392dfb05fc4877f6" X-ThisMailContainsUnwantedMimeParts: N --000000000000392dfb05fc4877f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 22, 2023 at 12:53=E2=80=AFPM Alexander Chernikov wrote: > > My main question here is the desired ownership model. I don=E2=80=99t hav= e a > strong opinion on whether the userland of the kernel should own loopback > creation. > However, I think that: > 1) the behaviour should be consistent (either both of them created by the > userland or both created by the kernel) > 2) the process should be independent (e.g. adding address from one family > shouldn=E2=80=99t result in adding address from the other family). > For example, it can be either userland explicitly creates both or the > kernel creates both on interface up, using protocol hooks). > 3) I=E2=80=99m not sure SIOCSIFADDR should be (ab)used by the drivers ioc= tls(). > That model dates back to BSD 4.4 and doesn=E2=80=99t look well in presenc= e of event > handlers. > Most drivers (default ethernet handler, loop, gre,disc,me,ipsec) just set > IFF_UP there. > > More than happy to hear what other=E2=80=99s think on the issue(s) > > It seems that loopback addresses are optional: I haven't found an RFC requiring their presence, but I'd like to have more information on this. So, the ownership of their creation seems to me good from the userland (i.e.: rc.d): Administrators are free to configure them or not. I agree with point 1 (consistency) and point 2 (independency), and about point 3 I have no technical knowledge here, but the work of cleaning up and making the proposal coherent seems good too :-) Regards, Olivier --000000000000392dfb05fc4877f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, May 22, 2023 at 12:53=E2=80=AFPM Alexander = Chernikov <melifaro@freebsd.org<= /a>> wrote:

My main question here is the desired ownership model. I don=E2=80=99t have = a strong opinion on whether the userland of the kernel should own loopback = creation.
However, I think that:
1) the behaviour should be consistent (either both of them created by the u= serland or both created by the kernel)
2) the process should be independent (e.g. adding address from one family s= houldn=E2=80=99t result in adding address from the other family).
For example, it can be either userland explicitly creates both or the kerne= l creates both on interface up, using protocol hooks).
3) I=E2=80=99m not sure SIOCSIFADDR should be (ab)used by the drivers ioctl= s(). That model dates back to BSD 4.4 and doesn=E2=80=99t look well in pres= ence of event handlers.
Most drivers (default ethernet handler, loop, gre,disc,me,ipsec) just set I= FF_UP there.

More than happy to hear what other=E2=80=99s think on the issue(s)

<= /blockquote>


It seems that loop= back addresses are optional: I haven't found an RFC requiring their pre= sence, but I'd like to have more information on this.
So, the owners= hip of their creation seems to me good from the userland (i.e.: rc.d): Admi= nistrators are free to configure them or not.
I agree wi= th point 1 (consistency) and point 2 (independency), and about point 3 I ha= ve no technical knowledge here, but the work of cleaning up and making the = proposal coherent seems good too :-)

Reg= ards,
Olivier
--000000000000392dfb05fc4877f6--