> Taking this off list This thread would be better served on n...@freebsd.org, what do you think cem? After getting to the end of this I decided I am going to add n...@freebsd.org, and woll...@freebsd.org just in case he is not on that list.
To those first seeing any of this, it is a thread that kinda started in a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235927 you may wish to read that before repling here. > there is a internet draft cooking in the ipv4-cleanup repository on > github. At the moment the history section is well worth reading, but > we may end up splitting it into separate drafts and don't currently > plan to submit it at the march ietf, but to gauge response at > netdevconf and then on the hallway track at the ietf. Thats good, as far as getting the process moving forward. > The last attempt to open up 240/4 died in bickering over how they > would be used rather than making them work, And I suspect what caused that has probably not changed, hence my hesitation on immeditate action. > so we've been patching > everything, testing with a couple testbeds, identifying what else is > broken, and planning a public experiment to take place over the next > 2-3 years. We've had more than a few convos at high levels at icann, > tacit support from folk like vint and so forth (see relevant > discussion on the internet history mailing list), etc. Also good. > Also what we're up to overall is actually a great deal more ambitious > ("a moonshot"). based on my experience on my prior rfcs (like > rfc8290), navigating ietf processes is somewhat easier with lots of > running code to point to. The moonshot on 240/0 would be getting Microsoft to fix there stuff. The OSS arena is trivial once a draft exists. I have backed off more than anything because there is infact, though maybe old, a draft submitted by Cisco. > Actually I regard fixing "zeroth" networking > and making sure https://tools.ietf.org/html/rfc3021 works in more > places as the best short term focus of the project - 240/4 is a > lightning rod for some people, but fixing 0/8 finally (john gilmore > fixed that in 1985 and is kind of bugged about it now), and > reallocating formerly reserved multicast spaces as unicast are also on > that long term agenda. > > (for the record, fixing 0/8 is merely changing the is_zeronet macro - > change that to 0 and 0/8 works. Should have been fixed when bsd 4.2 > finally retired damn it) One of the problems with fixing any of 240/4 or 0/8 is that these address are almost always used in foolishly crafted DDOS attacks so are heavily filtered as both source and destination addresses. > It's only been 10 years since 240/4 sort of started to work. I do > think that this time around with enough support from the open source > community we can make a dent in things in under 5; it would be great > to have a few freebsd folk along for the ride. I have sent a private email to Garratt Wollman asking him to take a look at the PR. If your concerned about my relactance to just go commit the 1 liner, do not let that worry you too much. We do need to do due dillegence, and for me the only real remaing question is does this in any way cause FreeBSD to be out of conformance with either host requirements or router requirements, or FIPS or other standards, as we do have downstreams who have strict requirements in these areas. > Dave T?ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 -- Rod Grimes rgri...@freebsd.org _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
