On 04/18/2013 09:08 AM, Gene Czarcinski wrote:
I need some help/guidance as to what networking characteristics
should
be supported by libvirt. Mostly, I am asking what should be valid for
a prefix.
For IPv4:
The prefix can theoretically range from 0 to 32. Typically, the
values of 8, 16 or 24 is used. For an IP specification, should I be
able to specify prefix=32 (netmask 255.255.255.255)? This is not a
network specification but one for a specific guest-host ... but, what
will the virtualization host have for the address on this interface?
Proposed: prefix (or equivalent netmask) must be
8 < prefix < 29
Are you talking about validating the prefix for <ip> elements, or your
new <route> elements? I think that for <route> elements that anything
between 0 and the number of bits in the address should be accepted. If
you put an artificial limit on it, you can be sure that someone will
come along who wants to exceed the limit.
For <ip> elements it's a bit more up in the air. Limiting the range of
prefix for either IPv4 or IPv6 may warn about some potential
misconfigurations, but I'm not sure how important it is.
Does /usr/sbin/ip have any limits about netmask/prefix?
For IPv6: Similar to IPv4 but the range is (theoretically) 0 to 128.
However, DHCPv6 and RA will **ONLY** work for prefix=64 ... nothing
greater and nothing less.
Nothing says that all libvirt networks must support/use DHCPv6 or RA
(although that will very likely be the most common scenario).
For an network on an interface which is visible to the
virtualization host, it must have an address for the host; therefore,
prefix <127. I am not sure what an IP definition with prefix=0 means
for a libvirt virtual network.
Proposed: Prefix=64 for DHCPv6 and/or RA support. For other network
addresses (such as static route),
7 < prefix <= 64.
Most IPv6 software does not appear to handle subnets where prefix > 64
except for prefix=128 for a specific host address.
Which software are you talking about?
That is not to say that prefix <64 prefix < 128 could not have a
meaning and be useful. But, if supported, how should it be specified
so that user problems are minimized ... or do we just support it and
what happens is a user problem?