NAME
gif
—
generic tunnel interface
SYNOPSIS
pseudo-device gif
DESCRIPTION
The gif
interface is a generic tunnelling
pseudo-device for IPv4 and IPv6. It can tunnel IPv[46] over IPv[46] 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
bridge(4), it will tunnel Ethernet packets over IPv[46] using RFC
3378 EtherIP encapsulation (version 3), providing two more combinations.
A gif
interface can be created at runtime
using the ifconfig gif
N
create
command or by setting up a
hostname.if(5) configuration file for
netstart(8).
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 SIOCSIFPHYADDR
ioctl).
For the IPv[46] over IPv[46] 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 gif
interface.
For the Ethernet-over-IP modes the gif
interface must be made a member of a
bridge(4). The
sysctl(3) variable 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
ipsec.conf(5). Otherwise, the Ethernet frames will be sent in
the clear between the two bridges.
EXAMPLES
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 1.2.3.4 on fxp0, bridge2 on network2 has the external IP address 4.3.2.1 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 1.2.3.4 4.3.2.1 (on bridge 2) # ifconfig gif0 tunnel 4.3.2.1 1.2.3.4
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 1.2.3.4 to 4.3.2.1 spi 0x4242:0x4243 \ authkey file "auth1:auth2" enckey file "enc1:enc2" flow esp proto etherip from 1.2.3.4 to 4.3.2.1
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 4.3.2.1 to 1.2.3.4 spi 0x4243:0x4242 \ authkey file "auth2:auth1" enckey file "enc2:enc1" flow esp proto etherip from 4.3.2.1 to 1.2.3.4
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 1.2.3.4 to 4.3.2.1
And on bridge2:
ike esp proto etherip from 4.3.2.1 to 1.2.3.4
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 hostname.if(5) files, using the ‘!’ operator.
SEE ALSO
sysctl(3), bridge(4), inet(4), inet6(4), ipsec(4), hostname.if(5), ifconfig(8), netstart(8)
STANDARDS
R. Housley and S. Hollenbeck, EtherIP: Tunneling Ethernet Frames in IP Datagrams, RFC 3378, September 2002.
E. Nordmark and R. Gilligan, Basic Transition Mechanisms for IPv6 Hosts and Routers, RFC 4213, October 2005.
HISTORY
The gif
device first appeared in WIDE
hydrangea IPv6 kit.
BUGS
There are many tunnelling protocol specifications, defined
differently from each other. gif
may not
interoperate with peers which are based on different specifications, and are
picky about outer header fields. For example, you cannot usually use
gif
to 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.