It also refers to the seperate tunnel.o encapsulator, which doesn't exist
anymore. Since loading ipip.o creates the net devices tunl0, I have to
presume tunnel(or new_tunnel as it was called for a while) has been folded
into ipip.o
True?
And shouldn't we put the README.tunnel file back in as ipip under
~/Documentation/networking and correct Configure.help?
I have made the assumption that my above statements are true and have this
patch. Please correct me if I'm wrong ...
Index: Configure.help
===================================================================
RCS file: /usr/local/cvsroot/linux/Documentation/Configure.help,v
retrieving revision 2.1.119.1
diff -u -r2.1.119.1 Configure.help
--- Configure.help 1998/09/07 07:57:56 2.1.119.1
+++ Configure.help 1998/09/09 01:24:58
@@ -2147,11 +2147,10 @@
networks without changing their IP addresses; check out
http://anchor.cs.binghamton.edu/~mobileip/LJ/index.html).
- Saying Y to this option will produce two modules ( = code which can
- be inserted in and removed from the running kernel whenever you
- want), one encapsulator called tunnel.o and one decapsulator called
- ipip.o. You can read details in drivers/net/README.tunnel. Most
- people won't need this and can say N.
+ Saying Y to this option will produce the module ipip.o, which
+ contains both the encapsulator and decapsulator. You can read
+ details in Documentation/networking/ipip. Most people won't need
+ this and can say N.
IP: GRE tunnels over IP
CONFIG_NET_IPGRE
Index: networking/ipip
===================================================================
RCS file: ipip
diff -N ipip
--- /dev/null Wed Oct 22 11:48:18 1997
+++ ipip Tue Sep 8 21:24:58 1998
@@ -0,0 +1,117 @@
+
+This is the alpha version of my IPv4 tunneling driver.
+
+Protocol Tunneling:
+
+ A network tunneling driver encapsulates packets of one
+protocol type within packets of another protocol type. It sends
+them out over the network to a relay (or destination) where the
+packet is unwrapped and is forwarded to its ultimate destination.
+Packet tunneling is useful in situations where you want to route
+packets of a non-standard protocol type over the common network.
+A good example of this is 'IPX encapsulation', in which IPX packets
+from a DOS network are routed across an IPv4 network by encapsulating
+them in IPv4 packets.
+
+ There are two parts to every protocol tunnel. There is
+the encapsulator, and the decapsulator. The encapsulator wraps
+the packets in the host protocol and sends them on their way,
+while the decapsulator takes wrapped packets at the other end
+and unwraps them and forwards them (or whatever else should be
+done with them.)
+
+ IPv4 tunneling is a specific case of protocol tunneling,
+in which the encapsulating protocol is IP, and the encapsulated
+protocol may be any other protocol, including Apple-Talk, IPX,
+or even IPv4 within IPv4.
+
+ For more information on the semantics and specifications
+of IPv4 encapsulation, see RFC-1241, also included in this package.
+
+
+My Implementation:
+
+ My implementation of IPv4 tunneling for Linux consists
+of one loadable module driver, containing both the encapsulator
+and decapsulator (ipip.o). It used for setting up a working
+IPv4-in-IPv4 tunnel. Currently, the driver only support IPv4
+encapsulated in IP.
+
+ The tunnel driver is implemented as a network device,
+based on the Linux loopback driver written (in part) by Ross Biro,
+Fred N. van Kempen, and Donald Becker. After the driver is
+loaded, it can be set up as any other network interface, using
+ifconfig. The tunnel device is given its own IPv4 address, which
+can match that of the machine, and also is given a pointopoint
+address. This pointopoint address is the address of the machine
+providing the decapsulating endpoint for the IPv4 tunnel. After
+the device is configured for use, the 'route' command can be used
+to route traffic through the IPv4 tunnel. There must be a route to
+the decapsulating endpoint that does not go through the tunnel
+device, otherwise a looping tunnel is created, preventing the
+network traffic from leaving the local endpoint.
+
+ The decapsulating endpoint must have loaded the ipip.o
+decapsulator module for it to understand IPv4-in-IPv4 encapsulation.
+This module takes any IPv4-in-IPv4 packet that is destined for the
+local machine, unwraps it, and sends it on its way, using standard
+routing rules. The current implementation of IPv4 decapsulation does
+no checking on the packet, other than making sure wrapper is bound
+for the local machine.
+
+An example setup might be as follows.
+
+ Machine A has an ethernet interface with an IPv4 address
+of 111.112.101.37, while machine B is on a different network, with
+an ethernet interface at IPv4 address 111.112.100.86. For some
+reason, machine A needs to appear on machine B's network. It could
+do that by setting up an IPv4 tunnel with machine B.
+
+First, the commands that would be run on machine A:
+(Assuming both machines are Linux hosts, running Linux >1.1.x)
+
+# insmod ipip.o // Here the drivers are loaded.
+# ifconfig tunl0 111.112.100.87 pointopoint 111.112.100.86
+# ifconfig tunl0 netmask 255.255.255.0 // Set a proper netmask.
+# route add 111.112.100.86 dev eth0 // Set a static route to B.
+# route add -net 111.112.100.0 dev tunl0 // Set up other routes.
+
+At this point, machine A is ready to route all traffic to the
+network that machine B resides on. But now, machine B needs to
+set up its half of the IPv4 tunnel:
+
+# insmod ipip.o // Here the drivers are loaded.
+# ifconfig tunl0 111.112.100.86 pointopoint 111.112.101.37
+# ifconfig tunl0 netmask 255.255.255.0 // Set a proper netmask.
+# route add 111.112.100.87 dev eth0 // Set a static route to B.
+# arp -s 111.112.100.87 EE.EE.EE.EE.EE pub // Act as a proxy arp server.
+
+The extra step of "arp -s" is needed so that when machines on
+network B query to see if 111.112.100.87 (the "ghost" host)
+exists, machine B will respond, acting as an arp proxy for machine
+A. In the command line, EE.EE.EE.EE.EE should be replaced with
+the ethernet hardware address of machine B's ethernet card.
+
+Notice that machine B's setup is almost the inverse of machine A's
+setup. This is because IPv4 tunneling is a peer-to-peer concept.
+There is no client and no server, there is no state to keep track
+of. The concept is simple. Every IPv4 packet outbound through the
+tunnel interface is wrapped and sent to the pointopoint address
+and every incoming IPv4-in-IPv4 packet bound for the local machine is
+unwrapped and re-routed normally.
+
+The only difference in the two machines setup shown above is that
+machine A set its tunnel address to one existing on machine B's
+network, while B set a route to machine A's tunnel device address
+through the tunnel. This is because machine A wants to have a new
+address on network B, and machine B is simply acting as a proxy
+for machine A. Machine A needs its tunnel address to be on network
+B so that when packets from machine B are unwrapped, the Linux
+routing system knows that the address is a local one. Due to a
+feature of Linux, any packets received locally, bound for another
+local address, are simply routed through the loopback interface.
+This means that the tunnel device should never receive packets. Even
+on machine B, it is the ethernet interface that is receiving wrapped
+packets, and once they are unwrapped they go back out the ethernet
+interface. This could cause Linux to generate ICMP redirect messages
+if this special routing case isn't caught.
G'day!
-- n i c h o l a s j l e o n
/ elegance through simplicity /
/ good fortune through truth / http://mrnick.binary9.net
/ simplicity is elegant / mailto:nicholas@binary9.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html