From nobody Wed Oct 20 04:02:04 2021 X-Original-To: freebsd-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 F0807180FCD6 for ; Wed, 20 Oct 2021 04:02:22 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HYxlL3frRz3NjD; Wed, 20 Oct 2021 04:02:22 +0000 (UTC) (envelope-from freebsd@grem.de) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id a3df2892; Wed, 20 Oct 2021 04:02:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=20180501; bh=ubkg1y3x1+M9F/ uYPIoMFPXwGWY=; b=oP4QBCex/8/GBzaSwkRo5vJoVODpT5FwTOh/9xjNQOshNK jLYrYpznXCD8OpkGV38xPH54H+B65x+x3Iw8Emn7veqJcxerJ0HR3NmKBRQMyWJg qZvBqO+5JoqDCC2B8Xws0KTYLby4cL9oAmWR+EEDl6eu3E6EuGf0mHP+bxRhjsZ3 5qRPzXAzKle2vf6t2D5CIcz8RCB5ln+UtemhXK501vf28MFyLsu3gXBt0bMPhOId xly/ZUhQXDpid993/35lq+Rj1loF4ANxML4foeqKhjvleANr8IBIkIEgidGOo7Wc VmX6VXe+tSRdnCcc592jcCIVa+FlkKBF82I6IvkA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; q=dns; s=20180501; b=ue5n7WK8 IypYY7+OJtqATu37M1wt3UsfcOxFsBicVO4jv+Hy1ZDgVfcX4y3tiadnFJdP2S5h diRMDuZgD03uL22acnDxXa5F7tk8qecjSQfTkNOjaazOGYgvgdDdOK+cUAMQOYLr UrpD0XiIP4yGUKC6LIlfwV47Utyne4XeM/rGKS+R0ZMhK/eFcZCdEzNTyhiUENf7 R3OjWO6MycaJvWM6vFsc23UC6H1ktSebBx2+x+MZ48yOWnTuh0vP0l+vHt3CYt6z ClZw8kvboyw8zQapDRCP32e6JmIQeh7qmAldeqa4Z8MChjWePiQIPW0m/g6kUI/2 dQOa6qHZGgoCag== Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 8a3e6c42 (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Wed, 20 Oct 2021 04:02:06 +0000 (UTC) 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 (1.0) Subject: Re: cleaning up INET: deprecating network class A/B/C From: Michael Gmelin In-Reply-To: <202110192115.19JLFsaR006625@mail.karels.net> Date: Wed, 20 Oct 2021 06:02:04 +0200 Cc: "Rodney W. Grimes" , freebsd-net@freebsd.org Message-Id: <5FF02060-1DA9-4B93-907F-3F608D4B04B7@grem.de> References: <202110192115.19JLFsaR006625@mail.karels.net> To: karels@freebsd.org X-Mailer: iPhone Mail (18F72) X-Rspamd-Queue-Id: 4HYxlL3frRz3NjD X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N > On 19. Oct 2021, at 23:16, Mike Karels wrote: >=20 > =EF=BB=BFRod wrote: >=20 >>> I plan to do some cleanup of the residual code defining and using the >>> old Internet network classes (A/B/C), which have been obsolete since >>> CIDR took hold. This is an outline of what I plan, as it will happen >>> in a number of steps and reviews, and I would like feedback on some >>> of it. >>>=20 >>> I want to reduce the use of the obsolete definitions and interfaces, >>> and make it less likely for them to be used going forward. I plan >>> to hide the Class A/B/C bit definitions unless a feature test macro >>> is defined; that will be the default for user code for the moment. >>> A few files in the kernel will need to define the feature test macro >>> for now (but see the next two paragraphs). >=20 >> Sounds good. >=20 >>>=20 >>> Several of the uses of the historical network class macros have to >>> do with generating a default network mask when none is provided. >>> The worst of these is in the code for SIOCAIFADDR (add interface >>> address). I want to have ifconfig and/or the kernel warn about this; >>> the default is most likely wrong. After some time with a warning, >>> it should become an error to set an Internet interface address >>> without a mask (except for loopback and point-to-point interfaces, >>> where the mask is meaningless). >=20 >> Sounds good except that last bit, mask on loopback is >> meaningful, especially for people like me that alrady >> have modified systems that change loopback from 127/8 >> to 127/16. >=20 > I'm not aware of anything that uses the mask on a loopback interface; > are you? There is no network route installed when the loopback address > is set. I think it's similar for point-to-point interfaces, where only > the host route for the destination is added. >=20 I=E2=80=99ve got a use case that depends on being able to set and read the n= etmask on loopback interfaces consistently to allow orchestration and nomad f= ingerprinters to pick it up. But that=E2=80=99s really only about those oper= ations. Best Michael