generic tunnel interface
interface is a generic tunnelling
pseudo-device for IPv4 and IPv6. It can tunnel IPv over IPv with
behavior mainly based on RFC 4213 IPv6-over-IPv4, for a total of four possible
combinations. When instead used as a member in a
, it will
tunnel Ethernet packets over IPv using RFC 3378 EtherIP encapsulation
(version 3), providing two more combinations.
interface can be created at runtime
command or by setting up a
configuration file for
For all six modes the
interface must be
configured with the addresses used for the outer header. This can be done by
command (which uses the
For the IPv over IPv modes the addresses of the inner header must be
configured by using
normal way. Note that IPv6 link-local address (those start with
) will be automatically configured whenever
possible. One may need to remove any IPv6 link-local address manually using
disable the use of IPv6 as inner header, for example when a pure
IPv4-over-IPv6 tunnel is required. The routing table can be used to direct
packets toward the
For the Ethernet-over-IP modes the
interface must be made a member of a
must be set to 1,
being used to protect the traffic. Ethernet frames are then encapsulated and
sent across the network to another
decapsulates the datagram and processes the resulting Ethernet frame as if it
had originated on a normal Ethernet interface. This effectively allows a layer
2 network to be extended from one point to another, possibly through the
Internet. This mechanism may be used in conjunction with IPsec by specifying
the appropriate IPsec flows between the two bridges. To only protect the
bridge traffic between the two bridges, the transport protocol 97 (etherip)
selector may be used in
Otherwise, the Ethernet frames will be sent in the clear between the two
Given two physically separate Ethernet networks, a bridge can be used as follows
to make them appear as the same local area network. If bridge1 on network1 has
the external IP address 126.96.36.199 on fxp0, bridge2 on network2 has the external
IP address 188.8.131.52 on fxp0, and both bridges have fxp1 on their internal
network (network1 and network2, respectively), the following configuration can
be used to bridge network1 and network2.
First create the bridge interface, adding the encapsulation interface and
internal Ethernet interface to the bridge interface:
# ifconfig bridge0 add gif0 add fxp1
Create and configure the gif0 interface:
(on bridge 1) # ifconfig gif0 tunnel 184.108.40.206 220.127.116.11
(on bridge 2) # ifconfig gif0 tunnel 18.104.22.168 22.214.171.124
Create Security Associations (SAs) between the external IP address of each
bridge and matching ingress flows by using the following
file on bridge1:
esp from 126.96.36.199 to 188.8.131.52 spi 0x4242:0x4243 \
authkey file "auth1:auth2" enckey file "enc1:enc2"
flow esp proto etherip from 184.108.40.206 to 220.127.116.11
Now load these rules into the kernel by issuing the
esp from 18.104.22.168 to 22.214.171.124 spi 0x4243:0x4242 \
authkey file "auth2:auth1" enckey file "enc2:enc1"
flow esp proto etherip from 126.96.36.199 to 188.8.131.52
And load them:
To use dynamic (as opposed to static) keying, use this
ike esp proto etherip from 184.108.40.206 to 220.127.116.11
And on bridge2:
ike esp proto etherip from 18.104.22.168 to 22.214.171.124
Bring up the internal interface (if not already up) and encapsulation interface:
# ifconfig fxp1 up
# ifconfig gif0 up
Finally, bring the bridge interface up and allow it to start processing frames:
# ifconfig bridge0 up
The internal interface on each bridge need not have an IP address: the bridge
can function without it.
Note: It is possible to put the above commands in the
files, using the ‘!’ operator.
R. Housley and
S. Hollenbeck, EtherIP: Tunneling
Ethernet Frames in IP Datagrams, RFC 3378,
E. Nordmark and
R. Gilligan, Basic Transition
Mechanisms for IPv6 Hosts and Routers, RFC
4213, October 2005.
device first appeared in WIDE
hydrangea IPv6 kit.
There are many tunnelling protocol specifications, defined differently from each
may not interoperate with peers
which are based on different specifications, and are picky about outer header
fields. For example, you cannot usually use
to talk with IPsec devices that use
IPsec tunnel mode.
The current code does not check if the ingress address (outer source address)
makes sense. Make sure to
configure an address which belongs to your node. Otherwise, your node will not
be able to receive packets from the peer, and your node will generate packets
with a spoofed source address.
If the outer protocol is IPv6, path MTU discovery for encapsulated packet may
affect communication over the interface.
When used in conjunction with a
only one bridge tunnel may be operational for every pair of source/destination
addresses. If more than one
is configured with the same pair of outer addresses, the one with the lowest
index number will receive all traffic.