|GIF(4)||Device Drivers Manual||GIF(4)|
gifinterface is a generic tunnelling pseudo-device for IPv4 and IPv6. It can tunnel IPv over IPv with behavior mainly based on RFC 1933 IPv6-over-IPv4, for a total of four possible combinations. When instead used as a member in a bridge(4), it will tunnel Ethernet packets over IPv using RFC 3378 EtherIP encapsulation (version 3), providing two more combinations.
For all six modes the
gif interface must
be configured with the addresses used for the outer header. This can be done
by using ifconfig(8)'s
tunnel command (which uses the
For the IPv over IPv modes the addresses of the inner
header must be configured by using
ifconfig(8) in the normal
way. Note that IPv6 link-local address (those start with
fe80::) will be automatically configured whenever
possible. One may need to remove any IPv6 link-local address manually using
ifconfig(8), to 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
net.inet.etherip.allow must be set to 1, unless
ipsec(4) is being used to
protect the traffic. Ethernet frames are then encapsulated and sent across
the network to another
bridge(4), which 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
the Ethernet frames will be sent in the clear between the two bridges.
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 188.8.131.52 184.108.40.206 (on bridge 2) # ifconfig gif0 tunnel 220.127.116.11 18.104.22.168
Create Security Associations (SAs) between the external IP address of each bridge and matching ingress flows by using the following ipsec.conf(5) file on bridge1:
esp from 22.214.171.124 to 126.96.36.199 spi 0x4242:0x4243 \ authkey file "auth1:auth2" enckey file "enc1:enc2" flow esp proto etherip from 188.8.131.52 to 184.108.40.206
Now load these rules into the kernel by issuing the ipsecctl(8) command:
# ipsecctl -f ipsec.conf
Appropriate ipsec.conf(5) for bridge2:
esp from 220.127.116.11 to 18.104.22.168 spi 0x4243:0x4242 \ authkey file "auth2:auth1" enckey file "enc2:enc1" flow esp proto etherip from 22.214.171.124 to 126.96.36.199
And load them:
# ipsecctl -f ipsec.conf
To use dynamic (as opposed to static) keying, use this ipsec.conf(5) on bridge1:
ike esp proto etherip from 188.8.131.52 to 184.108.40.206
And on bridge2:
ike esp proto etherip from 220.127.116.11 to 18.104.22.168
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 link2
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 hostname.if(5) files, using the ‘!’ operator.
R. Gilligan and E. Nordmark, Transition Mechanisms for IPv6 Hosts and Routers, RFC 1933, April 1996.
R. Housley and S. Hollenbeck, EtherIP: Tunneling Ethernet Frames in IP Datagrams, RFC 3378, September 2002.
gifdevice first appeared in WIDE hydrangea IPv6 kit.
gifmay not interoperate with peers which are based on different specifications, and are picky about outer header fields. For example, you cannot usually use
gifto talk with IPsec devices that use IPsec tunnel mode.
The current code does not check if the ingress address (outer
source address) configured to
gif 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
bridge(4) interface, only one
bridge tunnel may be operational for every pair of source/destination
addresses. If more than one
gif interface is
configured with the same pair of outer addresses, the one with the lowest
index number will receive all traffic.
|December 3, 2011||OpenBSD-5.1|