Filter RFC 1918 &amp; 4193 IPv4/6 addresses &amp; prefixes via search #1817

Originally created by @ewysong on GitHub (Jun 26, 2018).

Issue type

[X] Feature request
[ ] Bug report
[ ] Documentation

Environment

Python version: 3.4.8
NetBox version: 2.3.4

Description

I think it would be handy to be able to filter IPv4/6 addresses & prefixes via search based on whether they are a RFC 1918 address or not.

This would allow a quick way to see/not see public/private address space in use by the organization/tenant.

Originally created by @ewysong on GitHub (Jun 26, 2018).  ### Issue type [X] Feature request  [ ] Bug report  [ ] Documentation   ### Environment * Python version: 3.4.8  * NetBox version: 2.3.4   ### Description I think it would be handy to be able to filter IPv4/6 addresses & prefixes via search based on whether they are a RFC 1918 address or not. ![search](https://user-images.githubusercontent.com/17579891/41934181-046d34e8-7954-11e8-8f54-d72f0a60cdb2.PNG) This would allow a quick way to see/not see public/private address space in use by the organization/tenant.

adam added the type: feature status: needs owner pending closure labels 2025-12-29 17:19:23 +01:00

adam closed this issue

adam commented

@kkirsche commented on GitHub (Jul 1, 2018):

For documentation / presentation purposes if exposed in the UI — RFC1918 is specifically for IPv4, you'd want RFC4193 for IPv6

@kkirsche commented on GitHub (Jul 1, 2018): For documentation / presentation purposes if exposed in the UI — RFC1918 is specifically for IPv4, you'd want RFC4193 for IPv6

adam commented

@ewysong commented on GitHub (Jul 3, 2018):

Right. It's updated.

@ewysong commented on GitHub (Jul 3, 2018): Right. It's updated.

adam commented

@sdktr commented on GitHub (Jul 11, 2018):

Maybe a possibility to add your own 'predefined search filters' and define the contents of them to your own needs? These filters should refer to a (set of) container prefixes. You could use this to filter for example on 'only childs of your a container used for customer addressing'

@sdktr commented on GitHub (Jul 11, 2018): Maybe a possibility to add your own 'predefined search filters' and define the contents of them to your own needs? These filters should refer to a (set of) container prefixes. You could use this to filter for example on 'only childs of your a container used for customer addressing'

adam commented

@jeremystretch commented on GitHub (Jul 12, 2018):

This needs to be fleshed out before it can be considered for implementation. "Private" prefixes are not limited to those defined in RFCs 1918 and 4193. There's also RFC 3927, RFC 6598, 127/8, all multicast space, prefixes designated for use only in documentation...

RFC 6890 seems pretty inclusive of the oddball ranges. I'm okay with implementing a filter for this, so long as the qualifier for what constitutes a "private" prefix comes from an authority such as RFC 6890 and not a list we cobble together and have to maintain indefinitely.

@jeremystretch commented on GitHub (Jul 12, 2018): This needs to be fleshed out before it can be considered for implementation. "Private" prefixes are not limited to those defined in RFCs 1918 and 4193. There's also RFC 3927, RFC 6598, 127/8, all multicast space, prefixes designated for use only in documentation... [RFC 6890](https://tools.ietf.org/html/rfc6890) seems pretty inclusive of the oddball ranges. I'm okay with implementing a filter for this, so long as the qualifier for what constitutes a "private" prefix comes from an authority such as RFC 6890 and **not** a list we cobble together and have to maintain indefinitely.

adam commented

https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

@mryauch commented on GitHub (Aug 3, 2018):

Hope this is useful.
The ipaddress Python module has a boolean value is_private on IP addresses. It is based on the IANA IPv4 and IPv6 Special-Purpose Address Registries. Pretty exhaustive lists.
https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv4Address.is_private

>>> from ipaddress import IPv4Address
>>> ip = IPv4Address('10.1.0.1')
>>> ip.is_private
True
>>> ip2 = IPv4Address('8.8.8.8')
>>> ip2.is_private
False
>>>

@mryauch commented on GitHub (Aug 3, 2018): Hope this is useful. The ipaddress Python module has a boolean value is_private on IP addresses. It is based on the IANA IPv4 and IPv6 Special-Purpose Address Registries. Pretty exhaustive lists. https://docs.python.org/3/library/ipaddress.html#ipaddress.IPv4Address.is_private https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml ``` >>> from ipaddress import IPv4Address >>> ip = IPv4Address('10.1.0.1') >>> ip.is_private True >>> ip2 = IPv4Address('8.8.8.8') >>> ip2.is_private False >>> ```

adam commented

@jeremystretch commented on GitHub (Aug 3, 2018):

I'm not sure how well this would work at the database level though. Seems like we've got two options.

Option1: Write the filter to match on an array of all "private" prefixes. Probably not very efficient.

Option 2: Record an is_private flag on the IPAddress and Prefix models when the object is saved. We already do this with address family for some reason, so this would probably work fine. Then we can just filter on is_private. It might make things difficult if the rules for what's considered private change, but that should be rare enough that we could handle it in a database migration.

@jeremystretch commented on GitHub (Aug 3, 2018): I'm not sure how well this would work at the database level though. Seems like we've got two options. Option1: Write the filter to match on an array of all "private" prefixes. Probably not very efficient. Option 2: Record an `is_private` flag on the IPAddress and Prefix models when the object is saved. We already do this with address family for some reason, so this would probably work fine. Then we can just filter on `is_private`. It might make things difficult if the rules for what's considered private change, but that should be rare enough that we could handle it in a database migration.

adam commented

@mryauch commented on GitHub (Aug 3, 2018):

What I do in practice is create an IP address object and check is_private, but I'm only ever doing this with a couple of IPs or netblocks at a time. I definitely agree that doing something like that or your Option 1 at display filter time would be very inefficient.

I also think the danger of the rules being changed is pretty slim. Even if a new small block for some fringe use case is added, it's inherently not an issue until someone expects it to be caught in the filter. At that time they can submit an issue, the updated rules can be checked, and the issue can be quickly and easily resolved. Option 2 sounds great.

Since the ipaddress module already is based on the IANA list, that module will be updated with any new blocks. Instead of reinventing the wheel we could simply create an object from the ipaddress module when adding a new IPAddress/Prefix, then copy is_private's value. I don't know how feasible it is to then perform the same action for every single IPAddress/Prefix during database migrations. That sounds expensive.

@mryauch commented on GitHub (Aug 3, 2018): What I do in practice is create an IP address object and check `is_private`, but I'm only ever doing this with a couple of IPs or netblocks at a time. I definitely agree that doing something like that or your Option 1 at display filter time would be very inefficient. I also think the danger of the rules being changed is pretty slim. Even if a new small block for some fringe use case is added, it's inherently not an issue until someone expects it to be caught in the filter. At that time they can submit an issue, the updated rules can be checked, and the issue can be quickly and easily resolved. Option 2 sounds great. Since the ipaddress module already is based on the IANA list, that module will be updated with any new blocks. Instead of reinventing the wheel we could simply create an object from the ipaddress module when adding a new IPAddress/Prefix, then copy `is_private`'s value. I don't know how feasible it is to then perform the same action for every single IPAddress/Prefix during database migrations. That sounds expensive.

adam commented

@candlerb commented on GitHub (Feb 14, 2019):

Another idea: allow filtering of addresses and prefixes by RIR. Then you just enter 192.168.0.0/16, 172.16.0.0/12 etc as aggregates under an RIR called e.g. "Private" or "RFC1918"

Issue: you might also want negative matching, i.e. show all addresses not within the selected RIR.

@candlerb commented on GitHub (Feb 14, 2019): Another idea: allow filtering of addresses and prefixes by RIR. Then you just enter 192.168.0.0/16, 172.16.0.0/12 etc as aggregates under an RIR called e.g. "Private" or "RFC1918" Issue: you might also want negative matching, i.e. show all addresses *not* within the selected RIR.

adam commented

@jeremystretch commented on GitHub (Apr 27, 2019):

The RIR association approach would work well for prefixes but not for IP addresses, because there's no direct path from IPAddress to RIR. Our best bet is probably to introduce a discrete field or fields.

The netaddr IPNetwork and IPAddress objects provide is_private(), is_reserved(), and is_link_local() methods. We could replicate those individually, or perhaps add a single is_global field set to True so long as the other three are are False.

@jeremystretch commented on GitHub (Apr 27, 2019): The RIR association approach would work well for prefixes but not for IP addresses, because there's no direct path from IPAddress to RIR. Our best bet is probably to introduce a discrete field or fields. The `netaddr` IPNetwork and IPAddress objects provide `is_private()`, `is_reserved()`, and `is_link_local()` methods. We could replicate those individually, or perhaps add a single `is_global` field set to True so long as the other three are are False.

adam commented

@candlerb commented on GitHub (Apr 27, 2019):

The RIR association approach would work well for prefixes but not for IP addresses, because there's no direct path from IPAddress to RIR.

(Aside: I believe there's no direct path from prefix to RIR either. It's prefix -> enclosing aggregate -> RIR, so you could just as well have ipaddress -> enclosing aggregate -> RIR)

Anwyay, I don't object ot having a hard-coded list of private address blocks.

These are listed in IANA registries (v4, v6) - but I think it would be fine to limit it to just the important blocks: v4 /16 or larger, v6 ULA and link-local. Things like 'documentation examples' don't belong on a live network anyway. This would limit the complexity of corresponding filters in postgres queries.

@candlerb commented on GitHub (Apr 27, 2019): > The RIR association approach would work well for prefixes but not for IP addresses, because there's no direct path from IPAddress to RIR. (Aside: I believe there's no direct path from prefix to RIR either. It's prefix -> enclosing aggregate -> RIR, so you could just as well have ipaddress -> enclosing aggregate -> RIR) Anwyay, I don't object ot having a hard-coded list of private address blocks. These are listed in IANA registries ([v4](https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml), [v6](https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml)) - but I think it would be fine to limit it to just the important blocks: v4 /16 or larger, v6 ULA and link-local. Things like 'documentation examples' don't belong on a live network anyway. This would limit the complexity of corresponding filters in postgres queries.

adam commented

@stale[bot] commented on GitHub (Sep 7, 2020):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Sep 7, 2020): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).

adam commented