diff --git a/LDP/guide/docbook/linux-ip/advanced-ip.xml b/LDP/guide/docbook/linux-ip/advanced-ip.xml
index 5b675298..06468f9a 100644
--- a/LDP/guide/docbook/linux-ip/advanced-ip.xml
+++ b/LDP/guide/docbook/linux-ip/advanced-ip.xml
@@ -24,14 +24,33 @@
     </para>
   </section>
   <section id="adv-proxy-arp">
-    <title>Breaking a network in two with proxy arp</title>
+    <title>Breaking a network in two with proxy ARP</title>
     <para>
-      Proxy ARP is a method of advertising by a routing device 
-      for a destination on one ethernet which is reachable via another
-      ethernet.  Frequently, a bridge is used instead.  If a machine sits
+      Proxy ARP is a technique for splitting an IP network into two
+      separate segments.  Hosts on one segment can only reach hosts in the
+      other segment through the router performing proxy ARP.  If a router sits
       between two parts of an IP network and is not running bridging software,
-      then routing and proxy ARP are required to allow each half of the IP
-      network to communicate with another.
+      then routes to hosts in each segment and proxy ARP are required
+      on the router to allow each half of the
+      network to communicate with the other half.
+    </para>
+    <para>
+      Occasionally, this technique is incorrectly called proxy ARP bridging.
+      An ethernet bridge operates on frames and a router operates on packets.
+      The proxy ARP router should have routes to all hosts on both segments.
+      Once the router can reach all locally connected destinations via the
+      correct interfaces, you can begin to configure the proxy ARP
+      functionality.
+    </para>
+    <para>
+      Although proxy ARP complicates a network, a great advantage of proxy ARP
+      technique is the greater control over IP connections between hosts.
+    </para>
+    <para>
+      There are two primary proxy ARP techniques.  With the 2.4 kernel, it is
+      possible to use the sysctl
+      <filename>net/ipv4/conf/all/proxy_arp</filename> to perform proxy ARP.
+      Alternatively, manual population of the ARP table reaches the same end.
     </para>
     <para>
       The key part of the correct functioning of proxy ARP in a network is
diff --git a/LDP/guide/docbook/linux-ip/advanced-routing.xml b/LDP/guide/docbook/linux-ip/advanced-routing.xml
index 3fa6061d..b1f663e4 100644
--- a/LDP/guide/docbook/linux-ip/advanced-routing.xml
+++ b/LDP/guide/docbook/linux-ip/advanced-routing.xml
@@ -3,9 +3,8 @@
 <chapter id="ch-advanced-routing">
   <title>Advanced IP Routing</title>
   <section id="adv-routing">
-    <title>Introduction to Advanced Routing</title>
+    <title>Introduction to Policy Routing</title>
     <para>
-      FIXME
     </para>
   </section>
   <section id="adv-overview">
diff --git a/LDP/guide/docbook/linux-ip/ether.xml b/LDP/guide/docbook/linux-ip/ether.xml
index 47eca824..689a7fbc 100644
--- a/LDP/guide/docbook/linux-ip/ether.xml
+++ b/LDP/guide/docbook/linux-ip/ether.xml
@@ -146,8 +146,8 @@
 <computeroutput>tcpdump: listening on eth0
 0:80:c8:f8:4a:51 ff:ff:ff:ff:ff:ff 42: arp who-has 192.168.99.254 tell 192.168.99.35             <co id="ex-eao-request" linkends="ex-eao-request-text"/>
 0:80:c8:f8:5c:73 0:80:c8:f8:4a:51 60: arp reply 192.168.99.254 is-at 0:80:c8:f8:5c:73            <co id="ex-eao-reply" linkends="ex-eao-reply-text"/>
-0:80:c8:f8:4a:51 0:80:c8:f8:5c:73 98: 192.168.99.35 &gt; 192.168.99.254: icmp: echo request (DF) <co id="ex-eao-ip" linkends="ex-eao-ip-text"/>
-0:80:c8:f8:5c:73 0:80:c8:f8:4a:51 98: 192.168.99.254 &gt; 192.168.99.35: icmp: echo reply        <co id="ex-eao-ip2" linkends="ex-eao-ip-text"/></computeroutput>
+0:80:c8:f8:4a:51 0:80:c8:f8:5c:73 98: 192.168.99.35 &gt; 192.168.99.254: icmp: echo request (DF)    <co id="ex-eao-ip" linkends="ex-eao-ip-text"/>
+0:80:c8:f8:5c:73 0:80:c8:f8:4a:51 98: 192.168.99.254 &gt; 192.168.99.35: icmp: echo reply           <co id="ex-eao-ip2" linkends="ex-eao-ip-text"/></computeroutput>
         </programlisting>
         <calloutlist>
           <callout
@@ -659,28 +659,28 @@ Received 4 response(s)</computeroutput>
 <prompt>[root@real-server]# </prompt><userinput>ip address show dev eth1</userinput>
 <computeroutput>3: eth1: &lt;BROADCAST,MULTICAST,UP&gt; mtu 1500 qdisc pfifo_fast qlen 100
     link/ether 00:80:c8:7e:71:d4 brd ff:ff:ff:ff:ff:ff
-    inet 192.168.100.1/24 brd 192.168.100.255 scope global eth1</computeroutput> <co id="ex-eafa-server-setup" linkends="ex-eafa-server-setup-text"/>
+    inet 192.168.100.1/24 brd 192.168.100.255 scope global eth1</computeroutput>    <co id="ex-eafa-server-setup" linkends="ex-eafa-server-setup-text"/>
 <prompt>[root@real-client]# </prompt><userinput>arping -I eth0 -c 3 10.10.20.67</userinput>
 <computeroutput>ARPING 10.10.20.67 from 10.10.20.33 eth0
 Unicast reply from 10.10.20.67 [00:80:C8:E8:1E:FC]  0.882ms
 Unicast reply from 10.10.20.67 [00:80:C8:E8:1E:FC]  1.221ms
-Unicast reply from 10.10.20.67 [00:80:C8:E8:1E:FC]  1.487ms     </computeroutput><!-- gotta wrap the callout in tags so it's in the parent object --><co id="ex-eafa-expected" linkends="ex-eafa-expected-text"/><computeroutput>
+Unicast reply from 10.10.20.67 [00:80:C8:E8:1E:FC]  1.487ms        </computeroutput><!-- gotta wrap the callout in tags so it's in the parent object --><co id="ex-eafa-expected" linkends="ex-eafa-expected-text"/><computeroutput>
 Sent 3 probes (1 broadcast(s))
 Received 3 response(s)</computeroutput>
 <prompt>[root@real-client]# </prompt><userinput>arping -I eth0 -c 3 192.168.100.1</userinput>
 <computeroutput>ARPING 192.168.100.1 from 10.10.20.33 eth0
 Unicast reply from 192.168.100.1 [00:80:C8:E8:1E:FC]  0.877ms
 Unicast reply from 192.168.100.1 [00:80:C8:E8:1E:FC]  1.517ms
-Unicast reply from 192.168.100.1 [00:80:C8:E8:1E:FC]  1.661ms     </computeroutput><!-- gotta wrap the callout in tags so it's in the parent object --><co id="ex-eafa-problemzone" linkends="ex-eafa-problemzone-text"/><computeroutput>
+Unicast reply from 192.168.100.1 [00:80:C8:E8:1E:FC]  1.661ms      </computeroutput><!-- gotta wrap the callout in tags so it's in the parent object --><co id="ex-eafa-problemzone" linkends="ex-eafa-problemzone-text"/><computeroutput>
 Sent 3 probes (1 broadcast(s))
 Received 3 response(s)</computeroutput>
-<prompt>[root@real-client]# </prompt><userinput>ip neighbor del 192.168.100.1 dev eth0</userinput> <co id="ex-eafa-clearcache" linkends="ex-eafa-clearcache-text"/>
+<prompt>[root@real-client]# </prompt><userinput>ip neighbor del 192.168.100.1 dev eth0</userinput>         <co id="ex-eafa-clearcache" linkends="ex-eafa-clearcache-text"/>
 <prompt>[root@real-client]# </prompt><userinput>ip address add 192.168.100.2/24 brd + dev eth0</userinput> <co id="ex-eafa-newip" linkends="ex-eafa-newip-text"/>
 <prompt>[root@real-client]# </prompt><userinput>arping -I eth0 -c 3 192.168.100.1</userinput>
 <computeroutput>ARPING 192.168.100.1 from 192.168.100.2 eth0
 Unicast reply from 192.168.100.1 [00:80:C8:7E:71:D4]  0.804ms
 Unicast reply from 192.168.100.1 [00:80:C8:7E:71:D4]  1.381ms
-Unicast reply from 192.168.100.1 [00:80:C8:7E:71:D4]  2.487ms     </computeroutput><!-- gotta wrap the callout in tags so it's in the parent object --><co id="ex-eafa-workaround" linkends="ex-eafa-workaround-text"/><computeroutput>
+Unicast reply from 192.168.100.1 [00:80:C8:7E:71:D4]  2.487ms      </computeroutput><!-- gotta wrap the callout in tags so it's in the parent object --><co id="ex-eafa-workaround" linkends="ex-eafa-workaround-text"/><computeroutput>
 Sent 3 probes (1 broadcast(s))
 Received 3 response(s)</computeroutput>
           </programlisting>
diff --git a/LDP/guide/docbook/linux-ip/links.xml b/LDP/guide/docbook/linux-ip/links.xml
index b37fc7a4..cfe162d8 100644
--- a/LDP/guide/docbook/linux-ip/links.xml
+++ b/LDP/guide/docbook/linux-ip/links.xml
@@ -540,6 +540,21 @@
     <section id="links-misc">
       <title>Miscellaneous Linux IP Resources</title>
       <itemizedlist>
+        <listitem>
+          <para>
+            The <command>sysctl</command> utility is a convenient tool for
+            manipulating kernel parameters.  Combined with the
+            <filename>/etc/sysctl.conf</filename> this utility allows an
+            administrator to alter or tune kernel parameters in a convenient
+            fashion across a reboot.  See this
+            <ulink url="http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/ref-guide/s1-proc-sysctl.html">brief
+            RedHat page on the use of <command>sysctl</command></ulink>.  See
+            also
+            <ulink url="http://ipsysctl-tutorial.frozentux.net/">Oskar
+            Andreasson's IP Sysctl Tutorial</ulink> for a detailed examination
+            of the parameters and their affect on system operation.
+          </para>
+        </listitem>
         <listitem>
           <para>
             For users who need to provide a standards compliant VPN solution
diff --git a/LDP/guide/docbook/linux-ip/linux-ip.xml b/LDP/guide/docbook/linux-ip/linux-ip.xml
index a8264fdb..02d4139c 100644
--- a/LDP/guide/docbook/linux-ip/linux-ip.xml
+++ b/LDP/guide/docbook/linux-ip/linux-ip.xml
@@ -100,7 +100,7 @@
   <title>Concepts</title>
 
   &basic;                 <!-- chapter on basic IP connectivity -->
-  &devices;               <!-- chapter on the interfaces and devices -->
+  <!-- &interfaces;  -->  <!-- chapter on the interfaces and devices -->
   &ether;                 <!-- chapter on ARP, VLANs and bonding -->
   &bridging;              <!-- chapter on bridging -->
   &routing;               <!-- chapter on IP routing (static) -->
diff --git a/LDP/guide/docbook/linux-ip/nat.xml b/LDP/guide/docbook/linux-ip/nat.xml
index 2105a396..8999621a 100644
--- a/LDP/guide/docbook/linux-ip/nat.xml
+++ b/LDP/guide/docbook/linux-ip/nat.xml
@@ -190,6 +190,7 @@
       table.  For even modest machines, the connection tracking resource
       consumption should not be problematic.
     </para>
+    <!-- FIXME; next paragraph needs to be rewritten -->
     <para>
       Netfilter DNAT allows the user to select packets based on
       characteristics such as destination port.  This blurs the distinction
@@ -233,8 +234,9 @@
       </varlistentry>
       <varlistentry>
         <term>real IP</term>
-        <term>hidden IP</term>
         <term>server IP</term>
+        <term>hidden IP</term>
+        <term>private IP</term>
         <term>internal IP</term>
         <listitem>
           <para>
@@ -264,15 +266,40 @@
   <section id="nat-break">
    <title>Application Layer Protocols with Embedded Network Information</title>
     <para>
-      Some applications, FTP, H323, IRC?, use (check conntrack helpers) use
-      embedded network information inside the application layer protocol.
-      Introduce such problems, and how NAT confounds these protocols.
+      Network address translation is beautifully invisible when it works,
+      but has adverse effects on some protocols.
+      Some network applications, e.g., FTP, SNMP, H323, LDAP, IRC, make use of
+      embedded IP information in the application layer protocol or data
+      stream.  Since the 2.0.x kernel
+      series (which is not covered here), linux has supported modules which
+      inspect and manipulate packet contents on particular types of packets
+      when used with NAT or masquerading.
     </para>
     <para>
+      FTP is the classic example.  Within the FTP control channel
+      (usually established to destination port tcp/21) the client and the
+      server exchange IP address and port information.  If the network address
+      translation device doesn't manipulate this data, the FTP server will not
+      be able to contact the client to provide the data.
     </para>
     <para>
+      Passive mode FTP provides the possibility for a network layer which
+      requires only outbound TCP connections.  This results in a more NAT
+      friendly and firewall friendly protocol, because the connections are
+      initiated from the client.
     </para>
     <para>
+      Not only are there network applications which break when NAT is involved
+      but also network layer protocols.  IPSec is a standards-based
+      network-layer security protocol commonly used in VPNs and IPv6 networks.
+      There are many different ways to use IPSec, but, when used in AH
+      (Authentication Header) mode, NAT will break IPSec functionality.
+    </para>
+    <para>
+      This underscores the importance of determining if NAT is the best
+      solution for the problem.  There are kernel modules to help handle many
+      (though not all) of the application layer protocol when using NAT, but
+      some protocols, such as IPSec in AH mode simply cannot be used with NAT.
     </para>
   </section>
   <section id="nat-stateless">
@@ -281,7 +308,7 @@
       Stateless NAT, occasionally maligned as dumb NAT
       <footnote>
         <para>
-          In the kernel code tree, the stateless NAT, &iproute2; NAT can be
+          In the kernel code tree, stateless NAT, &iproute2; NAT can be
           located in the file <filename>net/ipv4/ip_nat_dumb.c</filename>.
           Even in the kernel, it has this reputation.
         </para>
@@ -331,219 +358,197 @@
       a certain range.  See <xref linkend="nat-stateless-rpdb"/>.
     </para>
     <section id="nat-stateless-simple">
-      <title>Simple Example</title>
+      <title>Stateless NAT Packet Capture and Introduction</title>
       <para>
-        We want to provide SMTP service on an IP in our outside network
-        (205.254.211.0/24) but we know that six months from now we are
-        going to be moving to a new network (65.211.43.0/24) and we don't
-        want to have to readdress our SMTP server then.  It's NAT to the
-        rescue.
-      </para>
-      <para>
-        We'll select an IP on the internal network (192.168.100.0/24) and
-        tell our router to accept packets for 205.254.211.17 and translate
-        this traffic to 192.168.100.17.  Let's take a look at the packet
-        as we accept the packet on our router's outside interface (eth1) and
-        again as we transmit the packet out the router's inside interface
-        (eth0).
+        Assume that example company in
+        <link linkend="ax-example-network">example network</link> wants to
+        provide SMTP service on a public IP (205.254.211.0/24) but plans to
+        move to a different IP addressing space in the near future.  Network
+        address translation can assist example company prepare for the move.
+        The administrator will select an IP on the internal network
+        (192.168.100.0/24) and configure the router to accept and translate 
+        packets for the publicly reachable IP into the private IP.
       </para>
       <example id="ex-nat-basic">
         <title>
-          NAT of public IP 205.254.211.17 to private IP 192.168.100.17
+          Stateless NAT Packet Capture
+          <footnote>
+            <para>
+              If you are having some difficulty understanding the
+              output of <command>tcpdump</command>, please see the
+              section on <link linkend="tools-tcpdump">tcpdump</link>.
+            </para>
+          </footnote>
         </title>
         <programlisting>
-<prompt>[root@masq-gw]# </prompt><userinput>tcpdump -q -n -n</userinput>
-<computeroutput>19:30:17.824853 eth1 &lt; 64.70.12.210.35131 &gt; 205.254.211.17.25: tcp 0 (DF)
-19:30:17.824976 eth0 &gt; 64.70.12.210.35131 &gt; 192.168.100.17.25: tcp 0 (DF)
-19:30:17.825400 eth0 &lt; 192.168.100.17.25 &gt; 64.70.12.210.35131: tcp 0 (DF)
-19:30:17.825568 eth1 &gt; 205.254.211.17.25 &gt; 64.70.12.210.35131: tcp 0 (DF)</computeroutput>
+<prompt>[root@masq-gw]# </prompt><userinput>tcpdump -qnn</userinput>
+<computeroutput>19:30:17.824853 eth1 &lt; 64.70.12.210.35131 &gt; 205.254.211.17.25: tcp 0 (DF)  <co id="ex-nb-public-in" linkends="ex-nb-public-in-text"/>
+19:30:17.824976 eth0 &gt; 64.70.12.210.35131 &gt; 192.168.100.17.25: tcp 0 (DF)  <co id="ex-nb-private-out" linkends="ex-nb-private-out-text"/>
+19:30:17.825400 eth0 &lt; 192.168.100.17.25 &gt; 64.70.12.210.35131: tcp 0 (DF)  <co id="ex-nb-private-in" linkends="ex-nb-private-in-text"/>
+19:30:17.825568 eth1 &gt; 205.254.211.17.25 &gt; 64.70.12.210.35131: tcp 0 (DF)  <co id="ex-nb-public-out" linkends="ex-nb-public-out-text"/></computeroutput>
         </programlisting>
+        <calloutlist>
+          <callout
+            arearefs="ex-nb-public-in"
+            id="ex-nb-public-in-text">
+              <simpara>
+                The first packet comes in on eth1, &masq-gw;'s
+                outside interface.  The packet is addressed to the NAT IP,
+                205.254.211.17 on tcp/25.  This is the IP/port pair on which
+                which our service runs.  This is a snapshot
+                of the packet before it has been handled by the NAT code.
+              </simpara>
+          </callout>
+          <callout
+            arearefs="ex-nb-private-out"
+            id="ex-nb-private-out-text">
+              <simpara>
+                The next line is the "same" packet leaving eth0, &masq-gw;'s
+                inside interface, bound for the internal network.
+                The NAT code has substituted the real IP of the server,
+                192.168.100.17.  This rewriting is handled by the
+                <constant>nat</constant> entry in the
+                <constant>local</constant> routing table (<userinput>ip
+                route</userinput>).  See also
+                <xref linkend="ex-nat-basic-commands"/>.
+              </simpara>
+          </callout>
+          <callout
+            arearefs="ex-nb-private-in"
+            id="ex-nb-private-in-text">
+              <simpara>
+                The SMTP server then sends a return packet which arrives on
+                eth0.  This is the packet before the NAT code on &masq-gw;
+                has rewritten the outbound packet.  This rewriting is handled
+                by the RPDB entry (<userinput>ip rule</userinput>).  See also
+                <xref linkend="ex-nat-basic-commands"/>.
+              </simpara>
+          </callout>
+          <callout
+            arearefs="ex-nb-public-out"
+            id="ex-nb-public-out-text">
+              <simpara>
+                Finally, the return packet is transmitted on eth1 after having
+                been rewritten.  The source IP address on the packet is now
+                the public IP on which the service is published.
+              </simpara>
+          </callout>
+        </calloutlist>
       </example>
       <para>
-        Let's examine each of the above packet details above to determine
-        what we are seeing
-        <footnote>
-          <para>
-            If you are having some difficulty understanding the
-            output of <command>tcpdump</command>, please see the
-            section on <link linkend="tools-tcpdump">tcpdump</link>.
-          </para>
-        </footnote>.
-        The first packet comes in on eth1 (masq-gw's
-        outside interface).  The packet is addressed to 205.254.211.17:25
-        which is the public IP on which our service runs.  This is a snapshot
-        of the packet before it has been handled by the NAT code.
       </para>
-      <para>
-<computeroutput>19:30:17.824853 eth1 &lt; 64.70.12.210.35131 &gt; 205.254.211.17.25: tcp 0 (DF)</computeroutput>
-      </para>
-      <para>
-        The next packet we see is the "same" packet leaving eth0 (masq-gw's
-        inside interface) bound for the internal network.  As you can see,
-        the NAT code has substituted the IP 192.168.100.17 for the
-        original destination IP.
-      </para>
-      <para>
-<computeroutput>19:30:17.824976 eth0 &gt; 64.70.12.210.35131 &gt; 192.168.100.17.25: tcp 0 (DF)</computeroutput>
-      </para>
-      <para>
-        The SMTP server then sends a packet back to us which comes in on
-        eth0.  This is before &masq-gw; has rewritten the outbound packet.
-      </para>
-      <para>
-<computeroutput>19:30:17.825400 eth0 &lt; 192.168.100.17.25 &gt; 64.70.12.210.35131: tcp 0 (DF)</computeroutput>
-      </para>
-      <para>
-        Finally, we see the return packet outbound on eth1 from the
-        public IP on which we have elected to publish the service.
-      </para>
-      <para>
-<computeroutput>19:30:17.825568 eth1 &gt; 205.254.211.17.25 &gt; 64.70.12.210.35131: tcp 0 (DF)</computeroutput>
-      </para>
-      <para>
-        Now that we have examined the general practice of NAT and looked at a
-        simple example of network address translation, we have the background
-        to begin looking at the tools available to perform NAT.
-      </para>
-      <section id="nat-stateless-howto">
-        <title>iproute2 NAT Practicum</title>
+    </section>
+    <section id="nat-stateless-howto">
+        <title>Stateless NAT Practicum</title>
         <para>
-          There are only a few commands which are required to enable NAT
-          on your linux routing device.
+          There are only a few commands which are required to enable stateless
+          NAT on a linux routing device.  The commands below will configure
+          the host &masq-gw; (see 
+          <xref linkend="example-network-netmap"/> and
+          <xref linkend="example-network-addressing"/>) as shown above in
+          <xref linkend="ex-nat-basic"/>.
         </para>
-        <para>
-          Refer to <xref linkend="ex-nat-basic"/> to see the result of the
-          following NAT configuration.  Our assumptions here are as follows:
-        </para>
-        <itemizedlist>
-          <listitem>
-            <para>
-              The machine &masq-gw; is connected to 205.254.211.0/24 on eth1.
-            </para>
-          </listitem>
-          <listitem>
-            <para>
-              The machine &masq-gw; is connected to 192.168.100.0/24 on eth0.
-            </para>
-          </listitem>
-          <listitem>
-            <para>
-              The machine &isolde; is listening on 192.168.100.17/24 on the
-              same media as eth0 of &masq-gw;.
-            </para>
-          </listitem>
-          <listitem>
-            <para>
-              The machine &isolde; uses &masq-gw; as its default gateway.
-            </para>
-          </listitem>
-          <listitem>
-            <para>
-            The machine &isolde; has a server running on port 25 (SMTP).
-              </para>
-          </listitem>
-        </itemizedlist>
-        <para>
+        <example id="ex-nat-basic-commands">
+          <title>Basic commands to create a stateless NAT</title>
           <programlisting>
-<prompt>[root@masq-gw]# </prompt><userinput>ip route add nat 205.254.211.17 via 192.168.100.17</userinput>
-<prompt>[root@masq-gw]# </prompt><userinput>ip rule add nat 205.254.211.17 from 192.168.100.17</userinput>
-<prompt>[root@masq-gw]# </prompt><userinput>ip route flush cache</userinput>
-<prompt>[root@masq-gw]# </prompt><userinput>ip route show table all | grep ^nat</userinput>
+<prompt>[root@masq-gw]# </prompt><userinput>ip route add nat 205.254.211.17 via 192.168.100.17</userinput>  <co id="ex-nbc-routenat" linkends="ex-nbc-routenat-text"/>
+<prompt>[root@masq-gw]# </prompt><userinput>ip rule add nat 205.254.211.17 from 192.168.100.17</userinput>  <co id="ex-nbc-rulenat" linkends="ex-nbc-rulenat-text"/>
+<prompt>[root@masq-gw]# </prompt><userinput>ip route flush cache</userinput>                                <co id="ex-nbc-flushcache" linkends="ex-nbc-flushcache-text"/>
+<prompt>[root@masq-gw]# </prompt><userinput>ip route show table all | grep ^nat</userinput>                 <co id="ex-nbc-routeshow" linkends="ex-nbc-routeruleshow-text"/>
 <computeroutput>nat 205.254.211.17 via 192.168.100.17  table local  scope host</computeroutput>
-<prompt>[root@masq-gw]# </prompt><userinput>ip rule show</userinput>
+<prompt>[root@masq-gw]# </prompt><userinput>ip rule show</userinput>                                        <co id="ex-nbc-ruleshow" linkends="ex-nbc-routeruleshow-text"/>
 <computeroutput>0:      from all lookup local 
 32765:  from 192.168.100.17 lookup main map-to 205.254.211.17 
 32766:  from all lookup main 
 32767:  from all lookup 253</computeroutput>
           </programlisting>
-        </para>
+          <calloutlist>
+            <callout
+              arearefs="ex-nbc-routenat"
+              id="ex-nbc-routenat-text">
+                <simpara>
+                  This command tells the kernel to perform network
+                  address translation on any packet bound for
+                  205.254.211.17.  The parameter via tells the NAT code
+                  to rewrite the packet bound for 205.254.211.17 with the
+                  new destination address 192.168.100.17.  Note, that this
+                  only handles inbound packets; that is, packets whose
+                  destination address contains 205.254.211.17.
+                </simpara>
+            </callout>
+            <callout
+              arearefs="ex-nbc-rulenat"
+              id="ex-nbc-rulenat-text">
+                <simpara>
+                  This command enters the corresponding rule for the
+                  outbound traffic into the RPDB (kernel 2.2 and up).
+                  This rule will cause the kernel rewrite any packet from
+                  192.168.100.17 with the specified source address
+                  (205.254.211.17).  Any packet originating from
+                  192.168.100.17 which passes through this router
+                  will trigger this rule.  In short, this command rewrites the
+                  source address of outbound packets so that they appear to
+                  originate from the NAT IP.
+                </simpara>
+            </callout>
+            <callout
+              arearefs="ex-nbc-flushcache"
+              id="ex-nbc-flushcache-text">
+                <simpara>
+                  The kernel maintains a routing cache to handle routing
+                  decisions more quickly
+                  (<xref linkend="routing-cache"/>).  After making changes
+                  to the routing tables on a system, it is good practice to
+                  empty the routing cache with <userinput>ip route flush
+                  cache</userinput>.  Once the cache is empty, the
+                  kernel is guaranteed to consult the routing tables again
+                  instead of the routing cache.
+                </simpara>
+            </callout>
+            <callout
+              arearefs="ex-nbc-routeshow ex-nbc-ruleshow"
+              id="ex-nbc-routeruleshow-text">
+                <simpara>
+                  These two commands allow the user to inspect the
+                  routing policy database and the <constant>local</constant>
+                  routing table to determine if the NAT routes and rules were
+                  added correctly.
+                </simpara>
+            </callout>
+          </calloutlist>
+        </example>
         <para>
-          Let's pause for a moment to examine what each of these commands
-          accomplishes.
         </para>
-        <programlisting>
-<prompt>[root@masq-gw]# </prompt><userinput>ip route add nat 205.254.211.17 via 192.168.100.17</userinput>
-        </programlisting>
+    </section>
+    <section id="nat-stateless-rpdb">
+        <title>Conditional Stateless NAT</title>
         <para>
-          This command tells the kernel to perform network address translation
-          on any packet bound for 205.254.211.17.  The parameter via tells the
-          NAT code to rewrite the packet bound for 205.254.211.17 with the new
-          destination address 192.168.100.17.  Note, that this only handles
-          inbound packets; that is, packets whose destination address contains
-          205.254.211.17.
-        </para>
-        <programlisting>
-<prompt>[root@masq-gw]# </prompt><userinput>ip rule add nat 205.254.211.17 from 192.168.100.17</userinput>
-        </programlisting>
-        <para>
-          This command instructs the routing policy database (kernel 2.2 and up)
-          to rewrite any packet from 192.168.100.17 with the source address
-          205.254.211.17.  this rule will be triggered by any packet passing
-          through this machine which originates from 192.168.100.17.  This
-          addresses the packets returning to the public network in our case.
-        </para>
-        <programlisting>
-<prompt>[root@masq-gw]# </prompt><userinput>ip route flush cache</userinput>
-        </programlisting>
-        <para>
-          The kernel maintains a routing cache to handle routing decisions more
-          quickly.  After making changes to the routes on a system, you'll
-          need to tell the cache to empty.  Once the cache is empty, the kernel
-          will again determine the best route by consulting the routing tables
-          (instead of the cache).
-        </para>
-        <programlisting>
-<prompt>[root@masq-gw]# </prompt><userinput>ip route show table all | grep nat</userinput>
-<prompt>[root@masq-gw]# </prompt><userinput>ip rule show</userinput>
-        </programlisting>
-        <para>
-          These two commands allow us to inspect the routing policy database and
-          the (main) routing table to determine if the routes and rules we added
-          appear as we expect.  If your output is similar to the output above,
-          you should be able to test to see if the linux routing device is
-          performing NAT for you.
-        </para>
-      </section>
-      <section id="nat-stateless-rpdb">
-        <title>&iproute2; NAT with Multiple Private
-          Networks</title>
-        <para>
-          Naturally, NAT introduces a complexity to the network in which it is
+          NAT introduces a complexity to the network in which it is
           used because a service is reachable on a public and a private IP.
-          Usually, this is a reasonable tradeoff or else you wouldn't select
-          NAT as the appropriate tool.  In the case that the linux routing
-          device is connected to a public network and more than one private
-          network, you have some extra work to do.
+          Usually, this is a reasonable tradeoff or else stateless NAT would
+          fail in the selection process.
+          In the case that the linux routing device is connected to a public
+          network and more than one private
+          network, there is more work to do.
         </para>
         <para>
-          Though you have made this service available to the public network on
-          a public IP, you may wish to have internal users connect to the service
-          on the internal IP.
-          In <xref linkend="ex-nat-basic"/>, you would not want users on the internal
-          network to reach the SMTP server on the public IP of the service, but
-          rather the private IP.
+          Though the service is available to the public network on
+          a public (NAT) IP, internal users may need to connect to the private
+          or internal IP.
         </para>
         <para>
           This is accomplished by use of the routing policy database (RPDB),
           which allows conditional routing based on packet characteristics.
           For a more complete explanation of the RPDB, see 
-          <xref linkend="adv-rpdb"/>.  The routing policy database can
+          <xref linkend="routing-rpdb"/>.  The routing policy database can
           be manipulated with the <link linkend="tools-ip-rule"><command>
-          ip rule</command></link> command.  In order to successfully
-          configure NAT, you need to have gained familiarity with the <command>
-          ip rule</command>, so this is a logical extension.
+          ip rule</command></link> command.
+          In order to successfully configure NAT, familiarity with the
+          <command> ip rule</command> command is required.
         </para>
-        <para>
-          The assumptions <link linkend="nat-stateless-howto">above</link> about
-          our host &masq-gw; are still valid.  Additionally, let's assume that
-          &masq-gw; is connected to
-          the internal network 192.168.99.0/24 on eth2.  In order to allow hosts
-          in this network to address 192.168.100.17 directly we'll have to
-          create an entry in the RPDB with a higher priority than the current
-          rule which handles all packets bound from 192.168.100.17 (and rewrites
-          them with a source address of 205.254.211.17).
-        </para>
-        <para>
+        <example id="ex-nat-stateless-rpdb">
+          <title>Conditional Stateless NAT (not performing NAT for a
+            specified destination network)</title>
           <programlisting>
 <prompt>[root@masq-gw]# </prompt><userinput>ip rule add to 192.168.99.0/24 from 192.168.100.17</userinput>
 <prompt>[root@masq-gw]# </prompt><userinput>ip route flush cache</userinput>
@@ -554,7 +559,7 @@
 32766:  from all lookup main 
 32767:  from all lookup 253</computeroutput>
           </programlisting>
-        </para>
+        </example>
         <para>
           Note that we now have an entry of higher priority in the RPDB
           for any packets returning from 192.168.100.17 bound for
@@ -585,7 +590,6 @@
           <link linkend="ex-sc-static-nat">configuration file</link>
           can ease the burden of managing a number of NAT IPs on your system.
         </para>
-      </section>
     </section>
   </section>
   <section id="nat-stateless-pf-interaction">
@@ -599,11 +603,11 @@
     </para>
     <para>
       All of the below requirements can be deduced from an understanding of
-      NAT and the kernel packet traveling diagram.  Consult the
+      NAT and the path a packet takes through the kernel.  Consult also the
       <ulink url="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO-4.html#ss4.1"><command>ipchains</command>
       packet path</ulink> as illustrated in the
       <ulink url="http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html"><command>ipchains</command>
-      HOWTO</ulink> to understand the packet path for kernels using
+      HOWTO</ulink> to understand the packet path when using
       <command>ipchains</command>.  Keep in mind when viewing the ASCII
       diagram that stateless NAT will always occur in the routing stage.  Also
       consult the
@@ -714,8 +718,8 @@
       #
       -->
     <example id="ex-nat-pf-ipchains">
-      <title>NAT of public IP 205.254.211.17 to private IP
-        192.168.100.17</title>
+      <title>Using an <command>ipchains</command> packet filter with
+        stateless NAT</title>
       <programlisting>
 <prompt>[root@masq-gw]# </prompt><userinput>ipchains -I input  -i eth1 -p tcp -l -y -s 0/0 1024:65535    -d 205.254.211.17 25 -j ACCEPT</userinput>
 <prompt>[root@masq-gw]# </prompt><userinput>ipchains -I input  -i eth1 -p tcp  ! -y -s 0/0 1024:65535    -d 205.254.211.17 25 -j ACCEPT</userinput>
diff --git a/LDP/guide/docbook/linux-ip/tools-diagnostics.xml b/LDP/guide/docbook/linux-ip/tools-diagnostics.xml
index db4b4114..94de4796 100644
--- a/LDP/guide/docbook/linux-ip/tools-diagnostics.xml
+++ b/LDP/guide/docbook/linux-ip/tools-diagnostics.xml
@@ -554,7 +554,7 @@ round-trip min/avg/max/mdev = 53.976/61.630/69.285/7.658 ms</computeroutput>
       <para>
         The tool <command>traceroute</command> is available on most Unix-like
         platforms and even under Windows as <command>tracert</command>.  Here,
-        we will only consider the common <command>traceroute</commmand>
+        we will only consider the common <command>traceroute</command>
         installed on linux systems.
       </para>
       <para>
diff --git a/LDP/guide/docbook/linux-ip/xsl/linux-ip-common.xsl b/LDP/guide/docbook/linux-ip/xsl/linux-ip-common.xsl
index 078ecd0d..328e62dd 100644
--- a/LDP/guide/docbook/linux-ip/xsl/linux-ip-common.xsl
+++ b/LDP/guide/docbook/linux-ip/xsl/linux-ip-common.xsl
@@ -8,6 +8,19 @@
 
 <xsl:param name="html.stylesheet" select="'linux-ip.css'"/>
 
+
+<!--
+  Tried chunk.tocs.and.lots, and got a main page with revision history
+  and abstract.  Not quite what I had hoped.
+
+  <xsl:param name="chunk.tocs.and.lots" select="1"/>
+
+  Appears to be used by the LDP stylesheets, on which this is based
+
+  <xsl:param name="chunk.first.sections" select="1"/>
+
+  -->
+
 <xsl:template match="ulink" name="ulink">
   <xsl:variable name="link">
     <a class="nonlocal">