Re: removing RIP/RIPng (routed/route6d)

[Paul Vixie]

<> 


That's been a very workable system. 


p vixie 


On May 17, 2024 21:32, "Rodney W. Grimes"  wrote:

> Scott  writes: 
> > Anyway, fun's over.  Perhaps this is a greater lesson that the Foundation 
> > provide the rules under which code is added or removed from base and then 
> > we'd all be the wiser. 
> 
> The FreeBSD Foundation does not set project policy, the FreeBSD Core 
> Team does. 

Sadly that was never my intent when I created the original "Core", 
the core team was to help the developers in setting project policy 
based on there inputs and interactions, not to just elect some 
group of people and then bow down to them for all decisions. 

The DEVELOPERS as a whole is who should be setting all project policies. 

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

Re: removing RIP/RIPng (routed/route6d)

[Paul Vixie]

i think it's not too soon for the bsd community to become less 
reactionary. (yes, i know that's ironic coming from me.)


https://nomadbsd.org/

i'd like freebsd to be fit for a lot of purposes. a complete OS is one 
of those that i will use the most. but not the only one for me, and not 
the only one for the community.


take deep breaths.

re:

John Howie wrote on 2024-05-15 19:04:
FreeBSD (and BSD Unix in general) has a rich history of being a 
“complete” OS – kernel and userland. If there was really a demand for a 
minimalist version of FreeBSD, why have people not forked FreeBSD and 
created it by now? There is also nanobsd, as an option, for those that 
want minimalist installs (yes, I know it is meant for embedded systems, 
but it works).


I think we need to stop trying to find solutions for non-existent problems.

*From: *owner-freebsd-...@freebsd.org  on 
behalf of Marek Zarychta 

*Date: *Wednesday, May 15, 2024 at 11:19 AM
*To: *freebsd-net@freebsd.org 
*Subject: *Re: removing RIP/RIPng (routed/route6d)

Today Michael Sierchio wrote:

There is an argument to be made that all such components of the
"base" system should be packages, and managed that way.  That would
facilitate removal or addition of things like MTAs, Route daemons
for various protocols, etc.  and permit them to be updated
independent of the base system.  Too much is included by default in
Base.

FreeBSD is a comprehensive OS, and most users still do appreciate this 
feature.


I remember that we had also RCS tools in the base system, they got 
purged (moved to the ports tree really), most users are fine with it, 
but for managing single config files RCS is still the best-suited 
versioning system. We still have ftpd(8), but it was almost removed, 
there was a strong battle on the mailing list to preserve it. FTP 
protocol is as old as BSD, but it's still valid and, so far not 
deprecated. A similar story was with smbfs(5). The same probably applies 
to RIP/RIPng.
What if we would better remove LLVM from the base if the system is 
bloated ? LLVM needs frequent updates and keeping it in base is far more 
risky in terms of system security than keeping RIP daemons. Why do we 
still have odd tools like biff(1) in the base ?


On the other hand, for a significant share of the user base, the more 
tiny the OS is, the better. The transition to PkgBase should fulfill 
user needs, especially those, who want a minimalist OS. So please, go 
ahead and switch to PgkBase if your FreeBSD system contains undesired 
software.


Cheers

Marek

On Wed, May 15, 2024 at 1:01 PM John Howie mailto:j...@thehowies.com>> wrote:

I use RIP all the time. Removing it would be a pain. What is the
justification? Moving it to ports is an option, but now we have
to compile, distribute, and install it.

Sent from my iPhone

 > On May 15, 2024, at 07:40, Tomek CEDRO mailto:to...@cedro.info>> wrote:
 >
 > On Wed, May 15, 2024 at 4:20 PM Scott
mailto:uatka3z4z...@thismonkey.com>> wrote:
 >>> On Mon, Apr 15, 2024 at 09:49:27PM +0100, Lexi Winter wrote:
 >>> (..)
 >>> i'd like to submit a patch to remove both of these daemons
from src.  if
 >>> there's some concern that people still want to use the BSD
 >>> implementation of routed/route6d, i'm also willing to
submit a port such
 >>> as net/freebsd-routed containing the old code, in a similar
way to how
 >>> the removal of things like window(1) and telnetd(8) were
handled.
 >>
 >> I use RIPv2 for it's simplicity and small memory and CPU
requirements.  It
 >> has its place and shouldn't be considered "legacy" despite
its shortcomings.
 >> It's not uncommon for vendors like Cisco to produce "basic"
feature sets of
 >> IOS that do not include any link-state protocols.
 >>
 >> Anyway, I'm a user, albeit a small user, of RIP and wouldn't
object to its
 >> removal from FreeBSD if there were a small footprint
alternative.  I've used
 >> FRR and VyOS a bit and they are overkill as replacements.
 >>
 >> Your email doesn't justify its removal other than to say you
are unconvinced
 >> of the value of shipping it.  As a user I definitely see the
value.  I
 >> understand that there is always a cost to providing code,
but that wasn't
 >> suggested as a reason.  All APIs, modules, utilities, etc.
need to regularly
 >> justify their presence in the OS.
 >>
 >> If it must be removed, is there any way to fork the FreeBSD
routed and
 >> route6d to a port?  Or would that defeat the purpose of
removing it in the
 >> first place?
 >
 > Yeah, where did that recent trend came to FreeBSD to remove

Re: Source IPv4 address selection vs BGP IX connection

[Paul Vixie]

agreed. and one of my mods to the ultrix (~4.3bsd) kernel for 
gatekeeper.dec.com back in ~1990 was to use the result of gethostid(3) 
if that result was nonzero and if a socket was not already bound. so 
named(8) and ntpd(8) and anything else that used explicit binding got 
what they expected, but the vast majority who just used INADDR_ANY (or 
more often just bzero(3)'d the sockaddr) would get what the sysadmin 
wanted. multihoming wasn't well understood and has gotten worse since.


of course, gethostid(3) is now deprecated in favour of sysctl(3), and 
the hostid(8) command is gone, and there's now more than one flavour of 
Internet-capable UNIX in the world, and there's more than one Internet 
address family now. so what i did in 1990 is a guide only inasmuch as 
some way should exist to change the default local address of a socket so 
that it isn't the address of the interface used for the destination. if 
that happens i hope we coordinate with Linux and with the other BSD's.


Gregory Shapiro wrote on 2024-04-24 11:00:

I still see value in source IP selection, even outside of the IX use
case.



--
P Vixie

Re: Network starvation question

[Paul Vixie]

ipfw firewalling for bhyve host, bypassing bhyve guests

[Paul Vixie]

You don't need L2 for this. The firewall pattern when your bare metal host has 
an address in the vlan you use for guests is: 


Allow the specific things you want the bare metal host to do; 


Deny all else involving the bare metal host; 


Allow all else involving the guest subnet. 


p vixie 


On Oct 15, 2023 07:14, void  wrote:

Hello, 

My objective is to protect services on a bhyve host, while allowing traffic 
to the bhyve guests to pass to them unprocessed, as these each have pf and 
their own firewall policies. The host running an up-to-date 13-stable. 

I know ipfw can process both layer 2 and layer 3 traffic, but pf only processes 
layer 3 so that is why i want to use ipfw on the bhyve host. 

So we have bridge0 with igb0 tap0 and tap1 as members. 
In this example, igb0 has a mac address of 11:11:11:11:11:11 
tap0 has 22:22:22:22:22:22 
tap1 has 33:33:33:33:33:33 

How can I tell ipfw to pass 22:22:22:22:22:22 and 33:33:33:33:33:33 and apply 
no more rules to frames matching those MACs? 

Let's say I want to just block on 11:11:11:11:11:11 (igb0) port 22 
apart from 10.0.0.0/24 

22:22:22:22:22:22 passing unhindered, unprocessed. 

Possible? 

-- 

propagating interface FIB to PCB

[Paul Vixie]

ed maste pointed me here after he saw me post the following on twixter:

>


to be clear, i can fix this and submit a patch, but won't if there are 
reasons why it was kept this way.


--
P Vixie