From nobody Mon May 22 10:52:42 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 4QPvRq1Mmtz4TMbt for ; Mon, 22 May 2023 10:52:55 +0000 (UTC) (envelope-from melifaro@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 4QPvRq0vpdz4MqX for ; Mon, 22 May 2023 10:52:55 +0000 (UTC) (envelope-from melifaro@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684752775; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=u9+Uf9lSYv6rkVLFr3EcoqUjHsFw19NOVfPwx37qCzA=; b=Y8kk41IP82kIqV//B5pBQMjNAhKvONQxsLHeU8Nra/b1iA9HnegJUJPt9HWCtWCGZQ768H beLhmF2q14WVBDsQ6IdPBDQgyqVxiYggCe24gfA74bRcmikhZCP1FchYv1FRElfeg1XlHn +KRVVbcILJyTsTWWBxH2+6/Lp0rqqrt7eTvoUxQU69MqVgTgemackFJMM2klEemGHBgPVd 5ZorhjoDdkguUc5l0kyZnkApr7E77Ojz6v/F+kIfcGOR6Up4eOzbH2e5xumoN3buYGKigf 6otOLsFa13/9o95eh7HaFKRcmQj8/4PqQ8Wr2g8CXeYhzo2Cmh4QF88dV7dgkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684752775; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=u9+Uf9lSYv6rkVLFr3EcoqUjHsFw19NOVfPwx37qCzA=; b=Advo5bzV5YUr7nE943+qqVCJ3LwVoEUF8PDg3C/wcT0y5RCg/aVuR+ehBhV+wvHYKbz0/w Wq8Br3j4rK5UEezSxCaHBdvp3EMDaVuR3CgNyEdHQMEFXKK1mcwSysFxTj22MHtjuWHZ1q zTcRN4tKdroGrlFl1m67BNHoJumj4so7cDJj0UfBCuFtw0A9OJ1zOO2mqpAzj/SW1Rdru2 uZ6YTuwb6pbDOd39P4Uz70Nr7qbwho1mYlkCRC5cFXgvS5gf2Bi5BqZKy2OQgNLw1dn5A3 x3IQK9qOWIjZn9vxg6GYu4im5n5Qdt6GekfYwfl7rYylUMsxa34cRsBQmetJEQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684752775; a=rsa-sha256; cv=none; b=k+zyCEKKq2TktljBuoILgbpI2CBKio0pIMlNdNkeh6a55saQBHRcKYZIc15Oat1vxLALUd hPQnu5OHBxJhpzyC5QuVQviNQVrYZdG4EnPyJzzhWgkvdoLRzpL+8QxY7vyAgq1Txm99Bl 8GzGeQmBtifNKQtLIdsItFfVL75gksVxC6M040ZJu+0mWndcor3v2fBJ5J89jAab1rl4xQ 3DR+2B1FWmlIk24aGqdGOqk9vj+IItzUHBbK8hpUfquuMCMR2sRSr4kq4dsfb9vHlxHXZF 8F6vt/qSfBq3c+tIjXVHlnd0AY8MOKU5vYSpdU0UlK83oCVdgqYJMBsXC9iOXA== Received: from smtpclient.apple (unknown [IPv6:2a02:8084:d6bb:510:a966:d3d6:9789:8d0a]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: melifaro/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QPvRp5ZbGz11X8 for ; Mon, 22 May 2023 10:52:54 +0000 (UTC) (envelope-from melifaro@freebsd.org) From: Alexander Chernikov Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: ::1/128 and 127.0.0.1 address creation ownership Message-Id: <6D75034B-6F14-49BE-ACFA-522D39D49490@FreeBSD.org> Date: Mon, 22 May 2023 11:52:42 +0100 To: net@freebsd.org X-Mailer: Apple Mail (2.3731.400.51.1.1) X-ThisMailContainsUnwantedMimeParts: N Hi, The current model of assigning default lo0 addresses is, well, = interesting. The ownership for creating 127.0.0.1 belongs to the rc.d = (network.subr:ifn_start() -> ipv4_up()). It is executed at the system start or jail start (explicitly by running = /etc/rc). The ownership for creating ::1 belongs to the kernel. When the userland (most likely, network.subr when adding 127.0.0.1) = calls SIOCAIFADDR (note it=E2=80=99s setting _alias_, not SIOCSIFADDR), It gets passed via kern_ioctl() to soo_ioctl() and then to = if.c:ifioctl(). Ifioctl() then calls in_aifaddr_ioctl(). in_aifaddr_ioctl() handler calls if_ioctl() for SIOCSIFADDR (set, but = not alias) before assigning the address. Loopback handler (loioctl()) sets IFF_UP flag and schedules taskq link = state change. Then, in_aifaddr_ioctl() adds the ifa & interface routes and completes, = returning to ifioctl(). Ifioctl() inspects the changed interface flags and, if IFF_UP is added = it explicitly calls in6_if_up() for the interface. in6_if_up() kicks up DAD and calls in6_ifattach(). Finally, = in6_ifattach() calls in6_ifattach_loopback() which adds ::1 and fe80::1. As a result, when adding 127.0.0.1 to lo0 from userland, ::1 gets = automatically added by the kernel. (I=E2=80=99m not sure what part of the process above I dislike the most = - there are too many of them). 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 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 = ioctls(). That model dates back to BSD 4.4 and doesn=E2=80=99t look well = in presence 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) /Alexander