In the patch to network-nat, I see that you are replacing the 10.0.0.0/16
usage with 192.0.2.0/24. Actually, vif-nat has a dependency on it
being 10.0.0.0/8(!), at least if more than 256 domains are launched (not
necessarily simultaneously, just sequentially created and destroyed).
In vif-nat ip_from_dom, IP's are created as 10.x.y.z for vifw.z, where
x*256+y==w.
I'm not sure what the right answer is, but 192.0.2.0/24 definitely
doesn't have enough bits. And regardless of the answer, vif-nat will
need to be patched also.
Thanks,
Dan
> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx]On Behalf Of Ian Jackson
> Sent: Wednesday, January 16, 2008 8:12 AM
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] [PATCH] example and default IP addresses
>
>
> In various places in documentation and code, IP addresses are provided
> as examples, defaults, or dummy configuration. In general the
> specific IP addresses used in Xen are not always appropriate. (For
> example, 1.2.3.4 is used in a few places!)
>
> The following addresses should be used:
> * For examples and documentation, 192.0.2.0/24. (See RFC3330.)
> * For defaults for private networks, a random network from RFC1918.
> I have randomly selected 172.30.206.0/24 for this purpose and
> documented this in at the only registry I know of,
> www.ucam.org/cam-grin. This network should henceforth be used for
> default configurations of local bridges, test networks, etc. in
> Xen tools.
>
> The following addresses should NOT be used:
> * 10.0.*.*, 10.1.*.*, 192.168.0.*, 192.168.1.*, etc. Using these
> addresses gives greatly increased likelihood of collision, as
> ignorant network administrators and reckless middlebox vendors
> often pick networks from the bottom of 10/8 and 192.168/16.
> * 169.254.*.*. These are reserved for zeroconf (ad-hoc networking)
> and should not be used for Xen private networks, bridges, etc.,
> etc. Use of these addresses by Xen scripts causes trouble on hosts
> (eg laptops) which find themselves in ad-hoc networking
> environments. I think this is not hypothetical (!) since at least
> one Linux distribution have specific code to detect this case and
> cause Xen startup to fail iff the host already has an external
> zeroconf address.
> * 1.2.3.4. WTF !?
>
> I have also used 127.0.255.255 in one place where apparently a dummy
> address is needed (some Linux kernels won't accept a lack of an NFS
> server address). If 127.0.255.255 is mistakenly used it is unlikely
> to do any damage to real traffic even if it does escape into the
> network at large.
>
> The attached patch corrects these mistakes, I think. It should NOT be
> applied to 3.2-testing, needless to say.
>
> Ian.
>
> Signed-off-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home