IPv6 Firewall Functions Analysis

Josef Horalek(&) and Vladimir Sobeslav(&)

Faculty of Informatics and Management,

University of Hradec Kralove, Hradec Kralove, Czech Republic
{josef.horalek,vladimir.sobeslav}@uhk.cz

Abstract. Currently, the most security solutions are based on technologies

realted to the old IPv4 protocol. Although the new protocol requires a different
approach, the network security solution often does not correspond and the
network protection may be affected. One of the results of the IPv6 implemen-
tation is the end of network address translation (NAT). Despite its disadvan-
tages, NAT can act as a security element of IPv6 protocol. The goal of this paper
is to analyse, present and compare firewall functions at the most used Windows
and Linux distribution along with the detailed packet analysis.

Keywords: IPv6
RFC
Firewall
Testing
Firewall6

1 Introduction

One of the IPv6 design intentions is to make a clean break with the need of the network
address translation (NAT). Despite its drawbacks, NAT operates also as a security
element [1] and its extraction creates a breach that needs to be filled. However, the
transition to IPv6 will not occur immediately and all at once; the IPv4 and IPv6
protocols will coexist for some time.
Known problems emerging from the dualness of the environment are e.g.
IPv4-mapped IPv6 addresses which leads to a security breach in the firewall [4]. This
can be problematic especially for the home and small business/office networks without
experienced administrators. RFC 6092 [5] provides a set of recommendations for
simple security of IPv6 gates also via packet filters functions for device manufacturers
particularly aimed at given users. IPv6 packet filtering in big “enterprise” networks
originally designed as “IPv4-only” networks is covered by RFC 7123 [6]. The security
scenarios related to the firewall issues that are necessary to be taken into consideration
are stated as:
• IPv4 firewall might not be able to enforce same security policy for IPv6 operation.
• The firewall can support both IPv4 and IPv6, but it might not be correctly con-
figured for IPv6 traffic control.
The aforementioned document RFC 4942 [3] is relatively extensive and from the
purely IPv6 problems point of view it mentions also routing headers issues (defined in
RFC 2460 [7]) and their potential abuse for firewall bypass or amplification attack.
Such an attack is serious and RFC 5095 [8] recommends all the IPv6 nodes to dep-
recate the use of Type 0 Routing Headers and firewalls to filter this kind of header.

© Springer International Publishing Switzerland 2016

N.T. Nguyen et al. (Eds.): ICCCI 2016, Part II, LNAI 9876, pp. 219–228, 2016.
DOI: 10.1007/978-3-319-45246-3_21
220 J. Horalek and V. Sobeslav

The firewall can potentially be bypassed by means of Type 2 Routing Header. Forged
packets in ICMPv6 error reports, traffic filtering with anycast addresses, IPSec, pro-
cedures for firewall processing of extended or unknown headers, firewall defence
against misuse of Pad1 and PadN options or misuse of link-local addresses, are also all
introduced in RFC 4942 including the fragmentation issue.
Security problems are especially packets with overlapping fragments. The detailed
description of the issue is offered by RFC 5722 [9] suggesting an IPv6 specification
modification in terms of overlapping fragment prohibition. IPv6 specification also
allows the use of a Fragment Header in packets that are in fact not fragmented. As RFC
6946 [10] mentions, these so called atomic fragments often result from the host reaction
on message ICMPv6 “Packet Too Big.” An attacker can artificially fabricate these
messages and then launch any fragmentation-based attacks against such traffic. It
therefore suggests to process atomic fragments independently on other fragments. RFC
6980 [11] subsequently explicitly forbids use of fragmentation in Neighbor Discovery
(ND) messages.
IPv6 brings new Internet Control Message Protocol (ICMP) implementation, so
called ICMPv6, defined in RFC 4443 [12]. ICMPv6 is necessary part for correct IPv6
function, although when uncontrolled this protocol presents potential security risk.
Similar situation is valid for ICMP in IPv4, although same filtering strategies can not be
applied on its IPv6 equivalent. RFC 4890 [13] contains recommendations for ICMPv6
firewall filter, for it is necessary to seek balance between too aggressive and too
benevolent filter policy.
Filtering rules also have to take into consideration the specific ICMPv6 message
type. For instance ICMPv6 error messages have to be let through by the firewall, but if
the firewall serves also as a router, the messages that might be used in configuring a
router interface should not be transited through. RFC 4890 filtering recommendations
furthermore differentiate goals of ICMPv6 traffic – the rules for traffic directed to the
firewall interfaces and the rules for traffic transiting the firewall. ICMPv6 messages are
categorized into classes:
• Messages that must not be dropped.
• Messages that should not be dropped.
• Messages that may be dropped.
• Messages that administrators may or may not want to drop depending on local
policy.
• Messages that administrators should consider dropping.
Messages are within their classes filtered according to their type and scope of
source and destination addresses. In comparison with the original ICMPv4 vs. Firewall
relationship it is necessary to create more granular set of rules. Firewalls also need to be
adapted for so called multihoming – Shim6 protocol defined in RFC 5533 [14]. It offers
the host an option to use multiple IPv6 addresses at the same time. Thus firewall has to
correctly keep the state in situation, when the host uses different IP address for the same
connection. This problem is also discussed in RFC 6629 [15].
The firewall might not be able to process whole long chain and thus allows the
attacker to bypass the filtering rules – RFC 7112 [16] suggests a solution in which the
first packet fragment (i.e. offset equals to 0) has to contain complete Header Chain.
 IPv6 Firewall Functions Analysis 221

Field tests of fragmentation and routing header problems can be found in [17],
where the authors were really able to bypass the firewall in this way. The importance of
proper configuration of packet fragment filtering rules is shown [18] on the illustrative
case where answers of DNSSEC (extension for DNS) to name inquiries can be frag-
mented and dropped by firewall due to their size. The Internet zone becomes
unavailable for clients behind firewall configured like that due to the impossibility of
domain name translation into IP address.
The problem of extension headers/fragmentation is also their practical utilization
and implementation – as examined in the study [19], in real world environment
extension headers are frequently dropped. IETF discusses the possible prohibition of
fragmentation as such in IPv6. Lai et al. [20] researched the possibilities of host firewall
and network firewall cooperation in order to secure IPv6 network. Since packets using
the ESP header are encrypted and hence it is not possible to inspect them by firewalls
(the content of the packet is known only to the source and destination, which owns the
secret key), they propose deployment of dual firewall controlled by a single central
server. It is interesting approach to the solving of the security issues in IPv6 by
actualisation of the idea of so called distributed firewalls for IPv6. Firewall issue in
IPv6 is considerably complex.

2 Problematic Areas of IPv6 Employment

This part represents main areas of the IPv6 employment and utilization issues and
presents the impacts of specific IPv6 features on firewalls. These impacts are intro-
duced here and tested in the following part.

2.1 IPv6 Address-Based Filtering

Stateless packet filtering based on source or destination address works in IPv6 on the
same principle as in IPv4, but it brings higher complexity, for single network interface
can have multiple IPv6 addresses. The problem also arises during the change of internet
service provider (ISP) for in the first 64 bits of IPv6 address, in so called network
prefix, a change occurs. Hosts could have at the same time new and old “deprecated”
addresses for certain specified duration, during which are old addresses being dis-
carded. The packet filter administrator has to properly react on such a situation by
modification of filtering rules.

2.2 Multihoming
Multihoming stands for a state in which a network is connected to multiple internet
service providers and it is desirable and typical especially in cases, where a high
connection reliability is required. It is not a feature that would not be already incor-
porated in IPv4, however in IPv6 it has new queries. The suggested multihoming
solution for IPv6 is Shim6 protocol defined in RFC 5533 [17]. It is able to reroute the
communication to proper paths for multihoming utilization which on the other hand
222 J. Horalek and V. Sobeslav

creates problematic relation with firewalls. A stateful firewall creates a state for each
connection. Since Shim6 changes so called locators, which communicating hosts use
for connection and which not adapted stateful filter uses for specific data stream
identification, it is necessary to adapt the firewall in order for it to be able to respond to
the change. The administrator of the stateless packet filter has to take into consideration
new packet types generated by Shim6.

2.3 Internet Control Message Protocol Version 6

ICMPv6 is used by IPv6 nodes for reporting of errors originating from packet pro-
cessing and for managing of other Internet1 layer functions, such as diagnostics
(ICMPv6 ping). ICMPv6 is integral IPv6 part and the basic protocol (all the messages
and behavior required by the technical specification) has to be fully implemented by
every IPv6 nod. [13] ICMPv6 uses for its functioning messages which can be divided
into two groups, namely error and information messages. The message type is defined
by the value in the ICMPv6 message Header Type field. Field Type is 8 bits long; the
highest bit for error messages is always set to value 0 (range of possible values 0–127)
whereas for information messages it has always the value 1 (128–255 range).

2.4 Extended IPv6 Headers

IPv6 packet is made of two main parts – the header and payload data. The first 40 bytes
of the packet belongs to the header. Extended headers can be inserted and chained
between the header and the data. Every IPv6 firewall has to be able to process a chain
of extended IPv6 headers, since their function might be undesirable from the security
policy point of view of the given organization. The minimum is the ability to skip the
extended headers and move to the higher layer header. The firewall should be able to
set and apply rules due to mere presence of some of the extended headers in the packet.
Firewall rules do not have to be applied on all the extended headers; it is possible to
add or block packets even based on specific choices inside the headers.

3 IPv6 Firewall Functionality Efficiency Testing

In this part the results of the executed tests focused on efficiency and functionality of
the firewalls over IPv6 will be presented.

3.1 Tested Operating Systems

All the operating systems (and firewall implementations they are distributed with)
runned within the scope of testing on the hosts are summarized in the Table 1. All the
tested operating systems were always fully updated before the testing. 64 bit operating
systems variants were used for the testing.
 IPv6 Firewall Functions Analysis 223

Table 1. Tested operating systems

Operating system Firewall Kernel version
MS windows 7 SP1 Windows firewall 6.1.7001
MS windows 8.1 Windows firewall 6.3.9600
MS windows server Windows firewall 6.1.7601
2008 R2
MS windows server Windows firewall 6.3.9600
2012 R2
Debian “Wheezy” Netfilter/iptables 3.2.0-4-amd64
Ubuntu 14.04 LTS Netfilter/iptables 3.13.0-24-generic
Fedora 21 Netfilter/iptables - service iptables service 3.17.4-301-fc21.
workstation replaced by firewall x86_64
CentOS Netfilter/iptables - service iptables service 3.10.0-229.el7.
replaced by firewall x86_64
FreeBSD IP firewall 10.0-RELEASE
OpenBSD Packet filter 5.6
NetBSD IP filter 6.1.5
Oracle solaris IP filter 5.11

3.2 Hardware Used for the Testing

As a source in the generated packets testing figured physical personal computer with
the following hardware configuration:
• Processor - AMD Phenom II X4 955 Deneb Quad-Core 3.2 GHz
• Memory - 8 GB RAM
• Operating system - Xubuntu 14.04 LTS
Virtual machines employed as a destination or a proxy were on the same PC
virtualized by means of virtualization software Oracle VM VirtualBox version 4.3.24.
Every virtual machine was assigned one virtual processor, 1024 MB RAM and turned
on hardware virtualization support (AMD-V). Both on the source and on the packets
destination there was always active software WireShark for network traffic detailed
analysis during the testing.

3.3 Testing Scenario and Firewall6 Results

The tool of choice used for the IPv6 firewall testing is firewall6 from the The Hacker’s
Choice IPv6 Toolkit. It is the most sophisticated of the similar solutions. It was always
launched on the source within the topology depicted in Fig. 1.
The firewall6 intention is to attempt to bypass the rules of access control
(ACL) defined on the firewall. For purposes of this work firewall6 generated TCP traffic
with destination port 22. The combination of protocol and destination port was blocked
by every tested firewall. Firewall6 one by one puts to test scenarios summarized in the
following list:
224 J. Horalek and V. Sobeslav

2001:2:1::b

2001:2:1::1
source target

Fig. 1. Firewall6 testing topology

• FW1 A common SYN packet is sent to find out whether the port is blocked.
• FW2 Same as FW1, but with added data.
• FW3 Field Type on the 2nd layer in the ISO/OSI model is incorrectly set on the IPv4
value. This can lead to IPv6 rule bypassing via IPv6 network code in case the
blocking decision is based only on layer 2.
• FW4 SYN packet has added 8 bytes long Hop-by-hop header, whereas its field
Options is filled with zeroes. The packet should be processed as a packet without
any extended header.
• FW5 The header for Destination Options is used in the same way as in FW4; again,
it should not have any influence on the packet processing.
• FW6 The packet contains Hop-by-hop header with the option Router Alert (which
indicates that it is expedient to examine packet closely since it can possess valuable
information for the router).
• FW7 The packet contains 3 headers for Destination Address. We have mentioned
that the header can occur maximally twice per packet, nevertheless the Options field
is again filled with zeroes and hence these headers should be ignored. They should
not have any impact on packet processing as in FW4 and FW5.
• FW8 The principle is the same as in FW7 and FW5 scenarios, only this time 130
headers for Destination Address is used. In such an amount they can cause diffi-
culties to some devices.
• FW9 Atomic fragment is sent (i.e. packet with Fragmentation header, yet it is in fact
not fragmented).
• FW10 Two atomic fragments with the same ID (Fragmentation headers in the
packet have same 32bit identification number necessary for reassembling) are sent.
Atomic fragments must not be processed in the same way as truly fragmented
network traffic.
• FW11 2 atomic fragments with different IDs.
• FW12 3 atomic fragments with the same ID.
• FW13 3 atomic fragments with different IDs.
• FW14 130 atomic fragments with the same ID.
• FW15 130 atomic fragments with different IDs.
• FW16 260 atomic fragments with the same ID.
• FW17 260 atomic fragments with different IDs.
• FW18 The packet with 2 KB large Address Option is sent. Because of the size it
has to be fragmented and can cause the firewall to collapse.
• FW19 The same principle as in FW18, only with addition of another Address
Option.
 IPv6 Firewall Functions Analysis 225

• FW20 Another FW18 variant. The amount of Address Option headers is increased
to 32.
• FW21 The packet with combination of two Address Option headers and 2 Frag-
mentation headers.
• FW22 The packet with combination of 4 Address Option headers and 3 Frag-
mentation headers.
• FW23 Only first two fragments out of three have the value of Next header field set
at TCP.
• FW24 Next header of the first fragment is set at ICMPv6, of the second at TCP.
• FW25 The first two fragments are overlapping. Fragments are filled with Address
Option headers.
• FW26 The packet is sent in three fragments. Next header of the first one is set at
ICMPv6, the remaining two are set at TCP.
• FW27 The first of the three fragments has Next header set at TCP, the remaining
two are set at ICMPv6.
• FW28 The last two fragments are overlapping.
• FW29 The ICMPv6 “ping” packet is fragmented and first fragment is overlapped by
the second.
• FW30 The ICMPv6 “ping” packet is fragmented into three parts and the second
fragment is overlapped by the third.
• FW31 In the fragment chain, after the second fragment the following one is sent
with the same ID and completely overlaps the second fragment, while it is identical
with the overlapped one except the altered Data Payload at the end of the fragment.
• FW32 Several packets with different source ports are sent.
After The Hacker’s Choice IPv6 Toolkit installation the complete test set can be
easily launched from the command line by

The individual operating systems results and their firewalls tested by firewall6 tool
are presented in the Table 2. As we already stated, all the traffic was generated as TCP
traffic with destination port 22. This combination of the port and the protocol was
always explicitly blocked. Successful packet/s blocking is indicated by Y, bypass of the
firewall rules is NO. Since all the systems of the MS Windows family rendered same
results, they are condensed into single column in the table.
The majority of the firewalls passed the tests with a clean slate. Detailed log
analysis of the individual firewalls reveals that some types of fragmented traffic always
passes through, however they are correctly not reassembled and system does not
respond to them. This can be considered as a satisfactory result and these cases are
evaluated as such in the Table 2. Firewall IP Filter had problems with some of the
testing scenarios. The firewall is used by NetBSD and Oracle Solaris systems, whereas
it has problems in different scenarios in each system. Over Oracle Solaris IP Filter does
not manage correct atomic fragments processing, in NetBSD it does not manage the
work with certain combinations of extended headers and both variants of overlapping
ICMPv6 “ping.” When sending packets with different source ports in both systems,
some of the source ports were blocked while others were not. Moreover, the behaviour
is inconsistent among both systems. Packets with source ports 21, 179, 443 and 8080
226 J. Horalek and V. Sobeslav

Table 2. The results for firewall 6

MS Debian Ubuntu Fedora CentOS FreeBSD OpenBSD NetBSD Solaris
Windows 14.04 21
FW1 Y Y Y Y Y Y Y Y Y
FW2 Y Y Y Y Y Y Y Y Y
FW3 Y Y Y Y Y Y Y Y Y
FW4 Y Y Y Y Y Y Y Y Y
FW5 Y Y Y Y Y Y Y Y Y
FW6 Y Y Y Y Y Y Y Y Y
FW7 Y Y Y Y Y Y Y Y Y
FW8 Y Y Y Y Y Y Y Y Y
FW9 Y Y Y Y Y Y Y Y Y
FW10 Y Y Y Y Y Y Y Y NO
FW11 Y Y Y Y Y Y Y Y NO
FW12 Y Y Y Y Y Y Y Y NO
FW13 Y Y Y Y Y Y Y Y NO
FW14 Y Y Y Y Y Y Y Y NO
FW15 Y Y Y Y Y Y Y Y NO
FW16 Y Y Y Y Y Y Y Y Y
FW17 Y Y Y Y Y Y Y Y Y
FW18 Y Y Y Y Y Y Y NO Y
FW19 Y Y Y Y Y Y Y NO Y
FW20 Y Y Y Y Y Y Y NO Y
FW21 Y Y Y Y Y Y Y NO Y
FW22 Y Y Y Y Y Y Y NO Y
FW23 Y Y Y Y Y Y Y Y Y
FW24 Y Y Y Y Y Y Y Y Y
FW25 Y Y Y Y Y Y Y Y Y
FW26 Y Y Y Y Y Y Y Y Y
FW27 Y Y Y Y Y Y Y Y Y
FW28 Y Y Y Y Y Y Y Y Y
FW29 Y Y Y Y Y Y Y NO Y
FW30 Y Y Y Y Y Y Y NO Y
FW31 Y Y Y Y Y Y Y Y Y
FW32 Y Y Y Y Y Y Y NO NO

were blocked over NetBSD, where in case of Oracle Solaris it was ports 53, 80, 111,
123, 179, 443 a 8080. This can not be considered as a good result, we can imagine e.g.
misuse for so called “OS fingerprinting,” meaning remote identification of the oper-
ating system running on the given host, which represents certain security risk because
attacker can acquire more in-depth information about the potentional target of the
attack. Then he can more accurately select means of the attack, for example by use of
known security holes of the given operating system, even though one of the firewall
responsibilities is to defend unauthorized information drain.
 IPv6 Firewall Functions Analysis 227

4 Conclusion

The aim of the article was to map the firewall issue within the IPv6 environment.
Initially the current state of the issue was outlined building mainly on related RFC
documents. The selected IPv6 specification areas were introduced alongside the nec-
essary definitions of terms. IPv6 firewalls were then practically tested in virtualized
laboratory environment. Several host firewalls standardly distributed with selected
operating systems were tested. These firewalls will probably achieve even more sig-
nificant importance considering the return of the truly end-to-end connectivity idea.
Higher responsibility share in terms of security will be moved from centralized network
perimeter defence to individual hosts. Every firewall was subjected to a series of tests
via selected software tools. The tests were aimed at known problematic IPv6 specifi-
cation areas. The behavior of individual firewalls was recorded and discussed.
Taking everything into account it can be concluded that firewalls tested in the
aforementioned tests by means of firewall6 from The Hacker’s Choice IPv6 Toolkit
behaved inconsistently both between each other and in the relationship to relevant
RFC. In order to achieve more correct behaviour closer to RFC it is necessary to create
high-quality access control ruleset.

Acknowledgment. The support of Czech Science Foundation GACR 15-11724S DEPIES is

gratefully acknowledged.

References
1. RFC 2993 - architectural implications of NAT. http://tools.ietf.org/html/rfc2993
2. RFC 4864 - local network protection for IPv6. http://tools.ietf.org/html/rfc4864
3. RFC 4942 - IPv6 transition/co-existence security considerations. http://tools.ietf.org/html/
rfc4942
4. RFC 7059 - a comparison of IPv6-over-IPv4 tunnel mechanisms. http://tools.ietf.org/html/
rfc7059
5. RFC 6092 - recommended simple security capabilities in customer premises equipment
(CPE) for providing residential IPv6 internet service. http://tools.ietf.org/html/rfc6092
6. RFC 7123 - security implications of IPv6 on IPv4 networks. http://tools.ietf.org/html/
rfc7123
7. RFC 2460 - internet protocol, version 6 (IPv6) specification. http://tools.ietf.org/html/
rfc2460
8. RFC 5095 - deprecation of type 0 routing headers in IPv6. http://tools.ietf.org/html/rfc5095
9. RFC 5722 - handling of overlapping IPv6 fragments. http://tools.ietf.org/html/rfc5722
10. RFC 6946 - processing of IPv6 “atomic” fragments. http://tools.ietf.org/html/rfc6946
11. RFC 6980 - security implications of IPv6 fragmentation with IPv6 neighbor discovery.
http://tools.ietf.org/html/rfc6980
12. RFC 4443 - internet control message protocol (ICMPv6) for the internet protocol version 6
(IPv6) specification. http://tools.ietf.org/html/rfc4443
13. RFC 4890 - recommendations for filtering ICMPv6 messages in firewalls. http://tools.ietf.
org/html/rfc4890
228 J. Horalek and V. Sobeslav

14. RFC 5533 - Shim6: level 3 multihoming shim protocol for IPv6. http://tools.ietf.org/html/
rfc5533
15. RFC 6629 - considerations on the application of the level 3 multihoming shim protocol for
IPv6 (Shim6). http://tools.ietf.org/html/rfc6629
16. RFC 7112 - implications of oversized IPv6 header chains. http://tools.ietf.org/html/rfc7112
17. Kim, J., Cho, H., Mun, G., Seo, J., Noh, B., Kim, Y.: Experiments and countermeasures of
security vulnerabilities on next generation network. In: Future Generation Communication
and Networking (FGCN 2007) (2007)
18. Van Den Broek, G., van Rijswijk-Deij, R., Sperotto, A., Pras, A.: DNSSEC meets real
world: dealing with unreachability caused by fragmentation. IEEE Commun. Mag. 52, 154–
160 (2014)
19. Gont, F., Linkova, L.: IPv6 extension headers in the real world v2.0. (2016)
20. Lai, Y., Jiang, G., Li, J., Yang, Z.: Design and implementation of distributed firewall system
for IPv6. In: 2009 International Conference on Communication Software and Networks
(2009)