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@eu.citrix.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dan Magenheimer
2008-Jan-16 17:53 UTC
RE: [Xen-devel] [PATCH] example and default IP addresses
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@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 <ian.jackson@eu.citrix.com> > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2008-Jan-17 15:35 UTC
RE: [Xen-devel] [PATCH] example and default IP addresses
Dan Magenheimer writes ("RE: [Xen-devel] [PATCH] example and default IP
addresses"):> 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.
Firstly, I think it''s important to note that network-nat and vif-nat
are pretty ropey. Anyone who is using them will almost certainly have
had to adjust them to local conditions anyway. For example, these
scripts attempt to find and edit your local dhcp server configuration
file !
> 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.
Having said that, I think you''re right. vif-nat does indeed have to
use 10/8 for static hosts for the reason you give. Although really I
think this is a poor approach. So my change to network-nat ought not
to be applied.
In practice many people using this code in any real setting are likely
to fall foul of address clashes anyway as it''s very likely that they
have at least some use of 10/8 ...
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Daniel P. Berrange
2008-Jan-17 16:03 UTC
Re: [Xen-devel] [PATCH] example and default IP addresses
On Thu, Jan 17, 2008 at 03:35:02PM +0000, Ian Jackson wrote:> Dan Magenheimer writes ("RE: [Xen-devel] [PATCH] example and default IP addresses"): > > 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. > > Firstly, I think it''s important to note that network-nat and vif-nat > are pretty ropey. Anyone who is using them will almost certainly have > had to adjust them to local conditions anyway. For example, these > scripts attempt to find and edit your local dhcp server configuration > file !FYI, for anyone using libvirt we recommend only using network-bridge and vif-bridge. libvirt then provides a ''virtual network'' capability which allows you to define multiple local networks either completely isolated from the physical network, or connected via NAT. This effectively provides same functionality as vif-nat/network-nat, but without requiring the admin to modify shell scripts. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dan Magenheimer
2008-Jan-18 01:52 UTC
RE: [Xen-devel] [PATCH] example and default IP addresses
Hi Keir -- Per the below discussion, could you revert the change to network-nat in the new cset 16739? Thanks, Dan> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com]On Behalf Of Ian Jackson > Sent: Thursday, January 17, 2008 8:35 AM > To: dan.magenheimer@oracle.com > Cc: xen-devel@lists.xensource.com > Subject: RE: [Xen-devel] [PATCH] example and default IP addresses > > > Dan Magenheimer writes ("RE: [Xen-devel] [PATCH] example and > default IP addresses"): > > 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. > > Firstly, I think it''s important to note that network-nat and vif-nat > are pretty ropey. Anyone who is using them will almost certainly have > had to adjust them to local conditions anyway. For example, these > scripts attempt to find and edit your local dhcp server configuration > file ! > > > 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. > > Having said that, I think you''re right. vif-nat does indeed have to > use 10/8 for static hosts for the reason you give. Although really I > think this is a poor approach. So my change to network-nat ought not > to be applied. > > In practice many people using this code in any real setting are likely > to fall foul of address clashes anyway as it''s very likely that they > have at least some use of 10/8 ... > > Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dan Magenheimer
2008-Jan-18 03:27 UTC
RE: [Xen-devel] [PATCH] example and default IP addresses
> On Thu, Jan 17, 2008 at 03:35:02PM +0000, Ian Jackson wrote: > > Dan Magenheimer writes ("RE: [Xen-devel] [PATCH] example > and default IP addresses"): > > > 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. > > > > Firstly, I think it''s important to note that network-nat and vif-nat > > are pretty ropey. Anyone who is using them will almost > certainly have > > had to adjust them to local conditions anyway. For example, these > > scripts attempt to find and edit your local dhcp server > configuration > > file ! > > FYI, for anyone using libvirt we recommend only using network-bridge > and vif-bridge. libvirt then provides a ''virtual network'' capability > which allows you to define multiple local networks either completely > isolated from the physical network, or connected via NAT. > This effectively > provides same functionality as vif-nat/network-nat, but > without requiring > the admin to modify shell scripts.Hi Dan -- Does this handle DHCP as well? If so, can you provide a pointer to more information? Thanks, Dan P.S. With the patch I posted yesterday, the admin doesn''t have to modify shell scripts for vif-nat and network-nat though admittedly the scripts modify them directly which is probably OK if dom0 is not otherwise used as a dhcp server. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Daniel P. Berrange
2008-Jan-18 03:53 UTC
Re: [Xen-devel] [PATCH] example and default IP addresses
On Thu, Jan 17, 2008 at 08:27:01PM -0700, Dan Magenheimer wrote:> > On Thu, Jan 17, 2008 at 03:35:02PM +0000, Ian Jackson wrote: > > > Dan Magenheimer writes ("RE: [Xen-devel] [PATCH] example > > and default IP addresses"): > > > > 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. > > > > > > Firstly, I think it''s important to note that network-nat and vif-nat > > > are pretty ropey. Anyone who is using them will almost > > certainly have > > > had to adjust them to local conditions anyway. For example, these > > > scripts attempt to find and edit your local dhcp server > > configuration > > > file ! > > > > FYI, for anyone using libvirt we recommend only using network-bridge > > and vif-bridge. libvirt then provides a ''virtual network'' capability > > which allows you to define multiple local networks either completely > > isolated from the physical network, or connected via NAT. > > This effectively > > provides same functionality as vif-nat/network-nat, but > > without requiring > > the admin to modify shell scripts. > > Hi Dan -- > > Does this handle DHCP as well? If so, can you provide a pointer to more > information?Yes, it runs a ''dnsmasq'' daemon per virtual network to provide DNS and DHCP services. Each virtual network is setup as a bridge device, so you can have many on a single machine, each with independant DHCP services The original design doc is http://www.gnome.org/~markmc/virtual-networking.html And UI screenshots are http://virt-manager.org/screenshots/networking.html Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel