From eb76f3d9a1bd02b8c400768397e7d9d92997759e Mon Sep 17 00:00:00 2001
From: Bart De Schuymer <bdschuym@pandora.be>
Date: Sun, 21 Jul 2002 13:05:03 +0000
Subject: *** empty log message ***

---
 docs/br_fw_ia/br_fw_ia.html | 61 ++++++++++++++++++++++-----------------------
 1 file changed, 30 insertions(+), 31 deletions(-)

diff --git a/docs/br_fw_ia/br_fw_ia.html b/docs/br_fw_ia/br_fw_ia.html
index 721fd39..cb51bd5 100644
--- a/docs/br_fw_ia/br_fw_ia.html
+++ b/docs/br_fw_ia/br_fw_ia.html
@@ -69,9 +69,15 @@
       <EM>Ebtables</EM> filters on the Ethernet layer, while <EM>iptables</EM>
       only filters IP packets.<BR>
       It is possible to use <EM>ebtables</EM> without compiling the br-nf
-      code into the kernel. The only reason why the <EM>ebtables</EM> patch
+      code into the kernel; and vice versa. The only reason why the <EM>ebtables</EM> patch
       has to be applied after the br-nf patch is because some files are
-      changed by both patches.
+      changed by both patches.<BR>
+      The explanations below will use the TCP/IP Network Model.
+      It should be noted that the br-nf patch 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,
+      while the word packet is used for the Network Layer. However, when we are talking about IP packets
+      inside the Link Layer, we will refer to these as frames/packets or packets/frames.
     </P>
     <A NAME="section2"></A>
     <P CLASS="section">
@@ -85,8 +91,7 @@
       First thing to keep in mind is that we are talking about
       the Ethernet layer here, so the OSI layer 2 (Data link
       layer), or layer 1 (Link layer, Network Access layer) by the TCP/IP Network
-      Model. All samples below will be explained according to the TCP/IP
-      Network Model.
+      Model.
     </P>
     <P>
       A packet destined for the local computer according to the
@@ -125,7 +130,7 @@
       process</I><BR>
     </P>
     <P>
-      <EM>Ebtables</EM> has three built in tables:
+      <EM>Ebtables</EM> has three tables:
       <B>filter</B>, <B>nat</B> and <B>broute</B>, as shown in Figure 2c.
     </P>
     <UL>
@@ -152,7 +157,7 @@
       <EM>ebtables</EM> chains are hooked into the bridge code.
     </P>
     <P>
-      When a NIC enslaved to a bridge receives a frame, the frame
+      When an NIC enslaved to a bridge receives a frame, the frame
       will first go through the BROUTING chain. In this special
       chain you can choose whether to route or bridge frames,
       enabling you to make a brouter. The definitions found on
@@ -184,7 +189,7 @@
       If the frame passes this chain, the bridging code will decide where the
       frame should be sent. The bridge does this by looking at
       the destination MAC address, it doesn't care about the
-      Network layer addresses (e.g. IP address).
+      Network Layer addresses (e.g. IP address).
     </P>
     <DIV CLASS="note">
       Incoming frames on non-forwarding ports of a bridge will
@@ -196,7 +201,7 @@
       computer, the frame will go through the INPUT chain.
       In this chain you can filter frames destined for the bridge box.
       After traversal of the INPUT chain, the frame will be passed up
-      to the Network layer code (e.g. to the IP code). 
+      to the Network Layer code (e.g. to the IP code).
       So, a routed IP packet will go through
       the <EM>ebtables</EM> INPUT chain, not through the
       <EM>ebtables</EM> FORWARD chain. This is logical.
@@ -319,6 +324,7 @@
       physical interface (simplistic view)</I><BR>
     </P>
     <P>
+      Figures 3c and 3d assume the IP packet arrived on a bridge port.
       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
@@ -355,7 +361,11 @@
       This is at the same place as where the <EM>ebtables</EM> nat
       PREROUTING chain will be traversed (for the same reason).
       This should explain the asymmetry encountered in Figures 3c
-      and 3d.
+      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>.
     </P>
     <A NAME="section5"></A>
     <P CLASS="section">
@@ -363,7 +373,7 @@
     </P>
     <P>
       A bridged packet never enters any network code above layer
-      1 (Link layer). So, a bridged IP packet/frame will never enter the
+      1 (Link Layer). So, a bridged IP packet/frame will never enter the
       IP code.
       Therefore all <EM>iptables</EM> chains will be traversed
       while the IP packet is in the bridge code. The chain
@@ -399,11 +409,11 @@
     <P>
       To make this possible the <EM>iptables</EM> chains have to
       be traversed after the bridge code decided where the frame
-      needs to be sent (eth0, eth1, both or none). This has some
+      needs to be sent (eth0, eth1 or both). This has some
       impact on the scheme presented in <A HREF=
       "#section3">section 3</A> (so, we are looking at routed
-      traffic here). It actually looks like this (in the case of
-      Figure 3c):
+      traffic here, entering the box on a bridge port). It actually
+      looks like this (in the case of Figure 3c):
     </P>
     <P>
       <IMG SRC="bridge6a.png">
@@ -442,14 +452,14 @@
       <EM>iptables</EM> nat OUTPUT chain):
     </P>
     <P>
-      The 'normal' way locally generated packets would go through
+      The normal way locally generated packets would go through
       the chains looks like this:
     </P>
     <P>
       <IMG SRC="bridge6c.png">
     </P>
     <P>
-      <I><B>Figure 6c.</B> The 'normal' way for locally generated
+      <I><B>Figure 6c.</B> The normal way for locally generated
       packets</I><BR>
     </P>
     <P>
@@ -460,28 +470,17 @@
       <IMG SRC="bridge6d.png">
     </P>
     <P>
-      <I><B>Figure 6d.</B> The 'actual' way for locally generated
+      <I><B>Figure 6d.</B> The actual way for locally generated
       packets</I><BR>
     </P>
     <P>
       Note that the <EM>iptables</EM> nat OUTPUT chain is traversed while the
-      packet is in the IP code, while the <EM>iptables</EM> filter OUTPUT chain
-      is traversed when the packet has entered the bridge code.
+      packet is in the IP code and the <EM>iptables</EM> filter OUTPUT chain
+      is traversed when the packet has passed the bridging decision.
       This makes it possible to do DNAT to another device in the
       nat OUTPUT chain and lets us use the bridge ports in the
       filter OUTPUT chain.
     </P>
-    <P>
-      Note that in Figures 6a and 6d the <EM>iptables</EM>
-      POSTROUTING chain is traversed before the <EM>ebtables</EM>
-      POSTROUTING chain, while it's the way around for Figure 5.
-      The rule is as follows:
-    </P>
-    <DIV CLASS="note">
-      for bridged traffic the <EM>ebtables</EM> POSTROUTING chain
-      is traversed before the <EM>iptables</EM> POSTROUTING chain,
-      for all other traffic it's the way around.
-    </DIV>
     <A NAME="section7"></A>
     <P CLASS="section">
       7. Two possible ways for frames/packets to pass through the
@@ -516,7 +515,7 @@
       More details:
     </P>
     <P>
-      The idea is that traffic between 172.16.1.4 and 172.16.2 is
+      The idea is that traffic between 172.16.1.4 and 172.16.1.2 is
       bridged, while the rest is routed, using masquerading.
     </P>
     <P>
@@ -627,7 +626,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 July 9, 2002.
+      Last updated July 21, 2002.
     </P>
   </BODY>
 </HTML>
-- 
cgit v1.2.3