gif(4)
- NetBSD Manual Pages
GIF(4) NetBSD Programmer's Manual GIF(4)
NAME
gif - Generic tunnel network device
SYNOPSIS
pseudo-device gif [count]
DESCRIPTION
The gif interface is a generic tunnelling 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, administrator needs to configure protocol and addresses used
for the outer header. This can be done by using ifconfig(8) `tunnel'
subcommand, or SIOCSIFPHYADDR ioctl. Also, administrator needs to con-
figure protocol and addresses used for the inner header, by using
ifconfig(8). Note that IPv6 link-local address (those start with fe80::)
will be automatically configured whenever possible. You may need to re-
move IPv6 link-local address manually using ifconfig(8), when you would
like to disable the use of IPv6 as inner header (like when you need pure
IPv4-over-IPv6 tunnel). Finally, use routing table to route the packets
toward gif interface.
gif interface can be configued to perform bidirectional tunnel, or multi-
destination tunnel. This is controlled by IFF_LINK0 interface flag. Al-
so, gif can be configured to be ECN friendly. This can be configured by
IFF_LINK1.
Bidirectional and multi-destination mode
Usually, gif implements bidirectional tunnel. ifconfig(8) should config-
ure a tunnel ingress point (this node) and an egress point (tunnel
endpoint), and one gif interface will tunnel to only a single tunnel end-
point, and accept from only a single tunnel endpoint. Source and desti-
nation address for outer IP header is always the ingress and the egress
point configued by ifconfig(8).
With IFF_LINK0 interface flag, gif can be configured to implement multi-
destination tunnel. With IFF_LINK0, it is able to configure egress point
to IPv4 wildcard address (0.0.0.0) or IPv6 unspecified address (0::0).
In this case, destination address for the outer IP header is determined
based on the routing table setup. Therefore, one gif interface can tun-
nel to multiple destinations. Also, gif will accept tunneled traffic
from any outer source address.
When finding a gif interface from the inbound tunneled traffic, bidirec-
tional mode interface is preferred than multi-destination mode interface.
For example, if you have the following three gif interfaces on node A,
tunneled traffic from C to A will match the second gif interface, not the
third one.
+ bidirectional, A to B
+ bidirectional, A to C
+ multi-destination, A to any
Please note that multi-destination mode is far less secure than bidirec-
tional mode. Multi-destination mode gif can accept tunneled packet from
anybody, and can be attacked from a malicious node.
ECN friendly behavior
gif 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
IFF_LINK1 interface flag.
Without IFF_LINK1, gif will show a normal behavior, like described in
RFC1933. This can be summarized as follows:
Ingress Set outer TOS bit to 0.
Egress 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:
Ingress Copy TOS bits except for ECN CE (masked with 0xfe) from
inner to outer. set ECN CE bit to 0.
Egress 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 mutual agreement with the peer.
Security
Malicious party may try to circumvent security filters by using tunnelled
packets. For better protection, gif performs martian filter and ingress
filter against outer source address, on egress. Note that mar-
tian/ingress filters are no way complete. You may want to secure your
node by using packet filters.
As mentioned above, multi-destination mode (IFF_LINK0) is far less secure
than bidirectional mode.
SEE ALSO
inet(4), inet6(4), ifconfig(8)
R. Gilligan, and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and
Routers", RFC1933, April 1996, ftp://ftp.isi.edu/in-notes/rfc1933.txt.
Sally Floyd, David L. Black, and K. K. Ramakrishnan, IPsec Interactions
with ECN, December 1999, draft-ietf-ipsec-ecn-02.txt.
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 ad-
dress 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.
gif(4) is an IFF_POINTOPOINT device, however, it supports NBMA behavior
in multi-destination mode.
NetBSD 1.5 April 10, 1999 2
Powered by man-cgi (2024-03-20).
Maintained for NetBSD
by Kimmo Suominen.
Based on man-cgi by Panagiotis Christias.