 |
What the use for a /32 "network" would be? |
 |
In our case we use an external VPS for monitoring our own nets and add this VPS to racktables for documentation reasons. And it seems unnecessary to add a larger network than necessary including IP-addresses not belong to us. I also think that all valid CIDR prefixes should be accepted in RackTables. |
 |
My upstream IP address from my ISP is a /32 in my view. I don't know what it is in their database, but I only have the one IP address to allocate / track. |
|
|
Well, now I tend to agree with that reasons. |
|
|
I've already added the default gateway of that "single ip's", so the network usually covers gateway and respective ip and is obviously larger than /32. Never thought about it, just found it convenient to have the gateway information also stored. |
|
|
Ouch, fine. |
|
|
Can you develop your answer a little? What conclusion have you reached? |
|
|
I missed, that the previous comment doesn't belong to the original reporter. Let this issue remain open. |
 |
/32s are useful on loopback interfaces both on hosts and routers. |
|
|
I second what kyreeth said, loopback interfaces on routers are a common way to have an interface always up for routing protocols to use. |
|
|
So, this issue has been around for about 2 years and for the time being I'm closing it as "will not fix" with the following reasoning: 1. Uplink networks are not /32, they have to be at least /31 and are typically /30. 2. Loopback addresses are often allocated from address pools that also represent a CIDR prefix. 3. Where above doesn't apply, in RackTables it is possible to document any IP address regardless if it belongs to a documented network or not (see IPV4_JAYWALK config option). 4. Extending IPv4 network structure to /32 requires careful changes to application logic. Developer effort is very limited and it is much safer to leave it as is. Excuse me for taking so much time. |
- Anonymous
