include fact that it's in 2.5

1 files changed, 32 insertions, 52 deletions

diff --git a/docs/br_fw_ia/br_fw_ia.html b/docs/br_fw_ia/br_fw_ia.html
index 6b05d50..f338d50 100644
--- a/docs/br_fw_ia/br_fw_ia.html
+++ b/docs/br_fw_ia/br_fw_ia.html
@@ -66,14 +66,14 @@
       This document describes how <EM>iptables</EM> and
       <EM>ebtables</EM> filtering tables interact on a Linux-based bridge.<BR>
       Getting a bridging firewall consists of patching the kernel source
-      code with one or two patches.
-      Kernels 2.5.39 and above only need the "br-nf-bds" patch, since ebtables has been integrated in the 2.5.x series.
-      For other kernels, you need to first apply the patch that adds <EM>ebtables</EM> support in the kernel.
-      The "br-nf-bds" patch makes bridged IP frames/packets go through the <EM>iptables</EM> chains.
+      code with one or two patches. Since kernel 2.5.39 (resp. 2.5.44), <EM>ebtables</EM> (resp. <EM>br-nf</EM>)
+      is in the standard 2.5 kernel releases.
+      Because the demand was high, patches for the 2.4 kernel are still available at the <EM>ebtables</EM> homepage.
+      The <EM>br-nf</EM> code makes bridged IP frames/packets go through the <EM>iptables</EM> chains.
       <EM>Ebtables</EM> filters on the Ethernet layer, while <EM>iptables</EM>
       only filters IP packets.<BR>
       The explanations below will use the TCP/IP Network Model.
-      It should be noted that the br-nf-bds patch sometimes violates the
+      It should be noted that the <EM>br-nf</EM> code sometimes violates the
       TCP/IP Network
       Model. As will be seen later, it is possible, f.e., to do IP DNAT inside the Link Layer.<BR>
       We want to note that we are perfectly well aware that the word frame is used for the Link Layer,
@@ -111,8 +111,8 @@
     <P>
     </P>
     <P>
-      There are five hooks defined in the Linux bridging code.
-      The sixth hook (BROUTING) is added by the <EM>ebtables</EM> patch.
+      There are six hooks defined in the Linux bridging code, of which the
+      BROUTING hook was added for <EM>ebtables</EM>.
     </P>
     <BR>
      <BR>
@@ -251,7 +251,7 @@
       decision, so this is actually too late. We should change this. The nat
       POSTROUTING chain is the same one as described above.
     </P>
-		<BR>
+     <BR>
      <BR>
      <IMG SRC="bridge2f.png">
     <P>
@@ -289,23 +289,25 @@
       Note that the iptables nat OUTPUT chain is situated after the
       routing decision. As commented in the previous section,
       this is too late for DNAT. This is solved by rerouting the
-      IP packet if it has been DNAT'ed, before continuing.
+      IP packet if it has been DNAT'ed, before continuing. For clarity:
+      this is standard behaviour of the Linux kernel, not something
+      caused by our code.
     </P>
     <P>
       Figures 3a and 3b give a clear view where the
       <EM>iptables</EM> chains are attached onto the IP hooks. When the
-      br-nf-bds patch is compiled into the kernel, the iptables chains are
+      bridge code and netfilter is enabled in the kernel, the iptables chains are
       also attached onto the hooks of the bridging code. However,
       this does not mean that they are no longer attached onto their
       standard IP code hooks. For IP packets that get into
-      contact with the bridging code, the br-nf-bds patch will
+      contact with the bridging code, the <EM>br-nf</EM> code will
       decide in which place in the network code the <EM>iptables</EM>
-      chains are traversed. Obviously, it is guaranteed that no chain is
+      chains will be traversed. Obviously, it is guaranteed that no chain is
       traversed twice by the same packet. All packets that do not come into
       contact with the bridge code traverse the <EM>iptables</EM> chains
       in the standard way as seen in Figure 3b.<BR>
       The following sections try, among other things,
-      to explain what the br-nf-bds patch does and why it does it.
+      to explain what the <EM>br-nf</EM> code does and why it does it.
     </P>
     <P>
       It's possible to see a single IP packet/frame traverse the
@@ -315,8 +317,7 @@
       The Ethernet frame(s) containing that IP packet will have
       the bridge's destination MAC address, while the destination
       IP address is not of the bridge. Including the
-      <EM>iptables</EM> chains and assuming the br-nf-bds code is
-      compiled into the kernel, this is how the IP packet runs
+      <EM>iptables</EM> chains, this is how the IP packet runs
       through the bridge/router (actually there is more going on,
       see <A HREF="#section6">section 6</A>):
     </P>
@@ -344,7 +345,7 @@
       What is obviously "asymmetric" here is that the
       <EM>iptables</EM> PREROUTING chain is traversed before the
       <EM>ebtables</EM> INPUT chain, however this cannot be
-      helped without sacrificing other functionality. See the
+      helped without sacrificing functionality. See the
       next section.
     </P>
     <A NAME="section4"></A>
@@ -352,7 +353,7 @@
       4. DNAT'ing bridged packets
     </P>
     <P>
-      Take an IP packet received by the bridge. Let's assume we 
+      Take an IP packet received by the bridge. Let's assume we
       want to do some IP DNAT on it.
       Changing the destination address of the packet (IP address
       and MAC address) has to happen before the bridge code
@@ -366,9 +367,9 @@
       This should explain the asymmetry encountered in Figures 3c
       and 3d.<BR>
       One should also be aware of the fact that frames for which the
-      bridging decision would be the fourth from the above list will
-      be seen in the PREROUTING chains of <EM>ebtables</EM> and
-      <EM>iptables</EM>.
+      bridging decision would be the fourth from the above list (i.e.
+      ignore the frame) will be seen in the PREROUTING chains of
+      <EM>ebtables</EM> and <EM>iptables</EM>.
     </P>
     <A NAME="section5"></A>
     <P CLASS="section">
@@ -402,7 +403,7 @@
       knowing when a box on the eth0 side changes its source IP
       address to that of a box on the eth1 side, except by
       looking at the MAC source address (and then still...). With
-      the br-nf-bds patch you can use eth0 and eth1 in your
+      the <EM>br-nf</EM> code you can use eth0 and eth1 in your
       <EM>iptables</EM> rules and therefore catch these attempts.
     </P>
     <P CLASS="case">
@@ -422,34 +423,15 @@
       <IMG SRC="bridge6a.png">
     </P>
     <P>
-      <I><B>Figure 6a.</B> Chain traversal when routing and br-nf-bds
-      is compiled into the kernel</I><BR>
+      <I><B>Figure 6a.</B> Chain traversal for routing, when the bridge
+      and netfilter code are compiled in the kernel.</I><BR>
     </P>
     <DIV CLASS="note">
       All chains are now traversed while in the bridge code.<BR>
-      This is the work of the br-nf-bds patch. Obviously this does not
+      This is the work of the <EM>br-nf</EM> code. Obviously this does not
       mean that the routed IP packets never enter the IP code. They
       just don't pass any <EM>iptables</EM> chains while in the IP code.
     </DIV>
-    <P>
-      If one does not compile the br-nf-bds code into the kernel, the
-      chains will be traversed as shown below. However, then one
-      can only use br0, not eth0/eth1 to filter.
-    </P>
-    <P>
-      <IMG SRC="bridge6b.png">
-    </P>
-    <P>
-      <I><B>Figure 6b.</B> Chain traversal when routing and br-nf-bds
-      code is not compiled into the kernel</I><BR>
-    </P>
-    <P>
-      Notice that the <EM>iptables</EM> PREROUTING chain is now in
-      the natural position in the chain list and too far to be able
-      to change the bridging decision. More precise: the <EM>iptables</EM>
-      PREROUTING chain is now traversed when the packet is already
-      in the IP code.
-    </P>
     <P CLASS="case">
       6.2. IP DNAT for locally generated packets (so in the
       <EM>iptables</EM> nat OUTPUT chain):
@@ -467,7 +449,7 @@
     </P>
     <P>
       From <A HREF="#section6">section 6.1</A> we know that this
-      actually looks like this (due to the br-nf-bds code):
+      actually looks like this (due to the <EM>br-nf</EM> code):
     </P>
     <P>
       <IMG SRC="bridge6d.png">
@@ -491,7 +473,7 @@
       chains
     </P>
     <P>
-      With the br-nf-bds patch there are 2 ways a frame/packet can
+      Because of the <EM>br-nf</EM> code, there are 2 ways a frame/packet can
       pass through the 3 given <EM>iptables</EM> chains. The
       first way is when the frame is bridged, so the
       <EM>iptables</EM> chains are called by the bridge code. The
@@ -548,7 +530,7 @@ echo '1' &gt; /proc/sys/net/ipv4/ip_forward
     <P>
       The catch is in the first line. Because the
       <EM>iptables</EM> code gets executed for both bridged
-      packets and routed packets we need to make a distinction
+      packets and routed packets, we need to make a distinction
       between the two. We don't really want the bridged frames/packets
       to be masqueraded. If we omit the first line then
       everything will work too, but things will happen
@@ -587,8 +569,8 @@ echo '1' &gt; /proc/sys/net/ipv4/ip_forward
       9. Using the MAC module extension for <EM>iptables</EM>
     </P>
     <P>
-      The side effect explained here occurs when the br-nf-bds code
-      is compiled in the kernel, the IP packet is routed and the
+      The side effect explained here occurs when the netfilter code
+      is enabled in the kernel, the IP packet is routed and the
       out device for that packet is a logical bridge device. The
       side effect is encountered when filtering on the MAC source
       in the <EM>iptables</EM> FORWARD chains. As should be clear
@@ -607,9 +589,7 @@ echo '1' &gt; /proc/sys/net/ipv4/ip_forward
       to filter on the real MAC source address in the FORWARD
       chains would involve a very dirty hack and is probably not
       worth it. This of course makes the anti-spoofing remark of
-      <A HREF="#section5">section 6</A> funny. If I'm [BDS]
-      pressured enough I could hack something up to make this
-      unpleasant side effect go away.
+      <A HREF="#section6">section 6</A> funny.
     </P>
     <A NAME="section10"></A>
     <P CLASS="section">
@@ -641,7 +621,7 @@ Copyright (c) 2002 Bart De Schuymer &lt;bart.de.schuymer@pandora.be&gt;,
     "http://www.gnu.org/licenses/fdl.txt">"GNU Free Documentation License"</A>.</SMALL> <BR>
      <BR>
     <P>
-      Last updated November 03, 2002.
+      Last updated December 23, 2002.
     </P>
   </BODY>
 </HTML>