NAME | SYNOPSIS | DESCRIPTION | ATTRIBUTES | SEE ALSO | BUGS
pseudo-device gif [count]
The gif() interface is a generic tunneling pseudo device for IPv4 and IPv6. It can tunnel IPv[46] traffic over IPv[46]. Therefore, there can be four possible configurations. The behavior of gif() is mainly based on RFC1933 IPv6-over-IPv4 configured tunnel.
To use gif(), the administrator needs to configure protocol and addresses used for the outer header. This can be done by using gifconfig(1M), or SIOCSIFPHYADDR ioctl. Also, the administrator needs to configure protocol and addresses used for the inner header, by using ifconfig(1M). Note that IPv6 link-local addresses (those that start with fe80::) will be automatically configured whenever possible. You may need to remove IPv6 link-local addresses manually using ifconfig(1M), when you want to disable the use of IPv6 as inner header (like when you need a pure IPv4-over-IPv6 tunnel). Finally, use the routing table to route the packets toward the gif() interface.
The gif() interface can be configured to perform a bidirectional or multi- destination tunnel. This is controlled by the IFF_LINK0 interface flag. Also, gif() can be configured to be ECN friendly. This can be configured by IFF_LINK1.
Usually, gif() implements a bidirectional tunnel. The gifconfig(1M) interface should configure a tunnel ingress point (this node) and an egress point (tunnel endpoint). One gif() interface will tunnel to only a single tunnel endpoint, and accept from only a single tunnel endpoint. The source and destination address for the outer IP header is always the ingress and the egress point configured by gifconfig(1M).
With the IFF_LINK0 interface flag, gif() can be configured to implement a multi- destination tunnel. With IFF_LINK0, it is able to configure an egress point to an IPv4 wildcard address (0.0.0.0) or to an IPv6 unspecified address (0::0). In this case, the destination address for the outer IP header is determined by the routing table setup. Therefore, one gif() interface can tunnel to multiple destinations. Also, gif() will accept tunneled traffic from any outer source address.
When finding a gif() interface from the inbound tunneled traffic, the bidirectional mode interface is preferred to the multi-destination mode interface. For example, if you have the following three gif() interfaces on node A,
bidirectional, A to B
bidirectional, A to C
multi-destination, A to any
Please note that the multi-destination mode is far less secure than the bidirectional mode. The multi-destination mode gif() can accept tunneled packets from anybody, and can be attacked from a malicious node.
The gif() interface can be configured to be ECN friendly, as described in draft-ietf-ipsec-ecn-02.txt. This is turned off by default, and can be turned on by the IFF_LINK1 interface flag.
Without IFF_LINK1, gif() will behave normally, as described in RFC1933. This can be summarized as follows:
Set outer TOS bit to 0
Drop outer TOS bit
With IFF_LINK1, gif() will copy ECN bits (0x02 and 0x01 on IPv4 TOS byte or IPv6 traffic class byte) on egress and ingress, as follows:
Copy TOS bits except for ECN CE (masked with 0xfe) from inner to outer. Set ECN CE bit to 0
Use inner TOS bits with some change. If outer ECN CE bit is 1, enable ECN CE bit on the inner
Note that the ECN friendly behavior violates RFC1933. This should be used in agreement with the peer.
A malicious party may try to circumvent security filters by using tunneled packets. For better protection, gif() performs martian filter and ingress filter against outer source address, on egress. Note that martian/ingress filters are incomplete. You may want to secure your node by using packet filters.
As mentioned above, the multi-destination mode (IFF_LINK0) is far less secure than the bidirectional mode.
See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPE | ATTRIBUTE VALUE |
---|---|
Interface Stability | Evolving |
There are many tunneling protocol specifications, defined differently from each other. The gif() interface 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 that you 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.
The gif() interface is an IFF_POINTOPOINT device. However, it supports NBMA behavior in multi-destination mode.
NAME | SYNOPSIS | DESCRIPTION | ATTRIBUTES | SEE ALSO | BUGS