[libvirt] need help: what should be supported?
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 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. 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. 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? Comments? Suggestions?? Gene
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?
On 04/18/2013 11:27 AM, Laine Stump wrote:
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? OK, for now any prefix is a good prefix (except for the 32 and 128 max-values). However, if I understand what the standards say about IPv6 (no a given), subclassing below prefix=64 was very much "a bad thing to do" even if, personally, I don't see the problem.
Gene
participants (2)
-
Gene Czarcinski -
Laine Stump