tools/docs: Fix 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.

Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>

2 files changed, 8 insertions, 8 deletions

diff --git a/docs/man/xend-config.sxp.pod.5 b/docs/man/xend-config.sxp.pod.5
index 5f949dee3b..3851bba3b4 100644
--- a/docs/man/xend-config.sxp.pod.5
+++ b/docs/man/xend-config.sxp.pod.5
@@ -124,7 +124,7 @@ An example configuration with relocation enabled for the local network:
 =over 4
 
  (xend-relocation-server yes)
- (xend-relocation-address 192.168.1.1)
+ (xend-relocation-address 192.0.2.192)
  (network-script network-bridge)
  (vif-script vif-bridge)
  (dom0-min-mem 0)
diff --git a/docs/src/user.tex b/docs/src/user.tex
index c1c0a35e74..c6884c0040 100644
--- a/docs/src/user.tex
+++ b/docs/src/user.tex
@@ -1807,7 +1807,7 @@ network by adding a line to \path{/etc/exports}, for instance:
 \begin{quote}
   \begin{small}
 \begin{verbatim}
-/export/vm1root      1.2.3.4/24 (rw,sync,no_root_squash)
+/export/vm1root      192.0.2.4/24 (rw,sync,no_root_squash)
 \end{verbatim}
   \end{small}
 \end{quote}
@@ -2076,7 +2076,7 @@ iptables -A INPUT -p tcp --destination-port 8002 -j REJECT
 
 # this command enables Xen relocations only from the specific
 # subnet:
-iptables -I INPUT -p tcp -{}-source 192.168.1.1/8 \
+iptables -I INPUT -p tcp -{}-source 192.0.2.0/24 \
     --destination-port 8002 -j ACCEPT
 \end{verbatim}
 
@@ -5121,9 +5121,9 @@ vnets are working by configuring IP addresses on these interfaces
 and trying to ping them across the network. For example, using machines
 hostA and hostB:
 \begin{verbatim}
-hostA# ifconfig vnif0004 10.0.0.100 up
-hostB# ifconfig vnif0004 10.0.0.101 up
-hostB# ping 10.0.0.100
+hostA# ifconfig vnif0004 192.0.2.100 up
+hostB# ifconfig vnif0004 192.0.2.101 up
+hostB# ping 192.0.2.100
 \end{verbatim}
 
 The vnet implementation uses IP multicast to discover vnet interfaces, so
@@ -5144,8 +5144,8 @@ on the vnet UDP port:
 \end{verbatim}
 
 If multicast is not being forwarded between machines you can configure
-multicast forwarding using vn. Suppose we have machines hostA on 10.10.0.100
-and hostB on 10.11.0.100 and that multicast is not forwarded between them.
+multicast forwarding using vn. Suppose we have machines hostA on 192.0.2.200
+and hostB on 192.0.2.211 and that multicast is not forwarded between them.
 We use vn to configure each machine to forward to the other:
 \begin{verbatim}
 hostA# vn peer-add hostB