Treat rfc6598 addresses (100.64.0.0/10) as non-public about erlang-libp2p HOT 5 CLOSED

There are more non-public ranges than just RFC1918 and RFC6598. Many firewalls solve this problem by downloading a bogon list. The list includes RFC1918, RFC6598, the link local addresses, various test ranges, etc. It also includes ranges that have not been assigned to an ISP or end user yet. The lists are updated periodically, typically once a week or something like this.

IMO, the minimum would be to use a static copy of the "The Text Bogon List, Aggregated" from copied from here: https://team-cymru.com/community-services/bogon-reference/bogon-reference-http/

Even better would be to build a mechanism to update that list periodically (1-2 a day at most should be fine, I think my firewall is set to update once a week) and use the "IPv4 Fullbogons" list on that same bogon reference page.

from erlang-libp2p.

That's a pretty short list, how often does it realistically change?

from erlang-libp2p.

That's a pretty short list, how often does it realistically change?

The version of the list he used in the code is just the RFC'd ranges and in ipv4 land, that's really all there is anymore, everything else is allocated. So it's only likely to change when an existing range is changed. So maybe once every few years? But if there is ever ipv6 support than that changes more often.

from erlang-libp2p.

To add, more extensive bogon lists also includes allocated public IPs address blocks that have not been assigned to an ISP. I do not think that is necessary as the larger risk is misconfiguration using private/shared blocks rather than the broader set of allocated but yet to be assigned IPs. Someone would need to intentionally use an unassigned IP which is not really to their advantage in any way. Misconfigure is the more likely scenario.

from erlang-libp2p.

Closed by #368 and #369.

from erlang-libp2p.