From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Magenheimer" Subject: RE: [PATCH] example and default IP addresses Date: Wed, 16 Jan 2008 10:53:54 -0700 Message-ID: <20080116105354781.00000001968@djm-pc> References: <18318.7874.264603.449572@mariner.uk.xensource.com> Reply-To: "dan.magenheimer@oracle.com" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <18318.7874.264603.449572@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson , "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org 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=3D=3Dw. 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@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com]On Behalf Of Ian Jackson > Sent: Wednesday, January 16, 2008 8:12 AM > To: xen-devel@lists.xensource.com > 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 > = > = >