MirOS Manual: gif(4)

GIF(4)                     BSD Programmer's Manual                      GIF(4)


     gif - generic tunnel interface


     pseudo-device gif [count]


     The gif interface is a generic tunnelling pseudo-device for IPv4 and
     IPv6. It can tunnel IPv[46] traffic over IPv[46], for a total of four
     possible combinations. The behavior of gif is mainly based on RFC 1933
     IPv6-over-IPv4 configured tunnel.

     A gif interface can be created at runtime using the ifconfig gifN create
     command or by setting up a hostname.if(5) configuration file for

     To use gif, the administrator needs to configure the addresses used for
     the outer header. This can be done by using ifconfig(8), or through the
     SIOCSIFPHYADDR ioctl. The administrator needs to also configure the ad-
     dresses used for the inner header, by using ifconfig(8). Note that IPv6
     link-local address (those start with fe80::) will be automatically con-
     figured whenever possible. One may need to remove any IPv6 link-local ad-
     dress manually using ifconfig(8), to disable the use of IPv6 as inner
     header (e.g., when a pure IPv4-over-IPv6 tunnel is required). Also, the
     routing table may be used to route the packets toward the gif interface.

     If plain Ethernet-over-IP is being used, the sysctl(3) variable
     net.inet.etherip.allow must be set to 1. This is not necessary in cases
     where Ethernet-over-IP is being protected using ipsec(4).

     Finally, the gif interface may be used as a bridge(4) member. Ethernet
     frames forwarded by the bridge to the gif interface are encapsulated in-
     side an IPv4 or IPv6 header (depending on how the interface is config-
     ured), with transport protocol number 97 (etherip). IPv4 or IPv6 packets
     carrying transport protocol 97 are delivered to the gif interface whose
     "physical" addresses match the source/destination addresses of the packet
     (the source address of the packet must match the destination "physical"
     address, and vice versa).


     sysctl(3), inet(4), inet6(4), ipsec(4), ifconfig(8)

     R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and
     Routers", RFC 1933, 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.


     The gif device first appeared in WIDE hydrangea IPv6 kit.


     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 re-
     ceive 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 the bridge(4), 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 ad-
     dresses, the one with the lowest index number will receive all traffic.

MirOS BSD #10-current           April 10, 1999                               1

Generated on 2015-07-19 22:36:15 by $MirOS: src/scripts/roff2htm,v 1.80 2015/01/02 13:54:19 tg Exp $

These manual pages and other documentation are copyrighted by their respective writers; their source is available at our CVSweb, AnonCVS, and other mirrors. The rest is Copyright © 2002–2015 The MirOS Project, Germany.
This product includes material provided by Thorsten Glaser.

This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report – diffs preferred.