Why are subnet masks required for IP Addresses?

[ritkit]

I am curious as to why cidr mask is required for IP Addresses. I understand Prefix's and maybe ranges.
However, why for singular addresses that may be assigned to interfaces or resources?

[rodvand]

Have you ever configure a network interface without inputing the subnet mask? That's why.

[candlerb]

It's also a pain in 'real' networks. A source of truth shouldn't duplicate data, because whenever you have manual duplication of data, there will always be inconsistencies.

For example, we have a bunch of networks with public IPs that are /26; however people who are assigning IP address often enter /24 because Netbox forces them to enter something, and that's what they learned with private IPs. So either I need to run reports periodically to highlight all the inconsistencies, and fix them by hand (in order for the data to be "clean"); or I just accept that the prefix lengths will be wrong, which looks bad but doesn't otherwise break anything for the way we use Netbox.

Netbox has recently gained custom validation capabilities, so these days it might be possible for me to hook something into that. However I'd really prefer the data to be modelled in a non-duplicative way: one prefix, many IP addresses. I don't buy the argument that "this is inefficient": that's premature optimisation, and IMO good data design comes ahead of shaving a microsecond off query times.

However I lost this argument with @jeremystretch years ago. For a while I did run a local modification to Netbox which let users enter IPs without prefix, setting them to /32 or /128 automatically. But there are big advantages to sticking with "stock" Netbox when it comes to applying updates.

[llamafilm]

@candlerb do you know if the rules have changed since you posted this? With no modification, I am able to create an IP with no mask in nbshell and it defaults to /32.

>>> ip = IPAddress(address='192.168.5.1')
>>> ip.save()
>>> IPAddress.objects.last()
<IPAddress: 192.168.5.1/32>

I would also prefer not duplicating data (single source of truth) but since we are currently forced to, I'm trying to decide if I want to enter correct masks on every address, or make them all 32 to avoid mistakes.

[candlerb]

No, it's not changed. The check that the user supplies a prefix length is in the form, not the model.

./netbox/ipam/formfields.py:            raise ValidationError('CIDR mask (e.g. /24) is required.')

Postgres' "inet" type is happy to default the mask - see docs:

If the /y portion is omitted, the netmask is taken to be 32 for IPv4 or 128 for IPv6, so the value represents just a single host.

Incidentally, you forgot to do ip.full_clean() - this is a very common error by Django users. Sadly save() does not perform validation and lets you save invalid models. However, in this case it doesn't make any difference.

EDIT: for a while in 2017 I ran a patched version of Netbox to work in exactly the way you said. However in the end I decided it was better not to fork, to make it easier for upgrades. FWIW, here is the patch I wrote (it may not apply cleanly any more)

--- a/netbox/ipam/formfields.py
+++ b/netbox/ipam/formfields.py
@@ -23,8 +23,8 @@ class IPFormField(forms.Field):
             return value

         # Ensure that a subnet mask has been specified. This prevents IPs from defaulting to a /32 or /128.
-        if len(value.split('/')) != 2:
-            raise ValidationError('CIDR mask (e.g. /24) is required.')
+        #if len(value.split('/')) != 2:
+        #    raise ValidationError('CIDR mask (e.g. /24) is required.')

         try:
             return IPNetwork(value)
diff --git a/netbox/ipam/models.py b/netbox/ipam/models.py
index 73a522d..de1270b 100644
--- a/netbox/ipam/models.py
+++ b/netbox/ipam/models.py
@@ -394,6 +394,8 @@ class IPAddress(CreatedUpdatedModel, CustomFieldModel):
         verbose_name_plural = 'IP addresses'

     def __str__(self):
+        if self.address and self.address.size == 1:
+            return str(self.address.ip)
         return str(self.address)

     def get_absolute_url(self):
diff --git a/netbox/ipam/tables.py b/netbox/ipam/tables.py
index bd81b00..426f5e0 100644
--- a/netbox/ipam/tables.py
+++ b/netbox/ipam/tables.py
@@ -69,7 +69,11 @@ PREFIX_ROLE_LINK = """

 IPADDRESS_LINK = """
 {% if record.pk %}
+    {% if record.address and record.address.size == 1 %}
+    <a href="{{ record.get_absolute_url }}">{{ record.address.ip }}</a>
+    {% else %}
     <a href="{{ record.get_absolute_url }}">{{ record.address }}</a>
+    {% endif %}
 {% elif perms.ipam.add_ipaddress %}
     <a href="{% url 'ipam:ipaddress_add' %}?address={{ record.1 }}{% if prefix.vrf %}&vrf={{ prefix.vrf.pk }}{% endif %}{% if prefix.tenant %}&tenant={{ prefix.tenant.pk }}{% endif %}" class="btn btn-xs btn-success">{% if record.0 <= 65536 %}{{ record.0 }}{% else %}Many{% endif %} IP{{ record.0|pluralize }} available</a>
 {% else %}

[llamafilm]

Nice. I just opened a feature request for this. If it’s not accepted I may go the patching route.

[llamafilm]

@candlerb I adapted your patch to version 4.0.8. I've never used patch command before, but this seems easy enough to maintain, so I'll do this because all my users and I hate the /32 cluttering up the display.

diff --git a/netbox/ipam/models/ip.py b/netbox/ipam/models/ip.py
index 0b8e3a8df..60b3e0852 100644
--- a/netbox/ipam/models/ip.py
+++ b/netbox/ipam/models/ip.py
@@ -636,7 +636,7 @@ class IPRange(ContactsMixin, PrimaryModel):
         start_str = separator.join(start_chunks[len(base_chunks):])
         end_str = separator.join(end_chunks[len(base_chunks):])
 
-        return f'{base_str}{separator}{start_str}-{end_str}/{self.start_address.prefixlen}'
+        return f'{base_str}{separator}{start_str}-{end_str}'
 
     def _set_prefix_length(self, value):
         """
@@ -678,7 +678,7 @@ class IPRange(ContactsMixin, PrimaryModel):
         if not available_ips:
             return None
 
-        return '{}/{}'.format(next(available_ips.__iter__()), self.start_address.prefixlen)
+        return '{}'.format(next(available_ips.__iter__()))
 
     @cached_property
     def utilization(self):
@@ -789,6 +789,8 @@ class IPAddress(ContactsMixin, PrimaryModel):
         verbose_name_plural = _('IP addresses')
 
     def __str__(self):
+        if self.address and self.address.size == 1:
+            return str(self.address.ip)
         return str(self.address)
 
     def __init__(self, *args, **kwargs):
diff --git a/netbox/ipam/tables/ip.py b/netbox/ipam/tables/ip.py
index 10dea3a92..0baa564b0 100644
--- a/netbox/ipam/tables/ip.py
+++ b/netbox/ipam/tables/ip.py
@@ -49,8 +49,11 @@ PREFIX_LINK_WITH_DEPTH = """
 
 IPADDRESS_LINK = """
 {% if record.pk %}
-    <a href="{{ record.get_absolute_url }}" id="ipaddress_{{ record.pk }}">{{ record.address }}</a>
-{% elif perms.ipam.add_ipaddress %}
+    {% if record.address and record.address.size == 1 %}
+        <a href="{{ record.get_absolute_url }}" id="ipaddress_{{ record.pk }}">{{ record.address.ip }}</a>
+    {% else %}
+        <a href="{{ record.get_absolute_url }}" id="ipaddress_{{ record.pk }}">{{ record.address }}</a>
+    {% endif %}{% elif perms.ipam.add_ipaddress %}
     <a href="{% url 'ipam:ipaddress_add' %}?address={{ record.1 }}{% if object.vrf %}&vrf={{ object.vrf.pk }}{% endif %}{% if object.tenant %}&tenant={{ object.tenant.pk }}{% endif %}" class="btn btn-sm btn-success">{% if record.0 <= 65536 %}{{ record.0 }}{% else %}Many{% endif %} IP{{ record.0|pluralize }} available</a>
 {% else %}
     {% if record.0 <= 65536 %}{{ record.0 }}{% else %}Many{% endif %} IP{{ record.0|pluralize }} available
@@ -297,9 +300,13 @@ class PrefixTable(TenancyColumnsMixin, NetBoxTable):
 # IP ranges
 #
 class IPRangeTable(TenancyColumnsMixin, NetBoxTable):
-    start_address = tables.Column(
+    start_address = tables.TemplateColumn(
+        template_code='<a href="{{ record.get_absolute_url }}">{{ record.start_address.ip }}</a>',
         verbose_name=_('Start address'),
-        linkify=True
+    )
+    end_address = tables.TemplateColumn(
+        template_code='{{ record.end_address.ip }}',
+        verbose_name=_('End address'),
     )
     vrf = tables.TemplateColumn(
         template_code=VRF_LINK,

[mtinberg]

You can still record a /32 or /128 for the "but sometimes" cases, the most common cases are going to need the netmask when using the IP in a config template, so having it available without needing a second API call to find the Active Prefix containing the IP is helpful. Better to have and not need than need and not have. You can still query for an IP without the netmask as well, at least for IPv4, to find the right record from tools which may not already know the netmask. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Brian Candler ***@***.***> Sent: Wednesday, February 23, 2022 3:21 PM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [netbox-community/netbox] Why are subnet masks required for IP Addresses? (Discussion #8731) I have instances in EC2. They have public IPs without a netmask. — Reply to this email directly, view it on GitHub<#8731 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UMZS5ZEH4ADUWQBLQZLU4VFUHANCNFSM5PFQCISQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ritkit]

Ya this was the idea that came to mind of why it was implemented. Just felt like it was redundant documentation when prefixes existed.

I can kind of see the loop issue where when using an API call to grab an IP Address. How best to package an answer to an API call trying to collect a Child Resource but include the Parent info. Always include the smallest prefix? Do you allow a call to a larger prefix? Do you expect the caller to make the connection?

I kind of want to stab at solving this because I hate filling in redundant information that much!

[mtinberg]

You can record IP addresses without a containing Prefix record though, so would you require a Prefix to record an IP or fail to return netmasks for IPs that exist without a Prefix? And how does that work within the Django ORM? — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Kit ***@***.***> Sent: Wednesday, February 23, 2022 3:52 PM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] Why are subnet masks required for IP Addresses? (Discussion #8731) Ya this was the idea that came to mind of why it was implemented. Just felt like it was redundant documentation when prefixes existed. I can kind of see the loop issue where when using an API call to grab an IP Address. How best to package an answer to an API call trying to collect a Child Resource but include the Parent info. Always include the smallest prefix? Do you allow a call to a larger prefix? I kind of want to stab at solving this because I hate filling in redundant information that much! — Reply to this email directly, view it on GitHub<#8731 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM53LGW5VNN2AAAK2MDU4VJIBANCNFSM5PFQCISQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[ritkit]

Totally did not realize that was possible to add an address without a prefix. I have just always trained everyone and assumed myself if the prefix does not exist add it before adding addresses. Besides the address prefix's are way more important for planning purposes and the IP Addresses are way more important for implementation purposes. So I make sure everyone is documenting both.

[mtinberg]

I would be nice if this could be inherited from the Prefix, and I wonder if a new logic could be tested out as a plugin, before attempting to change something that would impact everyone. Eg. If the mask on a new IPAddress object is supplied then use it but if the mask is not submitted on a new IPAddress object then try to look up the containing Prefix and use that mask, otherwise /32 or /128 depending on the address family. That shouldn't break existing tools which already include the netmask, and it should keep the same db schema (comment in fields.py says it's a PostgreSQL INET column and is returned as a Python netaddr.IPNetwork object IIUC) I'm not sure if this logic would be added to fields.py or somewhere else, I'd be concerned about adding more db lookups for data coming out of the db or interfering with the exception handling when trying to validate the submitted value, since we'd start expecting incomplete values and still need to raise an exception if our attempt to flesh them out fails. We may only want this to modify incomplete values going into the db and not read from the db, but I don't know enough about Django or Python to know whether adding a new to_python method in IPAddressField is the right approach or totally the wrong way to attempt this. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Brian Candler ***@***.***> Sent: Thursday, February 24, 2022 2:35 AM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] Why are subnet masks required for IP Addresses? (Discussion #8731) It's also a pain in 'real' networks. A source of truth shouldn't duplicate data, because whenever you have manual duplication of data, there will always be inconsistencies. For example, we have a bunch of networks with public IPs that are /26; however people who are assigning IP address often enter /24 because Netbox forces them to enter something, and that's what they learned with private IPs. So either I need to run reports<https://github.com/netbox-community/reports/blob/master/reports/ipam-reports/ip-check-prefix.py> periodically to highlight all the inconsistencies, and fix them by hand (in order for the data to be "clean"); or I just accept that the prefix lengths will be wrong, which looks bad but doesn't otherwise break anything for the way we use Netbox. Netbox has recently gained custom validation capabilities, so these days it might be possible for me to hook something into that. However I'd really prefer the data to be modelled in a non-duplicative way: one prefix, many IP addresses. I don't buy the argument that "this is inefficient": that's premature optimisation, and IMO good data design comes ahead of shaving a microsecond off query times. However I lost this argument with @jeremystretch<https://github.com/jeremystretch> years ago. For a while I did run a local modification to Netbox which let users enter IPs without prefix, setting them to /32 or /128 automatically. But there are big advantages to sticking with "stock" Netbox when it comes to applying updates. — Reply to this email directly, view it on GitHub<#8731 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM55YR5LTV3BNSEOIVTU4XUTJANCNFSM5PFQCISQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[candlerb]

I believe you're saying that the data model is unchanged, i.e. each IP address still has a prefix length. If so, can you clarify your proposal in the following ways:

1. Should it be optional that you enter a prefix length for an IP address, or that you never provide one and it's always auto-generated?
2. If entering a prefix length is optional, but you enter a prefix length which does not match the nearest enclosing prefix, what should happen? Validation error; silently correct it; keep it but flag a warning message; something else?
3. If entering a prefix length is optional, under what circumstances is it permitted to enter an IP address with /32 or /128 as prefix length? (e.g. the enclosing prefix is marked as "is_pool"; the IP address itself is marked with a role like Loopback / VIP / VRRP etc; something else; never?)
4. When you save (modify) and IP address object, is its prefix length checked again the enclosing prefix? What happens here if it doesn't match?
5. When you modify and/or delete a prefix, does this automatically update all child IP addresses within it?
6. If you are never allowed to provide the prefix length, but you enter an IP address which has no enclosing prefix, what should happen? Set it to /32 or /128?

[mtinberg]

Responding in-line

I believe you're saying that the data model is unchanged, i.e. each IP address still has a prefix length. If so, can you clarify your proposal in the following ways:

Yes, don't change the column type or return value for the address​ of an IPAddress object as that would be disruptive to existing code and expectations about the contents of this value.

Should it be optional that you enter a prefix length for an IP address, or that you never provide one and it's always auto-generated?

Optional, so that existing scripts and operational procedures that expect to set and get addresses in CIDR notation still work

If entering a prefix length is optional, but you enter a prefix length which does not match the nearest enclosing prefix, what should happen? Validation error; silently correct it; keep it but flag a warning message; something else?

It should accept the value as it would today, no exception, no correction. You can have a validation report that runs later to catch errors, or use the custom validator feature to enforce compliance, but Netbox shouldn't override what the Network Engineer inputs, unless it's just a totally invalid input (like a string in a number field).

If entering a prefix length is optional, under what circumstances is it permitted to enter an IP address with /32 or /128 as prefix length? (e.g. the enclosing prefix is marked as "is_pool"; the IP address itself is marked with a role like Loopback / VIP / VRRP etc; something else; never?)

It's always valid to enter as /32 or /128 and I don't think there should be enforcement of business rules like that unless the Netbox Admin / Network Engineer opt-in to it.

When you save (modify) and IP address object, is its prefix length checked again the enclosing prefix? What happens here if it doesn't match?

I would not interfere with the user putting whatever prefix length they want and only guess when it's not provided. There may be a case where an _existing_ IPAddress object is modified and the new address​ field is not fully populated, then you'd have to decide wither to auto-generate the netmask, use the existing one from the record or throw an exception (or none of these if the address field is not modifiable without creating a new record ID, I didn't take time to test this before replying)

When you modify and/or delete a prefix, does this automatically update all child IP addresses within it?

No, I wouldn't recommend that, but an audit report could offer to do this if desired. I wouldn't want surprising behavior for an existing Netbox user, making changes like this would catch someone out and break their workflow.

If you are never allowed to provide the prefix length, but you enter an IP address which has no enclosing prefix, what should happen? Set it to /32 or /128?

While as I stated I wouldn't forbid CIDR notation, yes I'd set to /32 or /128 if there were no enclosing prefix, although another wrinkle that just came to mind is if someone creates a 0/0 or 10/8 or whatever Prefix, would that be the "enclosing" prefix and create a bunch of IPAddress records with /8 netmasks, which was probably not what the Netbox User wanted.. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison Message ID: ***@***.***>

[llamafilm]

This proposal sounds like it will lead to top many inconsistencies from people mistakenly entering wrong data. I suggest instead changing the data model like this:

1. IP addresses must be associated with a parent prefix. Trying to create an IP address without a prefix will fail.
2. IP addresses are always entered in dotted notation, without CIDR range.
3. Mask length is a property of the prefix.
4. There could be an optional user preference to display IP addresses in CIDR notation by inheriting the mask length. I would personally never use this, I just mention it in case folks want to preserve the existing display.
5. A one-time upgrade script modifies all existing addresses and creates any missing prefixes.

The main benefits I see here are reducing redundant data entry, which saves time and reduces potential errors. And making it easier on the eyes when looking at big lists of addresses.

[chatasos]

Any idea what happened with this one? The concept seems quite interesting.
Maybe a configuration option could enable/disable this functionality, keeping always in mind that the final stored data would be the same in both cases.