NAME
stf —
6to4 tunnel interface
SYNOPSIS
pseudo-device stf
DESCRIPTION
The
stf interface supports “6to4” IPv6 in IPv4
encapsulation. It can tunnel IPv6 traffic over IPv4, as specified in
RFC3056
.
stf interfaces are
dynamically created and destroyed with the
ifconfig(8)
create and
destroy subcommands. Only one
stf interface may be created.
For ordinary nodes in 6to4 sites, you do not need a
stf
interface. The
stf interface is only necessary on the site
border router (called the “6to4 router” in the specification).
Due to the way the 6to4 protocol is specified,
stf interfaces
require certain configuration to work properly. A single (no more than one)
valid 6to4 address needs to be configured on the interface. “A valid
6to4 address” is an address which has the following properties. If any
of the following properties are not satisfied,
stf raises a
runtime error on packet transmission. Read the specification for more details.
- matches
2002:xxyy:zzuu::/48
,
where xxyy:zzuu
is the hexadecimal notation of an
IPv4 address for the node. The IPv4 address used can be taken from any
interface your node has. Since the specification forbids the use of IPv4
private address, the address needs to be a global IPv4 address.
- Subnet identifier portion (48th to 63rd bit) and
interface identifier portion (lower 64 bits) are properly filled to avoid
address collisions.
If you would like the node to behave as a relay router, the prefix length for
the IPv6 interface address needs to be 16 so that the node would consider any
6to4 destination as “on-link”. If you would like to restrict 6to4
peers to be inside a certain IPv4 prefix, you may want to configure the IPv6
prefix length to be “16 + IPv4 prefix length”. The
stf interface will check the IPv4 source address on packets
if the IPv6 prefix length is larger than 16.
stf can be configured to be ECN (Explicit Congestion
Notification) friendly. This can be configured by
IFF_LINK1
. See
gif(4) for details.
Please note that the 6to4 specification is written as an “accept tunneled
packet from everyone” tunneling device. By enabling the
stf device, you are making it much easier for malicious
parties to inject fabricated IPv6 packets to your node. Also, malicious
parties can inject IPv6 packets with fabricated source addresses to make your
node generate improper tunneled packets. Administrators must be cautious when
enabling the interface. To prevent possible attacks, the
stf
interface filters out the following packets (note that the checks are in no
way complete):
- Packets with IPv4 unspecified addresses as outer IPv4
source/destination (
0.0.0.0/8
)
- Packets with the loopback address as outer IPv4
source/destination (
127.0.0.0/8
)
- Packets with IPv4 multicast addresses as outer IPv4
source/destination (
224.0.0.0/4
)
- Packets with limited broadcast addresses as outer IPv4
source/destination (
255.0.0.0/8
)
- Packets with private addresses as outer IPv4
source/destination (
10.0.0.0/8, 172.16.0.0/12,
192.168.0.0/16
)
- Packets with IPv4 link-local addresses as outer IPv4
source/destination (
169.254.0.0/16
)
- Packets with subnet broadcast addresses as outer IPv4
source/destination. The check is made against subnet broadcast addresses
for all of the directly connected subnets.
- Packets that do not pass ingress filtering. Outer IPv4
source addresses must meet the IPv4 topology on the routing table. Ingress
filtering can be turned off by
IFF_LINK2
bit.
- The same set of rules are applied against the IPv4
address embedded into the inner IPv6 address, if the IPv6 address matches
the 6to4 prefix.
- Packets with site-local or link-local unicast addresses
as inner IPv6 source/destination
- Packets with node-local or link-local multicast
addresses as inner IPv6 source/destination
It is recommended to filter/audit incoming IPv4 packets with IP protocol number
41, as necessary. It is also recommended to filter/audit encapsulated IPv6
packets as well. You may also want to run normal ingress filtering against
inner IPv6 addresses to avoid spoofing.
By setting the
IFF_LINK0
flag on the
stf interface, it is possible to disable the input path,
making direct attacks from the outside impossible. Note, however, that other
security risks exist. If you wish to use the configuration, you must not
advertise your 6to4 addresses to others.
EXAMPLES
Note that
8504:0506
is equal to
133.4.5.6
, written in hexadecimal.
# ifconfig ne0 inet 133.4.5.6 netmask 0xffffff00
# ifconfig stf0 create inet6 2002:8504:0506:0000:a00:5aff:fe38:6f86 \
prefixlen 16 alias
The following configuration accepts packets from IPv4 source address
9.1.0.0/16
only. It emits 6to4 packets only for IPv6
destination 2002:0901::/32 (IPv4 destination will match
9.1.0.0/16
).
# ifconfig ne0 inet 9.1.2.3 netmask 0xffff0000
# ifconfig stf0 create inet6 2002:0901:0203:0000:a00:5aff:fe38:6f86 \
prefixlen 32 alias
The following configuration uses the
stf interface as an
output-only device. You need to have alternative IPv6 connectivity (other than
6to4) to use this configuration. For outbound traffic, you can reach other
6to4 networks efficiently via
stf. For inbound traffic, you
will not receive any 6to4-tunneled packets (less security drawbacks). Be
careful not to advertise your 6to4 prefix to others
(
2002:8504:0506::/48
), and not to use your 6to4 prefix
as a source address.
# ifconfig ne0 inet 133.4.5.6 netmask 0xffffff00
# ifconfig stf0 create inet6 2002:8504:0506:0000:a00:5aff:fe38:6f86 \
prefixlen 16 alias deprecated link0
# route add -inet6 2002:: -prefixlen 16 ::1 -ifp stf0
SEE ALSO
gif(4),
inet(4),
inet6(4)
Brian Carpenter and
Keith Moore, Connection of IPv6
Domains via IPv4 Clouds, RFC,
3056, February 2001.
C. Huitema, An
Anycast Prefix for 6to4 Relay Routers, RFC,
3068, June 2001.
F. Baker and P.
Savola, Ingress Filtering for Multihomed
Networks, RFC, 3704,
March 2004.
P. Savola and C.
Patel, Security Considerations for 6to4,
RFC, 3964,
December 2004.
Jun-ichiro itojun Hagino,
Possible abuse against IPv6 transition technologies,
draft-itojun-ipv6-transition-abuse-01.txt,
July 2000, expired, work in
progress.
HISTORY
The
stf device first appeared in WIDE/KAME IPv6 stack.
BUGS
No more than one
stf interface is allowed for a node, and no
more than one IPv6 interface address is allowed for an
stf
interface. This is to avoid source address selection conflicts between the
IPv6 layer and the IPv4 layer, and to cope with ingress filtering rules on the
other side. This is a feature to make
stf work right for all
occasions.