Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-14 Thread Rodney W. Grimes
> On Fri, Jun 14, 2024 at 06:42:09AM GMT, Rodney W. Grimes wrote:
> > > "Poul-Henning Kamp"  writes:
> > > 
> > > > Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense 
> > > > ever.
> > > 
> > > Well, not in the last 30 years or so, anyway.
> > 
> > No, never ever did /8 make since on 192.*.*.*, that has always been
> > class C address space.
> 
> I think what Poul-Henning meant is that 31 years ago, in 1993, classless
> inter-domain routing (CIDR) was introduced by the IETF, and it rendered
> "class"es of ip addresses obsoletes.
> 
> So, class C address spaces has been dead for 31 years :-)

NO!  That is an incorrect interpretation of what CIDR does, CIDR did
NOT remove the Class A/B/C applied to address space, it simply added
functionality (supernetting and subnetting) of the A/B/C space that
allows you to do things DIFFERENT than the default /8 /16 and /24
bit prefix length that classfull addresses implied.

> -- 
> Mathieu Arnold
-- 
Rod Grimes rgri...@freebsd.org



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-14 Thread Mathieu Arnold
On Fri, Jun 14, 2024 at 06:42:09AM GMT, Rodney W. Grimes wrote:
> > "Poul-Henning Kamp"  writes:
> > 
> > > Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever.
> > 
> > Well, not in the last 30 years or so, anyway.
> 
> No, never ever did /8 make since on 192.*.*.*, that has always been
> class C address space.

I think what Poul-Henning meant is that 31 years ago, in 1993, classless
inter-domain routing (CIDR) was introduced by the IETF, and it rendered
"class"es of ip addresses obsoletes.

So, class C address spaces has been dead for 31 years :-)

-- 
Mathieu Arnold


signature.asc
Description: PGP signature


Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-14 Thread Rodney W. Grimes
> "Poul-Henning Kamp"  writes:
> 
> > Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever.
> 
> Well, not in the last 30 years or so, anyway.

No, never ever did /8 make since on 192.*.*.*, that has always been
class C address space.

-- 
Rod Grimes rgri...@freebsd.org



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-13 Thread Lowell Gilbert
"Poul-Henning Kamp"  writes:

> Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever.

Well, not in the last 30 years or so, anyway.



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-13 Thread Ed Maste
On Wed, 12 Jun 2024 at 14:08, Ed Maste  wrote:
>
> As for the path forward, what do folks think about changing the
> warning into an error in main in the near future (prior to 15.0)? That
> would provide about four years of releases that emit the warning,
> hopefully enough time for users to notice and update their
> configuration.

I opened a review in https://reviews.freebsd.org/D45585 to turn it
into an error. I've intentionally made it a minimal change to avoid
conflicts on future MFCs; it could be cleaned up and simplified once
older branches pass EOL.



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Chris

On 2024-06-12 00:47, Poul-Henning Kamp wrote:

I had a machine with this line in /etc/rc.conf:

ifconfig_bla0="192.168.87.11"

I found out the hard way, that this defaults to /8 now.

The main symptom was that DNS was /really/ busted, which makes sense
when none of the DNS servers in the 192/8 "swamp" can be reached.

Since we all know that it is always DNS(SEC), I spent a lot of time
having fun with that, before I noticed the /8 netmask on the interface.

I agree that the class A/B/C netmask assumptions should have died long ago.

But from a foot-shooting point of view, it makes no sense to default
192.168/16 to a /8 netmask.

If we're going to default to /8, at the very least ifconfig should
spitting out a very noisy warning and wait 5 seconds before proceeding,
when the netmask is not explicitly specified.

But I also think we can do better than /8.

One option is to go for "limit the damage in RFC1918" and default
them according to their size: reach:

10/8
172.16/12
192.168/16

That will prevent the DNS weirdness I had to figure out, and probably
still DWIM in most cases.

Another option is to default all three to /24, which in my experience
is how people deploy RFC1918.

A third option is to default any missing netmask to /24 instead of /8,
which would be what I would personally have done in the first place.

I couldn't agree more. CPEs, WiFi AP's and most other network(ing) equipment
that most users encounter, generally default to a /24 (255.255.255.0).
IMHO this would result in the least amount of POLA. :)



Poul-Henning

--Chris



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Ed Maste
On Wed, 12 Jun 2024 at 12:16, Michael Gmelin  wrote:
>
> So this is simply a bug.
>
> I opened a code review request to fix this:
> https://reviews.freebsd.org/D45570

Thank you. An EN for 14.0 and 14.1 (as suggested in your review) is
certainly warranted.

As for the path forward, what do folks think about changing the
warning into an error in main in the near future (prior to 15.0)? That
would provide about four years of releases that emit the warning,
hopefully enough time for users to notice and update their
configuration.



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Michael Gmelin



On Wed, 12 Jun 2024 15:35:58 +
"Poul-Henning Kamp"  wrote:

> 
> Michael Gmelin writes:
> 
> > @phk From which version did you upgrade?  
> 
> To be totally honest: I'm not entirely sure.  Probably 13.x
> 

@Bjoern I checked again, I'm pretty sure the problem was introduced in
https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a (this was part of
adding netlink into the code). The preparation work by the late Mike
Karels was consistent, as one can see in 13.x.

So basically the behavior on 13.x is:
- ifconfig bla0 10.1.1.1 => 10.1.1.1/8
- ifconfig bla0 192.168.1.1 => 192.168.1.1/24

This is in line with one would expect. On 14.x it's the opposite.

The code in 4bf44dd73bc0a68b73f7ee50d52adf5d7cda3eb8 introduced a
function to emulate the previous behavior. This function uses
IN_CLASSX_NSHIFT as bitmask - therefore 10.1.1.1 uses /24 and
192.168.1.1 uses /8. To fix the code, one has to actually use the
bitmask, which is (32 - IN_CLASSX_NSHIFT).

So this is simply a bug.

I opened a code review request to fix this:
https://reviews.freebsd.org/D45570

Best
Michael

-- 
Michael Gmelin



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Poul-Henning Kamp

Michael Gmelin writes:

> @phk From which version did you upgrade?

To be totally honest: I'm not entirely sure.  Probably 13.x

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Michael Gmelin



On Wed, 12 Jun 2024 15:11:14 + (UTC)
"Bjoern A. Zeeb"  wrote:

> On Wed, 12 Jun 2024, Bjoern A. Zeeb wrote:
> 
> > On Wed, 12 Jun 2024, Michael Gmelin wrote:
> >  
> >> 
> >> 
> >> On Wed, 12 Jun 2024 14:36:35 +
> >> "Poul-Henning Kamp"  wrote:
> >>   
> >>> 
> >>> Bjoern A. Zeeb writes:
> >>>   
> > I had a machine with this line in /etc/rc.conf:
> >
> > ifconfig_bla0="192.168.87.11"
> > 
> > I found out the hard way, that this defaults to /8 now.  
>  
>  Did you track it down to a specific change?  I.e. is this
>  ifconfig/netlink or the old kernel change from like two years(?)
>  ago?
>  
>  Do you have a time window when this broke as that'll help people
>  to bisect?  
> >>> 
> >>> I have no idea, sorry, I just freebsd-updated this one box...
> >>>   
> >> 
> >> I just tried on 14.0-p6, same there:
> >>
> >>  # ifconfig vtnet0 192.168.87.11
> >>  ifconfig: WARNING: setting interface address without mask is
> >>  deprecated, default mask may not be correct.
> >> 
> >> Interestingly, `ifconfig vtnet0 10.0.0.1` uses "/24" whereas
> >> 192.168.87.11 uses "/8".
> >> 
> >> This dates back to:
> >> https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a  
> >
> > No it pre-dates that chnage.
> >
> > It goes back to d8237b95552807e937fc389c7e2237679ef0c984 and related
> > changes.  
> 
> Sorry I hit send too early
> 
> And I think it came out of
> 
> commit 2f35e7d9fa03f27543f347cd6277af5bfc6a7e95
> commit 20d59403961d531467cfab22163f49c131cc8b55
> 

Hm, the deprecation warning was introduced in 2021 and was already part
of 13.1 it seems:
https://cgit.freebsd.org/src/commit/?id=4dbba5ab609c9

Going through these various commits, default behavior changed. Just
tried on 13.2, where 10.x.x.x gave me /8 and 192.168.x.x gave me /24.

@phk From which version did you upgrade?

Best

-- 
Michael Gmelin



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Bjoern A. Zeeb

On Wed, 12 Jun 2024, Bjoern A. Zeeb wrote:


On Wed, 12 Jun 2024, Michael Gmelin wrote:




On Wed, 12 Jun 2024 14:36:35 +
"Poul-Henning Kamp"  wrote:



Bjoern A. Zeeb writes:


I had a machine with this line in /etc/rc.conf:

ifconfig_bla0="192.168.87.11"

I found out the hard way, that this defaults to /8 now.


Did you track it down to a specific change?  I.e. is this
ifconfig/netlink or the old kernel change from like two years(?)
ago?

Do you have a time window when this broke as that'll help people to
bisect?


I have no idea, sorry, I just freebsd-updated this one box...



I just tried on 14.0-p6, same there:

 # ifconfig vtnet0 192.168.87.11
 ifconfig: WARNING: setting interface address without mask is
 deprecated, default mask may not be correct.

Interestingly, `ifconfig vtnet0 10.0.0.1` uses "/24" whereas
192.168.87.11 uses "/8".

This dates back to:
https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a


No it pre-dates that chnage.

It goes back to d8237b95552807e937fc389c7e2237679ef0c984 and related
changes.


Sorry I hit send too early

And I think it came out of

commit 2f35e7d9fa03f27543f347cd6277af5bfc6a7e95
commit 20d59403961d531467cfab22163f49c131cc8b55

--
Bjoern A. Zeeb r15:7



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Bjoern A. Zeeb

On Wed, 12 Jun 2024, Michael Gmelin wrote:




On Wed, 12 Jun 2024 14:36:35 +
"Poul-Henning Kamp"  wrote:



Bjoern A. Zeeb writes:


I had a machine with this line in /etc/rc.conf:

ifconfig_bla0="192.168.87.11"

I found out the hard way, that this defaults to /8 now.


Did you track it down to a specific change?  I.e. is this
ifconfig/netlink or the old kernel change from like two years(?)
ago?

Do you have a time window when this broke as that'll help people to
bisect?


I have no idea, sorry, I just freebsd-updated this one box...



I just tried on 14.0-p6, same there:

 # ifconfig vtnet0 192.168.87.11
 ifconfig: WARNING: setting interface address without mask is
 deprecated, default mask may not be correct.

Interestingly, `ifconfig vtnet0 10.0.0.1` uses "/24" whereas
192.168.87.11 uses "/8".

This dates back to:
https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a


No it pre-dates that chnage.

It goes back to d8237b95552807e937fc389c7e2237679ef0c984 and related
changes.

--
Bjoern A. Zeeb r15:7



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Michael Gmelin



On Wed, 12 Jun 2024 14:36:35 +
"Poul-Henning Kamp"  wrote:

> 
> Bjoern A. Zeeb writes:
> 
> > > I had a machine with this line in /etc/rc.conf:
> > >
> > >   ifconfig_bla0="192.168.87.11"
> > >
> > > I found out the hard way, that this defaults to /8 now.  
> >
> > Did you track it down to a specific change?  I.e. is this
> > ifconfig/netlink or the old kernel change from like two years(?)
> > ago?
> >
> > Do you have a time window when this broke as that'll help people to
> > bisect?  
> 
> I have no idea, sorry, I just freebsd-updated this one box...
> 

I just tried on 14.0-p6, same there:

  # ifconfig vtnet0 192.168.87.11
  ifconfig: WARNING: setting interface address without mask is
  deprecated, default mask may not be correct.

Interestingly, `ifconfig vtnet0 10.0.0.1` uses "/24" whereas
192.168.87.11 uses "/8".

This dates back to:
https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a

-m

-- 
Michael Gmelin



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Poul-Henning Kamp

Rodney W. Grimes writes:

> *Stomps off my soap box, hands phk a bandaid for the bite mark (always,
> always specify critical values even if they are the default), and
> retreats to the background*

/me hands Rod a glass of lemonade: "It's OK, you're welcome on my lawn :-)"

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Rodney W. Grimes
> 
> Michael Gmelin writes:
> 
> > You can do an interface route hack
> 
> I think you misunderstand the situation.
> 
> We are talking about people who have /etc/rc.conf files which relied
> on how default netmasks have worked for nearly three decades,
> 
> Now that we have changed that default, many of them will see a
> single line rapidly scroll off their console, and a set of very
> bewilding symptoms of DNS not working correctly.
> 
> The solution is not for them to apply some weird, complex and
> unnecessary interface configuration.
> 
> The solution is for us to not break their configuration in the first
> place, or at least make it much more obvious to them, where the problem
> is to be found.
> 
> Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever.

Why have I been bitching for 20 years about how the project just
changes "defaults" that effect how a system behavies without
any change by the user.  In my book these are just plainly WRONG
and well, have and continue to bite someone in the ass.

No one else seems to complain unless it bites THEM in the ass,
well there is ALWAYS and THEM so the project should be far
more considerate than they have been, IMHO, about bitting
asses, as those asses are connected to the hands that feed
this project by growth.

It is not that hard to intruduce NEW behavior yet retain the OLD behavior
with lots of warning that it is exepcted to change or go away in
the future.

*Stomps off my soap box, hands phk a bandaid for the bite mark (always,
always specify critical values even if they are the default), and
retreats to the background*

> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.

-- 
Rod Grimes rgri...@freebsd.org



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Poul-Henning Kamp

Bjoern A. Zeeb writes:

> > I had a machine with this line in /etc/rc.conf:
> >
> > ifconfig_bla0="192.168.87.11"
> >
> > I found out the hard way, that this defaults to /8 now.
>
> Did you track it down to a specific change?  I.e. is this
> ifconfig/netlink or the old kernel change from like two years(?) ago?
>
> Do you have a time window when this broke as that'll help people to
> bisect?

I have no idea, sorry, I just freebsd-updated this one box...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Bjoern A. Zeeb

On Wed, 12 Jun 2024, Poul-Henning Kamp wrote:


I had a machine with this line in /etc/rc.conf:

ifconfig_bla0="192.168.87.11"

I found out the hard way, that this defaults to /8 now.


Did you track it down to a specific change?  I.e. is this
ifconfig/netlink or the old kernel change from like two years(?) ago?

Do you have a time window when this broke as that'll help people to
bisect?

--
Bjoern A. Zeeb r15:7



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Bob Bishop
Hi,

> On 12 Jun 2024, at 12:28, Poul-Henning Kamp  wrote:
> 
> Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever.

+1

--
Bob Bishop
r...@gid.co.uk







Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Ronald Klop

Van: Poul-Henning Kamp 
Datum: woensdag, 12 juni 2024 12:39
Aan: Ronald Klop 
CC: curr...@freebsd.org
Onderwerp: Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure 
out


Ronald Klop writes:

> What do you thing about defaulting to /32 on a missing netmask?
> An interface with 1 IP address without any information about the network. All 
traffic can go to the gateway.

I dont think that will work ?

The gateway will not be inside any of the attached networks, so you have no 
route to it ?

Poul-Henning

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.






Ai. Of course. Typed quicker than I was thinking. :-)

Well. Then it is maybe best to just error out on boot with a misconfigured 
network. Or revert back to the pre-14.1 behavior because of POLA.
I'll leave it up to you and will make sure I configure my interfaces with a 
netmask.

Regards,
Ronald.


Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Michael Gmelin



On Wed, 12 Jun 2024 11:28:38 +
"Poul-Henning Kamp"  wrote:

> 
> Michael Gmelin writes:
> 
> > You can do an interface route hack  
> 
> I think you misunderstand the situation.

I completely understand the situation and I can feel your pain, I just
wanted to throw in how to reach the default gateway when using a /32
mask. Hence me ending with "in the context of deciding on default
behavior when no mask is given this is probably not very helpful".
Maybe no news for those following this thread, so sorry if the noise
annoyed you.

> 
> We are talking about people who have /etc/rc.conf files which relied
> on how default netmasks have worked for nearly three decades,
> 
> Now that we have changed that default, many of them will see a
> single line rapidly scroll off their console, and a set of very
> bewilding symptoms of DNS not working correctly.

We had similar breaking changes with the route command[0] (personally I
really would like to support the same syntax for ip/netmasks that is
accepted by pf.conf, but that's off-topic).

If I remember correctly, there was also a breaking change in the syntax
on how to create vlandev's recently.

> 
> The solution is not for them to apply some weird, complex and
> unnecessary interface configuration.

Agreed.

> 
> The solution is for us to not break their configuration in the first
> place, or at least make it much more obvious to them, where the
> problem is to be found.

Agreed as well.

> 
> Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense
> ever.

Agreed - for RFC1918 addresses at least applying the natural default
netmasks (/8, /10, and /16) would feel more logical.

The question is if adding all this magic actually makes sense, or if it
wouldn't be better to just not accept an IP without netmask anymore
(like suggested, make it emit a warning or even make it an error).
Ideally, this should have been a warning/deprecation notice a while ago.

Going back to previous behavior is probably not an option at this point.

One way forward could be to support validating interface settings in
rc.conf by using the a "check" or "configtest" subcommand - this is
already used by many rc scripts (e.g., `service pf check`, `service
nginx configtest`).

So there could be `service netif check`, which can be run manually as
well as automatically as part of freebsd-update/pkgbase (ideally on a
updated config files, but **before** the installation is actually done).

It could also run automatically during boot and display an error +
sleep 5 in case it finds any issues to warn the admin.

Adding such `check` subcommands could actually benefit many rc scripts
(e.g., `service mountlate check`). Being able to call check on all rc
scripts supporting it with one command could also help admins to
identify problems early and therefore give more confidence when reboot
testing configuration changes.

Best
Michael

[0]https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276092

-- 
Michael Gmelin



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Poul-Henning Kamp

Michael Gmelin writes:

> You can do an interface route hack

I think you misunderstand the situation.

We are talking about people who have /etc/rc.conf files which relied
on how default netmasks have worked for nearly three decades,

Now that we have changed that default, many of them will see a
single line rapidly scroll off their console, and a set of very
bewilding symptoms of DNS not working correctly.

The solution is not for them to apply some weird, complex and
unnecessary interface configuration.

The solution is for us to not break their configuration in the first
place, or at least make it much more obvious to them, where the problem
is to be found.

Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Michael Gmelin



On Wed, 12 Jun 2024 10:39:36 +
"Poul-Henning Kamp"  wrote:

> Ronald Klop writes:
> 
> > What do you thing about defaulting to /32 on a missing netmask?
> > An interface with 1 IP address without any information about the
> > network All traffic can go to the gateway.  
> 
> I dont think that will work ?
> 
> The gateway will not be inside any of the attached networks, so you
> have no route to it ?
> 

You can do an interface route hack

  sysrc static_routes="gateway default"
  sysrc route_gateway="-host 1.2.3.4 -interface bla0"
  sysrc route_default="default 1.2.3.4"

This is actually quite useful in some setups, but in the context of
deciding on default behavior when no mask is given this is probably not
very helpful.

Cheers

-- 
Michael Gmelin



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Poul-Henning Kamp
Ronald Klop writes:

> What do you thing about defaulting to /32 on a missing netmask?
> An interface with 1 IP address without any information about the network All 
> traffic can go to the gateway.

I dont think that will work ?

The gateway will not be inside any of the attached networks, so you have no 
route to it ?

Poul-Henning

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.



Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out

2024-06-12 Thread Ronald Klop

Van: Poul-Henning Kamp 
Datum: woensdag, 12 juni 2024 09:47
Aan: curr...@freebsd.org
Onderwerp: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out


I had a machine with this line in /etc/rc.conf:

ifconfig_bla0="192.168.87.11"

I found out the hard way, that this defaults to /8 now.

The main symptom was that DNS was /really/ busted, which makes sense
when none of the DNS servers in the 192/8 "swamp" can be reached.

Since we all know that it is always DNS(SEC), I spent a lot of time
having fun with that, before I noticed the /8 netmask on the interface.

I agree that the class A/B/C netmask assumptions should have died long ago.

But from a foot-shooting point of view, it makes no sense to default
192.168/16 to a /8 netmask.

If we're going to default to /8, at the very least ifconfig should
spitting out a very noisy warning and wait 5 seconds before proceeding,
when the netmask is not explicitly specified.

But I also think we can do better than /8.

One option is to go for "limit the damage in RFC1918" and default
them according to their size: reach:

10/8
172.16/12
192.168/16

That will prevent the DNS weirdness I had to figure out, and probably
still DWIM in most cases.

Another option is to default all three to /24, which in my experience
is how people deploy RFC1918.

A third option is to default any missing netmask to /24 instead of /8,
which would be what I would personally have done in the first place.

Poul-Henning

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
 







What do you thing about defaulting to /32 on a missing netmask?
An interface with 1 IP address without any information about the network. All 
traffic can go to the gateway.

Regards,
Ronald.