Martin Schröder wrote:
> Am Sa., 28. Mai 2022 um 22:46 Uhr schrieb Seth David Schoen
> :
> > We're also interested in talking about whether there's an appropriate
> > path for supporting non-broadcast use of addresses within 127/8, our
> > most controversial change. In Linux and FreeBSD, we're
On 5/28/22 5:22 PM, Crystal Kolipe wrote:
There certainly are people using this behaviour of the loopback address(es)
in creative ways on non-OpenBSD systems:
https://timkay.com/solo/
Changing it on those systems will likely break various users' scripts in
unexpected ways.
The script
Am Sa., 28. Mai 2022 um 22:46 Uhr schrieb Seth David Schoen
:
> We're also interested in talking about whether there's an appropriate
> path for supporting non-broadcast use of addresses within 127/8, our
> most controversial change. In Linux and FreeBSD, we're experimenting
IPv6 is now older
On Sat, May 28, 2022 at 01:46:18PM -0700, Seth David Schoen wrote:
> We're also interested in talking about whether there's an appropriate
> path for supporting non-broadcast use of addresses within 127/8, our
> most controversial change. In Linux and FreeBSD, we're experimenting
> with the ideas
Theo de Raadt writes:
> This discussion relates to only one step of a number of potential increments.
>
> I believe it is a bad idea to conflate all of these potential address
> space recovery changes as the same singular discussion. Not all the
> decisions being made on intranets are sane.
I would agree with the diff.. @claudio (for what it is worth)
in principle 240.0.0.0/4 was reserved for future use in the past...
so changing that today makes sense to me ...
On Fri, 6 May 2022 at 13:20, Claudio Jeker wrote:
>
> On Thu, May 05, 2022 at 11:37:24AM +0200, Claudio Jeker wrote:
On Fri, May 06, 2022 at 02:11:46PM +0200, Claudio Jeker wrote:
> On Thu, May 05, 2022 at 11:37:24AM +0200, Claudio Jeker wrote:
> > So most routing daemons and other network daemons like pppd do not allow
> > 240/4 as IPs because they check the IP against IN_BADCLASS().
> > I think it is time to
On Thu, May 05, 2022 at 11:37:24AM +0200, Claudio Jeker wrote:
> So most routing daemons and other network daemons like pppd do not allow
> 240/4 as IPs because they check the IP against IN_BADCLASS().
> I think it is time to remove this restriction.
>
> Now there is another magical network
On 2022/05/05 15:28, Jeroen Massar wrote:
> Though they did it with 1.0.0.0/8 (though that is just a huge network
> telescope).
No this still does not work reliably
It is like you are trying to predict the next 20 years, but I'm sorry
I find it too confusing.
Jeroen Massar wrote:
> > On 5 May 2022, at 15:36, Theo de Raadt wrote:
> >
> > Jeroen Massar wrote:
> >
> >> I thus mostly see these odd prefixes (0/8, 127/8, 240/4) as extra RFC1918
> >> space
>
Jeroen Massar wrote:
> I thus mostly see these odd prefixes (0/8, 127/8, 240/4) as extra RFC1918
> space
> for those who do want to deploy more IPv4 as they can't be arsed after almost
> 30 years to finally do this IPv6 thing...
But that's the dangerous part.
If the operating systems suddenly
This discussion relates to only one step of a number of potential increments.
I believe it is a bad idea to conflate all of these potential address
space recovery changes as the same singular discussion. Not all the
decisions being made on intranets are sane. Not all of these proposals
make
So most routing daemons and other network daemons like pppd do not allow
240/4 as IPs because they check the IP against IN_BADCLASS().
I think it is time to remove this restriction.
Now there is another magical network 0.0.0.0/8 which is not allowed in
some but not all of the routing daemons. Not
13 matches
Mail list logo
