On Wed, 11 Jan 2006, Florian Weimer wrote: Thank you for your suggestions.
* william elan net:
For those doing similar exercise, you might want to look at rephrased version of rfc330 listed blocks: http://www.completewhois.com/iana-ipv4-specialuse.txt
You should move 192.88.99.0/24 from SPECIAL to YES (although you shouldn't see source addresses from that prefix, no matter what the folks at bit.nl think). 169.254.0.0/16 should be NO (otherwise it wouldn't be link-local).
I think you just explained it yourself why this is "SPECIAL", i.e. routing of it depends on local policies and setup. Anything where it is not clear from RFCs if it should be routable or not and where it depends on local decisions & policy is what I called SPECIAL. Perhaps better documentation is needed to explain each case, which I'll likely do some point way in the future when html version of the same page also becomes available. It is on the TODO list.
to make the list more future-proof, listing 128.0.0.0/16, 191.255.0.0/16, 192.0.0.0/24 and 223.255.255.0/24 as YES might be a good idea. I'm not sure what to do with 39/8.
Yes, I considered that. Ultimately these blocks might well become routed. It should be pointed out though that the file is not set in stone and was intended to be updated when some block's status changes just like this is done with iana-ipv4-allocations.txt It is however possible that I'll change it to YES with special comment because the data does seem more of something that people are going to configure and left alone rather then expect changes as with bogon data.
I haven't looked at RFC 3330, but another RFC reserves 192.0.2.0/24 for examples in documentation. In practice, this prefix is used for distributing fake null routes over BGP, so it's a rather strong NO.
If you know which RFC it is, I'll update the reference table. -- William Leibzon Elan Networks william@elan.net