More netmap updates

Signed-off-by: Tom Eastep <teastep@shorewall.net>

docs/netmap.xml

@@ -380,10 +380,11 @@ DNAT   10.10.11.0/24  vpn              192.168.1.0/24
 <emphasis role="bold">SNAT:P 192.168.1.0/24 vpn              10.10.10.0/24
 DNAT:T 10.10.10.0/24  vpn              192.168.1.0/24</emphasis></programlisting>
 
-      <para>The last two entries define Stateless NAT by specifying a chain
+      <para>The last two entries define <firstterm>Stateless NAT</firstterm>
-      designator (:P for PREROUTING and :T for POSTROUTING respectively). See
+      by specifying a chain designator (:P for PREROUTING and :T for
-      <ulink url="manpages/shorewall-netlink.html">shorewall-netmap</ulink>
+      POSTROUTING respectively). See <ulink
-      (5) for details.</para>
+      url="manpages/shorewall-netlink.html">shorewall-netmap</ulink> (5) for
+      details.</para>
     </section>
   </section>
 
@@ -391,16 +392,21 @@ DNAT:T 10.10.10.0/24  vpn              192.168.1.0/24</emphasis></programlisting
     <title>IPv6</title>
 
     <para>Beginning with Shorewall6 4.4.24, IPv6 support for Netmap is
-    included. This provides a way to use site local IPv6 addresses internally
+    included. This provides a way to use private IPv6 addresses internally and
-    and still have access to the IPv6 internet.</para>
+    still have access to the IPv6 internet.</para>
 
     <warning>
       <para>IPv6 netmap is <firstterm>stateless</firstterm> which means that
-      there are no helpers for applications that need them. As a consequence,
+      there are no Netfilter helpers for applications that need them. As a
-      applications that require a Netfilter helper (FTP, IRC, etc.) may
+      consequence, applications that require a helper (FTP, IRC, etc.) may
       experience issues.</para>
     </warning>
 
+    <para>For IPv6, the chain designator (:P for PREROUTING or :T for
+    POSTROUTING) is required in the TYPE column. Normally SNAT rules are
+    placed in the POSTROUTING chain while DNAT rules are placed in
+    PREROUTING.</para>
+
     <para>To use IPv6 Netmap, your kernel and iptables must include
     <emphasis>Rawpost Table Support</emphasis>.</para>
 
@@ -412,54 +418,50 @@ DNAT:T 10.10.10.0/24  vpn              192.168.1.0/24</emphasis></programlisting
     <para>IPv6 support is supplied from Hurricane Electric; the IPv6 address
     block is 2001:470:b:227::/64.</para>
 
-    <para>Because of the limitations of IPv6 NETMAP, The servers in the DMZ
+    <para>Because of the limitations of IPv6 NETMAP (no Netfilter helpers),
-    have public addresses in the block 2001:470:b:227::/112. The local LAN
+    the servers in the DMZ have public addresses in the block
-    uses the private network fec0:470:b:227::/64 with the hosts autoconfigured
+    2001:470:b:227::/112. The local LAN uses the private network
-    using radvd.</para>
+    fd00:470:b:227::/64 with the hosts autoconfigured using radvd. This block
+    is allocated from the range (fc00::/7) reserved for<firstterm> <ulink
+    url="http://en.wikipedia.org/wiki/Unique_local_address">Unique Local
+    Addresses</ulink></firstterm>.</para>
 
     <para>The /etc/shorewall6/netmap file is as follows:</para>
 
     <programlisting>#TYPE	NET1			INTERFACE	NET2		NET3		PROTO	DEST	SOURCE
 #												PORT(S)	PORT(S)
-SNAT:T	fec0:470:b:227::/64	HE_IF		2001:470:b:227::/64
+SNAT:T	fd00:470:b:227::/64	HE_IF		2001:470:b:227::/64
 DNAT:P  2001:470:b:227::/64!2001:470:b:227::/112\
-				HE_IF		fec0:470:b:227::/64
+				HE_IF		fd00:470:b:227::/64
 </programlisting>
 
     <para>HE_IF is the logical name for interface sit1. On output, the private
     address block is mapped to the public block. Because autoconfiguration is
     used, none of the local addresses falls into the range
-    fec0:470:b:227::/112. That range can therefore be excluded from
+    fd00:470:b:227::/112. That range can therefore be excluded from
     DNAT.</para>
 
     <note>
       <para>While the site local network that was used is very similar to the
       public network (only the first word is different), that isn't a
       requirement. We could have just as well used
-      fec0:bad:dead:beef::/64</para>
+      fd00:bad:dead:beef::/64</para>
     </note>
 
     <note>
-      <para>The MacBook Pro running OS X Lion refused to autoconfigure a
+      <para>The MacBook Pro running OS X Lion refused to autoconfigure when
-      site-local address.</para>
+      radvd advertised a <ulink
+      url="http://tools.ietf.org/html/rfc3513">site-local</ulink> network
+      (fec0:470:b:227/64) but worked fine with the unique-local network
+      (fd00:470:b:227::/64). Note that site-local addresses were deprecated in
+      <ulink url="http://tools.ietf.org/html/rfc3879">RFC3879</ulink>.</para>
+    </note>
+
+    <note>
+      <para>This whole scheme isn't quite as useful as it might appear. Many
+      IPv6-enabled applications (web browsers, for example) are smart enough
+      to recognize unique local addresses and will only use IPv6 to
+      communicate with other such local addresses.</para>
     </note>
   </section>
-
-  <section id="Notes">
-    <title>Author's Notes</title>
-
-    <para>This could all be made a bit simpler by eliminating the TYPE field
-    and have Shorewall generate both the SNAT and DNAT rules from a single
-    entry. I have chosen to include the TYPE in order to make the
-    implementation a bit more flexible. If you find cases where you can use an
-    SNAT or DNAT entry by itself, please let <ulink
-    url="mailto:webmaster@shorewall.net">me</ulink> know and I'll add the
-    example to this page.</para>
-
-    <para>In the previous section, the table in the example contains a bit of
-    a lie. Because of Netfilter's connection tracking, rules 2B and 1B aren't
-    needed to handle the replies. They ARE needed though for hosts in the
-    bottom cloud to be able to establish connections with the 192.168.1.0/24
-    network in the top cloud.</para>
-  </section>
 </article>