Technical Information Paper Tip-12-225-01 Fundamental Filtering of Ipv6 Network Traffic

TLP: GREEN
Technical Information Paper TIP-12-225-01

Fundamental Filtering of IPv6 Network Traffic
1
1
US-CERT continuously strives to improve its products and services. You can help by answering a very short series of questions
about this product at the following URL: https://forms.us-cert.gov/ncsd-feedback/.
Tim Stahl, Michael King, Robert Renstrom
June 19, 2012
Overview
This paper begins a series of IPv6 TIPs to assist network defenders with the security implications of
IPv6 deployment. This document will not duplicate existing published documentation concerning the
theoretical aspects of IPv6-based network security, but will focus more on the first steps of a
HowTo for network defenders.
You will find non-vendor-specific provisioning of IPv6-based network traffic filtering via basic types
of traffic blocking suggestions, identification of deprecated addresses, a brief discussion on ICMPv6,
tunneling, and additional topics to consider when developing an IPv6 implementation strategy.
Implementing IPv6 introduces a myriad of challenges, including providing security at network
borders as well as internal controls. By design, IPv6 enables each hosts direct connection to the
internet with a completely routable address.
Please ensure each recommendation in this TIP is vetted in a test network prior to implementation
in your production environment.
Notification
This report is provided as is for informational purposes only. The Department of Homeland Security (DHS) does not
provide any warranties of any kind regarding any information contained within. In no event shall the United States
Government or its contractors or subcontractors be liable for any damages, including but not limited to, direct, indirect, special
or consequential damages, arising out of, resulting from, or in any way connected with this report, whether or not based upon
warranty, contract, tort, or otherwise, whether or not arising out of negligence, and whether or not injury was sustained from,
or arose out of the results of, or reliance upon the report.
The display of the DHS official seal or other DHS visual identities, including the US-CERT name or logo, on this report shall
not be interpreted to provide the recipient organization authorization to use the official seal, insignia or other visual identities
of the Department of Homeland Security, including US-CERT. The DHS seal, insignia, or other visual identities shall not be
used in any manner to imply endorsement of any commercial product or activity by DHS, US-CERT, or the United States
Government. Use of the DHS seal without proper authorization violates federal law (e.g., 18 U.S.C. 506, 701, 1017), and is
against DHS policies governing usage of its seal.
This document is TLP: GREEN. Recipients may share TLP: GREEN information with peers and partner organizations within
their sector or community, but not via publicly accessible channels. Please contact US-CERT with specific distribution
inquiries.

TLP: GREEN
Details
The following recommendations are not written in specific firewall or IDS/IPS syntax because of the
great variety of infrastructure filtering devices and software with differing syntax that are available.
However, using the guidance provided below for the types of traffic and addresses, an administrator
should be able to construct the appropriate rule syntax for their environment. It is not meant to be an
authoritative word in IPv6 network security; it is merely a baseline if nothing has been done to secure
your network from IPv6 security threats.
Though format and address length are different between IPv4 and IPv6, many of the features of the
protocols remain the same, rules included. All inbound or outbound traffic that is not specifically
permitted should be blocked regardless of the protocol version. There are a great variety of
capabilities for infrastructure devices and their abilities to filter IPv6 traffic. If an organization is
connected to the internet, it needs the network infrastructure capable of filtering IPv6 traffic at the
same level of competency as the infrastructure used with IPv4 traffic. This also applies to those
networks that do not allow IPv6 traffic to enter or traverse the network.
2
2
National Institute of Standards Special Publication 800-41, Section 4.1.2, (NIST SP800-41),
http://csrc.nist.gov/publications/nistpubs/800-41-Rev1/sp800-41-rev1.pdf. Last accessed on J uly 5, 2012.
IPv6 continues to evolve and mature, and vendor implementations to comply with the applicable
RFCs will vary. Changes will continue to occur to the 150 or so IETF standards that govern it. This
will occur at a faster pace than the IT world has ever had to deal with before.
3,4
3
The Internet Big Picture, Internet Usage Statistics, World Internet Users and Population Stats,
http://www.internetworldstats.com/stats.htm. Last accessed on J uly 24, 2012.
4
http://fiber.google.com/about/. Last accessed on J uly 27, 2012.
This will be a living
document, with revisions reflecting both changes to the standard as well as lessons learned.
Note: The numbers in superscript following an alphanumeric text string are footnote references and
should not be considered part of the IPv6 address.
Access Control
As the digital world transitions to using IPv6, administrators need to understand how to implement
security-based access controls. Therefore, a common baseline is needed, which this part of the
document will address. Examples of the vendor agnostic type of IPv6-related traffic that should be
blocked are provided in the preceding subsections.
If your enterprise infrastructure is not currently set up to run IPv6, then it is recommended all devices
on the network have the IPv6 interface disabled. This will help prevent known and unknown IPv6-
based attacks.
TLP: GREEN
US-CERT Technical Information Paper TIP-12-225-01 Page 2 of 10

TLP: GREEN
All traffic from these address or ranges should be blocked both inbound and outbound.
o The loopback address is : : 1/ 128.
5
5
Internet Engineering Task Force, RFC 4291, http://tools.ietf.org/html/rfc4291. Last accessed on J uly 5, 2012.
Can be displayed as
0: 0: 0: 0: 0: 0: 0: 1
: : 1
o The unspecified address, similar to the IPv4 address 0.0.0.0, is ::/128, and is
only used when an interface doesnt know what its link local address is yet.
6
6
RFC4291
Can be displayed as
0: 0: 0: 0: 0: 0: 0: 0
: : / 0
: :
Depending on your IPv6 implementation, this address may be seen within
your network but should not appear on the internet or be routed to it.
o The IPv4-mapped address is ::FFFF: 0: 0/ 96.
7
7
NIST SP800-41
The IPv4 address 129. 107. 86. 36 can be displayed as
0: 0: 0: 0: 0: FFFF: 129. 107. 86. 36
: : FFFF: 129. 107. 86. 36
IPv4-mapped addresses should not be confused with the similar, and
deprecated, IPv4-compatible addresses. IPv4-mapped addresses can be used
in a dual-stack environment to map IPv4 addresses to IPv6 addresses allowing
IPv6-only applications to operate with IPv4 nodes.
While they can be used internally on your network, they are not routable in the
internet.
8
8
NIST SP800-41
o Link-local unicast addresses
9
9
NIST SP800-41
fe80::/10, fe90::/10, fea0::/10, feb0::/10
Should be treated similarly to the private address space in IPv4. Expect to see
these on your internal network, but dont allow it to cross your network border
in either direction.
o Site-local addresses are f c00: : / 7.
10
10
This range functions the same as the IPv4 private address ranges.
TLP: GREEN

TLP: GREEN
o The documentation addresses are 2001: db8: : / 32.
11
11
These addresses are used for documentation purposes such as user manuals,
RFCs, etc. Similar in function to the 555 telephone numbers used on TV
and in movies.
o Orchid
Overlay Routable Cryptographic Hash Identifiers (ORCHID) addresses are
2001: 10: : / 28.
12
12
These addresses are used as identifiers and should
not be routable.
o IPv6 Benchmarking Addresses are 2001: 2: : / 48
o Discard-Only Prefix for remote triggered blackhole routing addresses are
0100: : / 64.
13
13
Internet Assigned Numbers Authority, http://www.iana.org/assignments/icmpv6-parameters. Last accessed J uly 4,
2012.
o IANA Special Purpose Address Block
14
14
2001: 0000: : / 29 - 2001: 01F8: : / 29
o Address ranges Reserved by the IETF
0000::/8 0100::/8 0200::/7 0400::/6
0800::/5 1000::/4 2000::/3
15
15
It is US-CERTs position that, since this address space has not been allocated, blocking this address space at the
firewall is a business case decision to be made by each entity with respect to their business needs and architecture.
4000::/3
6000::/3 8000::/3 A000::/3 C000::/3
E000::/4 F000::/5 F800::/6 FE00::/9
FEC0::/10
Deprecated Addresses
A compilation of special use IPv6 addresses have been discontinued in the following
categories: Node-Scoped Unicast, IPv4-Mapped Addresses, IPv4-Compatible Addresses,
Link-Scoped Unicast, Unique-Local, Documentation Prefix, 6to4, Teredo, 6bone, ORCHID,
Default Route, IANA Special-Purpose IPv6 Address Registry, and Multicast, and the reasons
for removing them are in the referenced RFCs. However, US-CERT has selected the
following address types, again to form the foundation of information for your
consideration.
16
16
Internet Engineering Task Force RFC 5156, http://tools.ietf.org/html/rfc5156. Last accessed on J uly 30, 2012.
,17
TLP: GREEN

TLP: GREEN
17
RFC 4291
These have been removed from the IPv6 standard and should not appear on any network:
o The IPv4-compatible addresses are : : <i pv4- addr ess>/ 96.
o 6bone experimental network ranges used for early testing of IPv6.
Addresses of the first instance of the 6bone experimental network were
5f 00: : / 8.
18
18
The second instances of the 6bone experimental network were
3f f e: : / 16.
19
19
The following addresses were returned to IANA 5f 00: : / 8 and
3f f e: : / 16.
20
20
o The deprecated address range of FEC0: : / 10, is no longer routable and should be
blocked on all routers and firewalls.
Routing
IPv6 routing has also introduced additional capabilities, but the items in the list below have
specific reasons for blocking; for example, type 0 can be exploited for generating denial-of-
service traffic.
21
21
Routing Headers
o Block packets containing type 0 routing header extensions (source routing).
Block packets containing type 1 routing header extensions (NIMROD
routing, deprecated in 2009).
Extension Header type 43, variant 0 and 1
o Be careful NOT to block all packets with header type 43; not
all routing header extensions are dangerous, just variant 0.
Block routing header types 4 252, unassigned.
Block routing header types 253 & 256 experimental.
22
22
Block routing header type 255 reserved.
o Some IP protocols are rarely passed between an outside network and an
organizations LAN, and therefore can simply be blocked in both directions at the
firewall. For example, IGMP is a protocol used to control multicast networks, but
multicast is rarely used, and when it is, it is often not used across the internet.
TLP: GREEN

TLP: GREEN
Therefore, blocking all IGMP traffic in both directions is feasible if multicast is not
used.
23
23
National Institute of Standards Special Publication 800-41, http://csrc.nist.gov/publications/nistpubs/800-41-
Rev1/sp800-41-rev1.pdf. Last accessed on J uly 5, 2012.
IPv6 Option Types to Block:
C3 unassigned
7 Calypso
24
24
Only useful in closed networks and shouldnt be seen on the internet,
and thus can be safely blocked.
1e, 3e, 5e, 7e, 9e, be, de, f e - experimental
f f unassigned
Multicast Addresses
Multicast addresses that contain a 4-bit scope in the address field that
indicates the packets scope are f f 00: : / 8. (Only addresses with global
scope should be allowed to cross the network boundary.)
25
25
RFC4291
Understanding multicast scope
The 4th hex character indicates the scope of a multicast address,
with the values ranging from 0 t o F, each indicating a scope.
Address will begin with f f XY
o f f identifies the address as multicast
o X = a hex character that represents some set of flags that
arent relevant to this topic
o Y = the scope of the multicast address that determines its
range
Only scope values of E are global and should be allowed to pass your
networks border, meaning those with the 4th hex value of E
( FFXE) .
ICMPv6 Filtering
In keeping with the security best practices of IPv4, much of the same could be applied to
ICMPv6. An administrator will need to know what they want to allow in and out of their
network when monitoring devices. This section touches on a couple of the types of blocking
that is recommended via the RFC.
TLP: GREEN

TLP: GREEN
o Recommended Blocking
Seamoby Experimental Protocol (ICMP Type 150)
26
26
experimental protocol designed to accelerate IP handover between
wireless access routers
All informational messages currently unassigned by Internet Assigned
Numbers Authority (IANA): (Types 154-199 and 202-254).
27
27
ICMPv6 specification requires informational messages of unknown
types must be silently discarded, which can be accomplished by
simply blocking them at the firewall.
This list should be reviewed periodically for changes as new message
numbers get assigned.
Node Information enquiry messages should generally not be forwarded across
site boundaries.
Node Information Query (Type 139)
Node Information Response (Type 140)
Router Renumbering messages should not be forwarded across site
boundaries (Type 138)
Experimental message types: 100, 101, 200, and 201
Reserved extension types (127 and 255)
13,28
28
IANA ICMPv6
o As stated in the Overview caveat, implementation of the following will be dependent
(requires research and judgment) upon your specific environments:
Error messages not currently defined by IANA: (Types 5-99 and 102-126).
27
The ICMPv6 specification recommends allowing unknown error
messages in the hopes that a higher level protocol can understand
them.
Could allow a communication channel for malicious traffic like C&C
communication.
This list should be reviewed periodically for changes as new message
numbers get defined.
Tunneling
If an organization cannot obtain an IPv6 address natively, then creating a tunnel is a viable
method to establish connectivity between an IPv4 and another running IPv6. Tunneling can
provide the connectivity, but it also presents security considerations since it can also provide
a method to surreptitiously gain access to a network. The suggestions listed below help to
mitigate the security issues.
TLP: GREEN

TLP: GREEN
o 6to4 tunneling
6to4 addresses are 2002: : / 16.
29
29
The 6to4 addresses may be routed
when the site is running a 6to4 relay or offering a 6to4 transit service. If not,
then can be blocked.
o Teredo /Miredo (Unix, Linux) tunneling
Teredo addresses are 2001: : / 32.
30
30
If you arent using or allowing this type of tunneling, these addresses
can be blocked.
o Intra-site Automatic Tunnel Addressing Protocol ( ISATAP tunneling)
Filter for this string 0000: 5EFE:(followed by the 32-bit IPv4
address).
Additional tunneling information
o Tunneled IPv6 within IPv4 traffic should be isolated to IPv4
protocol 41.
o Tunneled IPv6 within IPv6 will contain a next header value
of 41. This indicates that the type of packet contained within
the IPv6 packet is also IPv6, where you would normally expect
this to be ICMPv4 (next header value of 1), TCP (next header
value of 6) or some other higher level protocol or possibly an
extension header like a fragmentation or routing extension
header.
Organizations that do not yet use IPv6 should block all native and
tunneled IPv6 traffic at their firewalls. Note that such blocking limits
testing and evaluation of IPv6 and IPv6 tunneling technologies for
future deployment. To permit such use, the firewall administrator can
selectively unblock IPv6 or the specific tunneling technologies of
interest for use by the authorized testers.
31
31
RFC 4291
Use access control lists at border routers to block protocols 41 (used
by 6to4), 43, 44, 58, 59, 60, and 192.88.99.1 (default anycast address
of some 6to4 systems) would be a good place to start.
32
32
CERT/CC Blog, Bypassing firewalls with IPv6 tunnels, by Ryan Giobbi, April 2, 2009,
http://www.cert.org/blogs/certcc/2009/04/bypassing_firewalls_with_ipv6.html. Last accessed on J uly 4, 2012.
TLP: GREEN

TLP: GREEN
References
1. National Institute of Standards Special Publication 800-41, Section 4.1.2, (NIST SP800-41),
http://csrc.nist.gov/publications/nistpubs/800-41-Rev1/sp800-41-rev1.pdf. Last accessed on J une 19,
2012.
2. Internet Engineering Task Force, RFC 4291, http://tools.ietf.org/html/rfc4291. Last accessed on J une 19,
2012.
2012.
2012.
2012.
6. Internet Assigned Numbers Authority, http://www.iana.org/assignments/icmpv6-parameters. Last accessed
on J uly 4, 2012.
2012.
8. Internet Engineering Task Force, RFC 1897, http://tools.ietf.org/html/rfc1897. Last accessed on J une
19, 2012.
2012.
2012.
2012.
12. National Institute of Standards Special Publication 800-41, http://csrc.nist.gov/publications/nistpubs/800-
41-Rev1/sp800-41-rev1.pdf. Last accessed on J une 19, 2012.
13. Internet Engineering Task Force, RFC 5570, http://tools.ietf.org/html/rfc5570. Last accessed on
J une 19, 2012.
2012.
19, 2012.
2012.
19, 2012.
18. Internet Engineering Task Force, RFC 5095, http://tools.ietf.org/html/rfc5095. Last accessed on J uly
30, 2012.
19. Internet Engineering Task Force RFC 5156, http://tools.ietf.org/html/rfc5156. Last accessed on J uly
30, 2012.
20. CERT/CC Blog, Bypassing firewalls with IPv6 tunnels, by Ryan Giobbi, April 2, 2009,
http://www.cert.org/blogs/certcc/2009/04/bypassing_firewalls_with_ipv6.html. Last accessed on J uly 4,
2012.
TLP: GREEN

TLP: GREEN
Contact US-CERT
For any questions related to this report, please contact US-CERT at:
Email: soc@us-cert.gov
Voice: 1-888-282-0870
Incident Reporting Form: https://forms.us-cert.gov/report/
Document FAQ
What is a TIP? A Technical Information Paper (TIP) is issued for a topic that is more
informational in nature, describing an analysis technique, case study, or general
cybersecurity issue. Depending on the topic, this product may be published to the public
website.
I see that this document is labeled as TLP: GREEN. Can I distribute this to other
people? Information in this category can be circulated widely within a particular
community. However, the information may not be published or posted publicly on the
internet, nor released outside of the community. Please contact US-CERT with specific
distribution inquiries.
Can I edit this document to include additional information? This document is not to be
edited, changed, or modified in any way by recipients. All comments or questions related
to this document should be directed to the US-CERT Security Operations Center at
1-888-282-0870 or soc@us-cert.gov.
TLP: GREEN

Technical Information Paper Tip-12-225-01 Fundamental Filtering of Ipv6 Network Traffic

Uploaded by

Copyright:

Available Formats

Technical Information Paper Tip-12-225-01 Fundamental Filtering of Ipv6 Network Traffic

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Technical Information Paper Tip-12-225-01 Fundamental Filtering of Ipv6 Network Traffic

Uploaded by

Copyright:

Available Formats

TLP: GREEN

Technical Information Paper TIP-12-225-01

You might also like