Andreas Schwab writes ("Re: [Qemu-devel] Making qemu use 10.0.3.x not
10.0.2.x"):
> Samuel Thibault <[EMAIL PROTECTED]> writes:
> > Mmm, actually, shouldn't qemu use a more "private" network like a
> > RFC1918 172.16.0.0/12 network?
>
> In which way is 172.16.0.0/12 more "private" than 10.0.0.0/8?
It isn't. There is no particular reason to choose one rather than
another so in that sense I disagree with Samuel.
However, there are two things wrong with the current qemu
arrangements. The first is that the range isn't configurable without
recompiling. I agree with Johannes Schindelin that it should be.
The second is that addresses chosen from RFC1918 space should be
chosen randomly. Quoting the RFC:
If two (or more) organizations follow the address allocation
specified in this document and then later wish to establish IP
connectivity with each other, then there is a risk that address
uniqueness would be violated. To minimize the risk it is strongly
recommended that an organization using private IP addresses choose
randomly from the reserved pool of private addresses, when allocating
sub-blocks for its internal allocation.
I don't believe that 10.0.2.0/24 was chosen randomly :-). It would be
better for qemu's default range to be a randomly chosen one.
The URL Samuel quotes, www.ucam.org/cam-grin, is a personal project of
mine which helps choose random addresses and which can also be used
for documenting one's usage.
So while this setup is being made configurable, I think it would
probably be best for qemu's range to be changed to a random range. I
would suggest 172.30.206.0/24 which is already used as a default for
some regression testing in Xen; since Xen's and qemu's management
setups are best regarded as alternatives, there is less problem with
clashes. As an alternative, a new range can be chosen randomly quite
easily.
I think it would also be good for one of the qemu maintainers to
document qemu's use in my registry.
Ian.
