Date: Fri, 22 Feb 2019 16:22:41 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 235927] FreeBSD does not reply to ICMP requests when assigned an ip in 240.0.0.0/8 Message-ID: <bug-235927-7501-f0fVfGcXT6@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-235927-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-235927-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D235927 Dave Taht <dave.taht@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dave.taht@gmail.com --- Comment #8 from Dave Taht <dave.taht@gmail.com> --- (In reply to Rodney W. Grimes from comment #7) To clarify a few things...=20 The last major attempt at making 240/4 "real" happened in the 2008-2010 timeframe - bsd and linux gained the ability to assign and route it around = then (and osx had it in the first place). The IETF conflated "making it work" wi= th "how they should be used" and after the CGN address space was defined suppo= rt died out there. There was consensus then about making them unicast, I think, from talking to all the participants in the debate. Linux had one teeny patch dropped on the floor back then which allowed assignment from the ifconfig sysctl still used by busybox (otherwise the netlink based tools like iproute had no restrictions), so it had otherwise = been able to assign/route/ping for all this time. So we just fixed that (and obsoleted IN_EXPERIMENTAL entirely) in linux 4.20 and backported it to open= wrt. There's other patches outstanding across other tools in the ipv4-cleanup gi= thub repo. So... the minor bug regarding using this space on freebsd was this single l= ine check for icmp, and I don't think removing that needs a sysctl or ifdef. assignment and routing already work.=20 I agree that after kernel support lands that the next bigger barriers are firewalls, bcp38, and other devices on the path... and the ietf. Knocking o= ut the ping issue is just one small step along the way. Lastly, it's far from a lone dev at pushing this stuff forward again, howev= er we totally don't mind just accumulating more patches in our repo until more visibility and consensus is achieved. That said... one line patch... --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-235927-7501-f0fVfGcXT6>