[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH] example and default IP addresses

In the patch to network-nat, I see that you are replacing the
usage with  Actually, vif-nat has a dependency on it
being!), 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

I'm not sure what the right answer is, but definitely
doesn't have enough bits.  And regardless of the answer, vif-nat will
need to be patched also.


> -----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, is used in a few places!)
> The following addresses should be used:
>  * For examples and documentation,  (See RFC3330.)
>  * For defaults for private networks, a random network from RFC1918.
>    I have randomly selected 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.
>  *  WTF !?
> I have also used in one place where apparently a dummy
> address is needed (some Linux kernels won't accept a lack of an NFS
> server address).  If 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.