freebsd-src
freebsd-src copied to clipboard
freebsd
ifconfig(8): change default IP address format to 'cidr'
'netmasks' haven't been used in IP networking for decades. Change the default address format for both IPv4 and IPv6 addreses in ifconfig(8) to 'cidr', which prints addreses in the format most users will be more familiar with.
The previous format is still available using -finet:hex or -finet6:numeric.
arch@ thread https://lists.freebsd.org/archives/freebsd-arch/2024-May/000653.html
You are right, netmasks have not been used on the Internet for quite some time, but you are ignoring the vast number of companies that still use /8, /16. and /32 on their RFC 1918 address-space networks. This change could be a significant issue for many of them, and breaks your premise of "most people will be familiar". I recommend against the change, especially as cidr is already supported in ifconfig with the -f flag
could you explain how this would be an issue for people who use /8, /16 or /32 addresses? i use 10/8 in our local network which i subnet into /24s, and i've had this IFCONFIG_FORMAT set in login.conf since forever with no issues.
note that that this doesn't prevent someone using 'ifconfig em0 10.1.1.1 netmask 255.255.255.0' if they want to do that, and it won't break anyone's /etc/rc.conf. it only affects the printed output format.
Hi Lexi,
Any script that expects the current format will be broken, and you are ignoring all the runbooks and incident handling guides that would have to be updated as a consequence of the change. That could be quite significant.
Best regards,
John
From: Lexi @.> Date: Saturday, May 4, 2024 at 11:11 AM To: freebsd/freebsd-src @.> Cc: John Howie @.>, Comment @.> Subject: Re: [freebsd/freebsd-src] ifconfig(8): change default IP address format to 'cidr' (PR #1216)
could you explain how this would be an issue for people who use /8, /16 or /32 addresses? i use 10/8 in our local network which i subnet into /24s, and i've had this IFCONFIG_FORMAT set in login.conf since forever with no issues.
note that that this doesn't prevent someone using 'ifconfig em0 10.1.1.1 netmask 255.255.255.0' if they want to do that, and it won't break anyone's /etc/rc.conf. it only affects the printed output format.
— Reply to this email directly, view it on GitHubhttps://github.com/freebsd/freebsd-src/pull/1216#issuecomment-2094281419, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADX2TMYQSA7N5MLQKKKKPCDZAUCEVAVCNFSM6AAAAABHG44JU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJUGI4DCNBRHE. You are receiving this because you commented.Message ID: @.***>
we can note this change in RELNOTES for 15.0-RELEASE for people to update their scripts. i don't expect this change will be MFC'd (nor should it).
the number of people who rely on parsing 'netmask' in ifconfig(8) in a shell script is much, much smaller than the number of people who expect to see IP addresses printed in a modern format -- it's not 1996 anymore.
This is a bad idea as it will break thousands of scripts and you can achieve the same result by adding a single line to your shell startup script:
export IFCONFIG_FORMAT=inet:cidr,inet6:cidr
I am in favor of this change; it should have been made long ago. I have had IFCONFIG_FORMAT=inet:cidr in my environment for a long time. I find it hard to believe that so many scripts will be broken, but they can trivially be fixed by setting IFCONFIG_FORMAT. On the other hand, new users will not know about the option to use cidr, and the change to the default will benefit most of the people, who do not set the format and deal with the default. If there is significant fallout, there is plenty of time before 15.0-RELEASE to consider reverting.
If you really think this change should be made, then IFCONFIG_FORMAT should be set globally to default to current output format. Anyone who wants cidr format output can remove it. That way you do not break everyone’s scripts and experience. Is that acceptable?Sent from my iPhoneOn May 4, 2024, at 12:15, MikeKarels @.***> wrote: I am in favor of this change; it should have been made long ago. I have had IFCONFIG_FORMAT=inet:cidr in my environment for a long time. I find it hard to believe that so many scripts will be broken, but they can trivially be fixed by setting IFCONFIG_FORMAT. On the other hand, new users will not know about the option to use cidr, and the change to the default will benefit most of the people, who do not set the format and deal with the default. If there is significant fallout, there is plenty of time before 15.0-RELEASE to consider reverting.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
The value IS a netmask, it is stored as a netmask, it should be displayed by default how it is stored and implemented. CIDR is a notation, a notation that does not cover all possible values, it should ONLY be used if asked for. As Jessica pointed out on the mailing list the current code incorrectly calculates a non contiguous netmask. I have not seen any other ifconfig that does this, yes linux "ip address" command outputs it in cidr, but not there ifconfig, nor does windows 10. Please do not do this.
As Jessica pointed out on the mailing list the current code incorrectly calculates a non contiguous netmask.
can you show an example of a non-contiguous netmask configured on a FreeBSD system and the commands you used to configure it? i was not able to achieve this when i tested it (see my reply to Jessica's mail).
also, let me add that if FreeBSD does still support non-contiguous netmasks in some way, the correct fix for that is to remove support for non-contiguous netmasks, which have been obsolete for over 30 years.
I agree that this is a good change, but there are an awful lot of scripts out there that will need to be fixed -- many of which haven't been touched in decades. "ifconfig | awk" is a very common pattern.
If we're going to make this change, we should set IFCONFIG_FORMAT=inet:cidr,inet6:cidr in the default environment for 15.0 and change ifconfig in 16.0.
I don't think discontiguous netmasks are something to worry about in 2024. I've only ever encountered them in load balancers, where you could direct traffic to each interface based on them. And I can't even remember the last time I encountered one of these.
I'll remind everybody that ifconfig has had IFCONFIG_FORMAT since
commit 7c2aa744374aa3449ad81f60852e74ad73d823e6
Author: Allan Jude <[email protected]>
Date: Tue May 31 17:30:08 2016 +0000
ifconfig(8) now supports some output formatting options
so we've already 7 years into this process. This is nothing new and the desire to migrate has been around a long time. As such, we can transition in 15, and put a release note into 14.1 release that's coming up and still give people years worth of notice. We don't need to give 4 or 5 years notice to do this in 16. That's too long and people will take their eye off the ball and it will be 17 or 18 before it happens. I've had several things I "gratuitously" had a long horizon on, only to forget about until it was too late (14.0 was supposed to have an awk that didn't decode hex number, for example).
Also, broken scripts are a 1 line fix away from working, so the impact is rather small, and that one line can be set globally for people that have a lot of these scripts. The fix can be placed into the release notes as well. In addition, there's plenty of time for us to get a feel on how many scripts there actually are here. We can back off to a longer time horizon if it proves to be too disruptive. It would be even better if ifconfig, or a similar tool, could produce easy to use in scripts data (like json via libxo). I'm surprised there's no libxo option to it today. Of course these would be a more intrusive change, but would insulate us from data change like we've done in nearly every other system.
So I agree with Mike Karels on this.
As Jessica pointed out on the mailing list the current code incorrectly calculates a non contiguous netmask.
can you show an example of a non-contiguous netmask configured on a FreeBSD system and the commands you used to configure it? i was not able to achieve this when i tested it (see my reply to Jessica's mail).
Something (my best guess would be the netlink rewrites) has broken this: rgrimes_bgp.dnsmgr.net:root {1001}# uname -a FreeBSD rgrimes_bgp.dnsmgr.net 13.2-RELEASE FreeBSD 13.2-RELEASE releng/13.2-n25 4617-525ecfdad597 GENERIC amd64 rgrimes_bgp.dnsmgr.net:root {1002}# ifconfig bridge2 create rgrimes_bgp.dnsmgr.net:root {1003}# ifconfig bridge2 192.0.2.1 netmask 255.0.255 .0 rgrimes_bgp.dnsmgr.net:root {1004}# ifconfig bridge2 bridge2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 58:9c:fc:10:ed:64 inet 192.0.2.1 netmask 0xff00ff00 broadcast 192.255.2.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 groups: bridge nd6 options=9<PERFORMNUD,IFDISABLED>
afbr1.dnsmgr.net:root {167}# uname -a FreeBSD afbr1.dnsmgr.net 14.0-RELEASE FreeBSD 14.0-RELEASE #0 releng/14.0-n26538 0-f9716eee8ab4: Fri Nov 10 05:57:23 UTC 2023 [email protected]:/u sr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 afbr1.dnsmgr.net:root {168}# ifconfig bridge2 create afbr1.dnsmgr.net:root {169}# ifconfig bridge2 192.0.2.1 netmask 255.0.255.0 afbr1.dnsmgr.net:root {170}# ifconfig bridge2 bridge2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 options=0 ether be:24:56:0f:fd:78 inet 192.0.2.1 netmask 0xffff0000 broadcast 192.0.255.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 groups: bridge nd6 options=9<PERFORMNUD,IFDISABLED>
Something (my best guess would be the netlink rewrites) has broken this
has it "broken" this or has it fixed this by not allowing non-contiguous netmasks? like i said - these have been obsolete for over 30 years. it's time to move on. CIDR is your friend.
Something (my best guess would be the netlink rewrites) has broken this
has it "broken" this or has it fixed this by not allowing non-contiguous netmasks? like i said - these have been obsolete for over 30 years. it's time to move on. CIDR is your friend.
Silently doing something different than what the user asked to be done is "broken!"
Silently doing something different than what the user asked to be done is "broken!"
that's a fair point but not directly related to this PR - i'd be happy to submit another one to produce a warning/error when trying to add non-contiguous netmasks. i'm not sure if that's better done in ifconfig(8) or in the kernel, though -- probably the latter.
Another data point, people are asserting that CIDR obsoleted non contiguous netmask, yet the IETF documents do NOT refect this fact. RFC950 was NOT updated by the CIDR RFC's, It has only ever been updated by RFC6918 which was to obsolete some ICMP, and with respect to netmask it simply obsoletes the ICMP request/reply mask icmp types. So as it stands today, the IETF standards (RFC950 is part of STD5) out weight anything in an RFC or BCP.
what IGPs can carry non-contiguous netmasks?
what OSs can configure non-contiguous netmasks on an interface address? (FreeBSD cannot, as we already established.)
what practical purpose is there to configure a non-contiguous netmask on an interface address?
is anyone here actually using a non-contiguous netmask on an interface address in a production system?
what IGPs can carry non-contiguous netmasks? As far as I am aware ALL ipv4 IGP's carry routes as Address:Netmask pairs, they do NOT carry this data as a prefix length. I also know that OSPFv3 for IPv6 did infact do away with the netmask and now carries a prefix length in LSA's. BGP4 also uses prefix length.
what OSs can configure non-contiguous netmasks on an interface address? (FreeBSD cannot, as we already established.)
That would need time to investigate, and FreeBSD was NOT an intentional removal, someone borked some code doing some other change so I do not think we should be asserting that as a basis for this change.
what practical purpose is there to configure a non-contiguous netmask on an interface address?
is anyone here actually using a non-contiguous netmask on an interface address in a production system? Good questions, which put those details in what I would call the known unknowns.
I understand the temptation to have "nicer" output by default, but please resist. This will break untold numbers of scripts that parse the ifconfig output. This output line has been this way it for decades. If you want to improve the default output for human users please set the IFCONFIG_FORMAT environment variable and export it in the default shell profile files instead.
I find it hard to believe that so many scripts will be broken, but they can trivially be fixed by setting IFCONFIG_FORMAT.
This came up on a recent Production User Call and yes, it would break many systems. Users have been required to parse the output for a long time, for better or for worse, and institutionalized that parsing.
If not mistaken, this is output is identical on macOS and the Linux kernel, systemd aside.
This syntax is highly-documented, existing in books, manuals, search results, "stack overflow results", blogs, and other formal and semi-formal locations.
One suggestion to find potential breakage in ports is to run:
grep -r -l ’^. /etc/rc.subr’ /usr/ports/*
This change sounds like NextBSD territory.
As for "it's trivial to fix", it is trivial to override the defaults on your systems. Having individual users push their personal configurations upstream is a very long, slippery slope and the adding of directory colors comes to mind. Plus syslog compression, the new default root shell... Please configure your system exactly as you like. Consider zsh on it, or BASH.
These changes feel like progress, but asking administrators to continually revise their working production workflows is not advancement. Different is not always better. New features are great but please only enable them by default when you have broad consensus.
Rephrased: Exactly what well-defined problem does this solve, given the unseen administrator cost involved in adjusting to the change?
I just checked my own parser code, and it already transparently handled both, but I added test-case for future proofing: https://github.com/canonical/cloud-init/pull/5272
The problem is that there're so many ad-hoc parsers for ifconfig's output in the wild because it's the least bad way to get this information unless you're prepared to deal with operating system specific ioctl()s, netlink sockets etc. Is "it looks prettier" a good enough reason to change the default notation to represent the same information? Heck I run the environment variable myself on my personal systems yet I would be pissed to learn about this change because some remote system is unreachable after an upgrade because a script blew up.
Has anyone checked how this interacts with /etc/network.subr?
Has anyone checked how this interacts with
/etc/network.subr?
Looks like it will work, since it uses regexp to pick out the IP address. Anything trailing the X.Y.Z.W is ignored.
The point about the multiple ad-hoc parsers, though, is interesting. There's three different parsers in network.subr...
It appears that the consensus is that this change should not be made, and I think I have been convinced. Setting IFCONFIG_FORMAT to inet:cidr in root's .profile and .login seems to be a reasonable compromise, is easy to undo, and is unlikely to affect scripts run by cron, etc.
I would suggest placing it in the default section of login.conf instead. Remember that .profile also affects shell scripts.
I don't think .profile is sourced by shell scripts unless they do it manually; sh(1) says it is used on login. However, I think login.conf is better, as it applies to all users.