FAQ : Connectivity (Tunnels and Subnets) : Is my connectivity filtered? / Mandatory IPv6 Filtering on IPv6

Other FAQ sections

Can I move my tunnel/subnet to another PoP? Can I request multiple subnets over my tunnel? Can I use SixXS tunnels to hide my IPv4 IP? Can a heartbeat tunnel be converted to a static or AYIYA tunnel or vice versa? Do you provide 6to4 connectivity? Do you provide BGP peering? Heartbeat or AYIYA tunnel doesn't work How do I configure my machine to setup the IPv6 in IPv4 tunnel to the SixXS PoP? How do I give connectivity to other hosts on my subnet? How is my endpoint connectivity tested? I have a firewall, what ports/protocols are used? IPv6 Transition Mechanism / Tunneling Comparison Is my connectivity filtered? / Mandatory IPv6 Filtering on IPv6 Is there a command line/non web tool for SixXS? Is there a traffic/data limit? Is there support for dynamic IPv4 endpoints? Multicast Support My IPv6 is random and changes often. Why? My static endpoint is broken and I don't want to lose credits My tunnel doesn't work My tunnel goes down after some idletime. My tunnelendpoint also is a NAT/Connection Tracker My tunnel/subnet doesn't work at once My tunnel/subnet stays in deleted state PoPs that are marked down The tunnel is slow Transit / I have some other tunnels and now it doesn't work Tunnel endpoint didn't ping What is the MTU of a tunnel? Where can I get native IPv6 / Which ISPs provide IPv6? Where can I get native IPv6 transit? Which PoP should I choose? Why are some PoPs not available for tunnels

Is my connectivity filtered? / Mandatory IPv6 Filtering on IPv6

Except for the minor essential filters defined below, connectivity provided by the SixXS PoPs are completely unfiltered and allow you to enjoy IPv6 and the Internet to its full extent. You will thus most likely want to configure your own firewall if you want to be safe on the Internet.

All PoPs

The PoPs only forward packets which are sourced from the client tunnel endpoint or from the subnet that has been routed toward that endpoint as per BCP38. As these are Access Nodes, they also PoPs reject IPv6 Routing Headers of Type 0 (Source Routing).

Additionally the following prefixes are routed to the 'lo' device as they are not supposed to be available on the Internet. Sending packets to those destinations would thus only cause them to be returned by a core router. The effect of the nullroute is that an ICMP destination network unreachable is given by the PoP.

Prefix	Description
2001:db8::/32	IPv6 Documentation Prefix (RFC3849)
2001:10::/28	ORCHID (RFC4843)
fc00::/7	Unique Local Addresses (RFC4193)
fe80::/10	Link Local Unicast (RFC4291)

All other traffic is allowed to pass through onto the Internet. Of course: do not abuse.

ittrn01

Additionally to the filters applied to all the PoPs, ittrn01 only allows IRC connections to Italian IRC servers, all other IRC servers are blocked. Connection attempts on any port will return an ICMP indicating Administratively Prohibition.

---

Mandatory IPv6 Filtering on IPv6

In this section we specify mandatory IPv6 filtering that should be enabled on all nodes. We suggest that operators of nodes minimally apply these filters along with other filters that they deem neccesary. Of course next to these hints please apply common sense and BCP38, in particicular ingress and egress filtering, to prevent endusers being able to insert spoofed traffic onto the Internet.

The general rule is to disable processing of Routing Header Type 0 (RH0). Note that if the RH0 is not processed, other hosts that are still vulnerable and can be used to perform this attack. The 'fixed' host will simply still forward the packet and thus the ping-pong effect can be caused by vulernable hosts on other networks. Applying BCP38 resolves this as with uRPF enabled only correctly sourced packets are forwarded.

The Routing Header Type 0 (RH0) concern was raised in IPv6 Routing Header Security by Philippe Biondi and Arnaud Ebalard released at CanSecWest 2007, see their presentation for more information about this issue.

Check IPv6 Ping Pong by Geoff Huston for a detailed explaination on how this works, and NatIsBad for a long list of related links.

Cisco

To only block Routing Header Type 0 in 12.4(2)T and up one can use:

Router(config)#ipv6 access-list deny-sourcerouted
Router(config-ipv6-acl)#deny ipv6 any any routing-type 0
Router(config-ipv6-acl)#permit ipv6 any any
Router(config)#interface Ethernet0
Router(config-if)#ipv6 source-route
Router(config-if)#ipv6 traffic-filter deny-sourcerouted in

This has to be separately applied to all the interfaces.

Alternatively, to disable processing of all types routing headers on 12.2(15)T and up one can use:

no ipv6 source-route

Note that this will still forward these packets on to other hosts which can be vulnerable. This statement also affects perfectly valid Routing Headers of Type 2 which are used by Mobile IPv6. Thus if possible upgrade to 12.4(2)T or higher and apply the above filters. For further details see: Cisco SA-20070124-IOS-IPv6 and the previous advisory which is related to this problem 81722: Identifying and Mitigating Exploitation of the IPv6 Routing Header Vulnerability.

Juniper

Not yet, but they claim to be busy with it, call your TAC and complain.

PSN-2007-04-034 - IPv6 Route Header Type 0 (RH-0) vulnerability in JUNOS (CERT/CC VU#267289) (login required) has the following two important points:

• "Code to address this issue is being developed for all currently supported JUNOS releases. This Technical Bulletin will be updated when corrected software is available."
• "When updated software is available, processing of IPv6 Route Header Type 0 extension headers will be disabled by default"

It also contains the following work-around:

firewall { family inet6 { filter filter_v6_rh { term 0 { from { next-header [hop-by-hop routing]; } then { discard; } } } } }

Apple

Not yet, but they are aware of the issue.

Microsoft Windows

Can be filtered using the Windows Firewall and the "advanced security" snap-in MMC by blocking IPv6 Route (proto 43). Per default it drops en-route packets.

Sun Solaris

Solaris 8 has RH0 processing enabled. Solaris 9 and 10 drop packets containing RH0 per default. This can be verified by executing:

# ndd /dev/ip6 ip6_forward_src_routed
0

Linux

Filter all packets that have RH0 headers

ip6tables -A INPUT -m rt --rt-type 0 -j DROP
ip6tables -A FORWARD -m rt --rt-type 0 -j DROP
ip6tables -A OUTPUT -m rt --rt-type 0 -j DROP

of course before accepting anything else.

RH0 processing is disabled per default since Linux 2.6.20.9. These hosts will still forward RH0 headers per default, using the above filter rule will really block them.

KAME

KAME is the stack used by, amongst others, FreeBSD, OpenBSD and NetBSD, see below for details on these. KAME's statement can be found in their document called KAME project's action on Type 0 Routing Header issue.

The current patch returns an ICMPv6 Parameter Problem back to the origin host: route6.c 1.60 1.63 patch. Note that ICMPv6 Error messages are ratelimited and as such can't be usefully used for attacks.

FreeBSD

One has to upgrade the kernel with at least the following patch in place: route6.c 1.12 -> 1.13. For further details see FreeBSD-SA-07:03.ipv6.

OpenBSD

Source code patches have to be applied, unless not done yet. The following patches are available: OpenBSD 4.0 common/012_route6.patch, OpenBSD 3.9 common/022_route6.patch. For further details see OpenBSD 4.0 Errata 012_route6 and OpenBSD 3.9 Errata 022_route6.

OpenBSD -current (per 2007-05-08) rejects all packets containing RH0, see the following three CVS commits 1, 2, 3.

NetBSD

Fix commited to -current, expected to show up in 4.0, 3.x and maybe 2.x "real soon now".

DragonflyBSD

Fix commited to -current.