Open Stack

Paul Ward wrote:

>Given your statement about routers potentially using a /30 network, I think we should leave the restriction at /30
>rather than /29.  I'm assuming your statement that >some routers use /30 subnets to connect to each other could
>potentially apply to neutron-created routers.

Generally speaking I’ve only seen /30 on point to point links. For most purposes the network number (all zeros host part) and broadcast (all ones host part) are not valid host addresses so a /30 only has two usable addresses. This is perfect on a point to point link which only has two endpoints, but kind of silly on a broadcast domain.

However, what is the user perceived impact of your code? Will the error message propagate back to the user directly or do they simply get an unexplained failure while the explanatory error message gets dumped into a log file which is visible only to the provider, not the tenant?

Putting a friendly helper in Horizon will help novice users and provide a good example to anyone who is developing an alternate UI to invoke the Neutron API. I’m not sure what the benefit is of putting code in the backend to disallow valid but silly subnet masks. I include /30, /31, AND /32 in the category of “silly” subnet masks to use on a broadcast medium. All three are entirely legitimate subnet masks, it’s just that they’re not useful for end host networks.

>My reasoning behind checking the number of IP addresses in the subnet rather than the actual CIDR prefix length
>is that I want the code to be IP version agnostic.  If we're talking IPv6, then /30 isn't going to be relevant.  I'm not
>overly familiar with IPv6, but is it safe to say it has the same restriction that there must be more than 2 IPs >available as the highest IP is the broadcast?

No, it actually isn’t safe to say that at all. IPv6, in what I consider to be “broken by design” but others defend vehemently, mandates that no subnet mask longer (i.e. numerically larger) than /64 is allowed. Some people grudgingly acknowledge that a /128 mask is acceptable for router loopback addresses and fewer people accept /126 for point to point links, but pretty much everyone agrees that anything between /64 to /126 should never be used.

Some people state that using a mask longer than /64 will break fundamental parts IPv6. I’m of the opinion that it was already broken and using masks longer than /64 merely reveals what’s broken rather than causing the breakage. Nevertheless, it’s too late to change those parts of IPv6 now. They’re set in stone and we’re stuck with the fact that all broadcast domains (i.e. layer 2 segments, VLANs, end host subnets) must be /64 and nothing else. Masks shorter than /64 (i.e. numbers smaller than 64) are for route aggregation and belong in the world of routing protocols and IPAM databases.

One could probably make a convincing argument that as far as neutron subnet-create is concerned there’s no reason to even accept a subnet mask at all. Anything other than /64 is pretty much 99.999% guaranteed to be user error.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140124/a41a2e2d/attachment.html>