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

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

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