The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6
Transition Technologies
M. Georgescu, H. Hazeyama, T. Okuda, Y. Kadobayashi and S. Yamaguchi
Nara Institute of Science and Technology, 891-6 Takayama, Ikoma, Nara, Japan
IPv6 Transition Technologies, Threat Model, STRIDE, Dual-stack, Single Translation, Double Translation,
The IPv6 worldwide deployment rate is still a single figure. This is due to the many challenges introduced
by the transition period through which both IPv4 and IPv6 will need to coexist. One of the biggest concerns
related to the IPv6 transition is security, which is more difficult to ensure in a heterogeneous environment. To
clarify the security threats introduced by IPv6 transition technologies, this article proposes a comprehensive
threat model built around the established STRIDE approach. To verify the usefulness of the proposed model, a
threat analysis of four generic categories of IPv6 transition technologies is performed. Existing and new threats
are documented, classified and prioritized. To further validate some of the documented threats, preliminary
penetration test data is presented.
The IPv4 address space exhaustion is imminent and
can affect the further expansion of the Internet. The
Internet Assigned Numbers Authority (IANA) has al-
located on February 3rd 2011 the last blocks of IPv4
addresses (NRO, 2014). Four out of the five Regional
Internet Registries (RIR) have entered the last stage
of IPv4 exhaustion. A detailed report is presented in
(Huston, 2015) by APNIC’s G. Huston. IPv6 was in-
troduced in 1998. However, the IPv6 worldwide de-
ployment rate is still very low, approaching 5% as the
APNIC Labs (APNIC, 2015) report. The root cause
for this low deployment status is the lack of back-
wards compatibility between IPv6 and IPv4. In other
words, IPv4-only nodes and IPv6-only nodes cannot
communicate directly. That means transition mecha-
nisms have to be used and also that the Internet has to
undergo a period through which both protocols have
to coexist. This period can be simply referred as the
IPv6 transition.
Aside from the larger address space, IPv6 has,
in theory, a number of advantages over its predeces-
sor in terms of design: a more efficient and exten-
sible datagram, improved routing with easier route
computation and aggregation, stateless autoconfigu-
ration and mandatory security. Over the years, how-
ever, some of these new features have proved to be ei-
ther challenges for enforcing security (e.g. extension
headers, stateless autoconfiguration), or not-feasible
(e.g. widespread deployment of IPv6 with IPsec).
The IPv6 transition has further aggravated these chal-
lenges as transition technologies are generally ex-
posed to the threats associated with both IP versions
and hybrid blends, depending on the subcomponents.
When building an IPv6 transition plan, security
is arguably the biggest concern for network opera-
tors, as a heterogeneous IPv4 and IPv6 environment
greatly increases the attack surface. To that end,
building a threat model for IPv6 transition technolo-
gies can help clarify and categorize the associated se-
curity threats. In turn, this should facilitate the search
for mitigation techniques and can lead to a security
quantification method for IPv6 transition implemen-
tations. Considering all of the above, this article pro-
poses a threat model built around the well established
STRIDE approach described in (Hernan et al., 2006).
The STRIDE mnemonic is used to classify the doc-
umented threats. The correlations between elements
of the Data Flow Diagrams (DFD) and the STRIDE
threat categories detailed in (Hernan et al., 2006) are
used for the initial basic assessment of the threats for
each of the sub-elements.
The generic STRIDE approach represents only the
base of our proposal. The main contribution lies in
identifying the threat modeling steps necessary for
IPv6 transition technologies in particular. To prove
the validity of the proposal, the model is used to de-
Georgescu, M., Hazeyama, H., Okuda, T., Kadobayashi, Y. and Yamaguchi, S.
The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6 Transition Technologies.
DOI: 10.5220/0005652402430254
In Proceedings of the 2nd International Conference on Information Systems Security and Privacy (ICISSP 2016), pages 243-254
ISBN: 978-989-758-167-0
2016 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
fine and categorize existing and new threats for the
four generic types of IPv6 transition technologies.
The resulting non-exhaustive threat analysis and pen-
etration test data can be considered another important
part of the contribution of this work.
The rest of the paper is organized as follows: Sec-
tion 2 gives an overview of IPv6 transition technolo-
gies, Section 3 presents related literature, in Section
4, we introduce the proposed threat model, section 5
discusses our approach and lastly section 6 states the
IPv6 was not designed to be backwards compatible.
Consequently, in a heterogeneous environment coex-
istence and transition technologies need to be em-
ployed. Initially, three basic transition mechanisms
were proposed: dual-stack, translation and tunnel-
ing. The associated implementation standards are pre-
sented in RFC 4213 (Nordmark and Gilligan, 2005)
and RFC 6144 (Baker et al., 2011).
For dual-stack, IPv4 and IPv6 are implemented on
the same node. This method is used mostly for host-
side nodes and edge nodes. The biggest challenge
introduced by dual-stack is overhead. Translation is
the only method which ensures direct communication
between IPv4 and IPv6 by translating the message
format and information between different versions of
Internet Protocol. The complication introduced by
translation is breaking the end-to-end characteristic
of the Internet, something that IPv6 was supposed
to bring back. Tunneling or encapsulation is used
to traverse heterogeneous network environments, by
encapsulating the IPvX packets into the payload of
IPvY packets, where X,Y {4, 6}. At the border of
the IPvY and IPvX networks the packets are decap-
sulated back into IPvX by an edge router. Tunneling
mechanisms are mainly confronted with fragmenta-
tion problems because of encapsulation.
In an attempt to compensate for the design sim-
plicity of the two IP versions, IPv6 transition tech-
nologies grew in complexity. Most of the modern
transition technologies use one or more basic tran-
sition technologies. For instance, Dual-Stack Lite
(DSLite)(Durand et al., 2011) used dual-stack and
translation at the edge nodes and encapsulation in the
core. Considering all of the above, a generic classifi-
cation of the transition technologies can prove useful.
2.1 IPv6 Transition Technologies
Generic Categories
We can consider a basic production IP-based network
as being constructed using the following components:
Customer Edge (CE) segment: connects the cus-
tomer network to the production network’s core.
Core network segment: the main part of the pro-
duction network, which connects the CE and PE
Provider Edge (PE) segment: connects the core
network to the up-link provider.
According to the technology used for the core net-
work traversal, the IPv6 transition technologies can be
categorized as follows:
1. Dual-stack: the core network devices implement
both IP protocols
2. Single translation: either IPv4 or IPv6 is used to
traverse the core network, and translation is used
at one of the edges
3. Double translation: a translation mechanism is
employed for the traversal of the core network;
CE nodes translate IPvX packets to IPvY packets
and PE nodes translate the packets back to IPvX.
4. Encapsulation: an encapsulation mechanism is
used to traverse the core network; CE nodes en-
capsulate the IPvX packets in IPvY packets, while
PE nodes are responsible for the decapsulation
Table 1 shows how some of the existing IPv6 transi-
tion technologies can fit into the generic categories.
Threat models have been proposed and used for the
security analysis of online applications for some time.
Probably the most popular is the one introduced in
(Hernan et al., 2006), more commonly known as
the STRIDE approach. At the heart of the pro-
posal is the STRIDE mnemonic, which stands for
Spoofing, Tampering, Repudiation, Information dis-
closure, Denial of service and Elevation of privilege,
a set of generic security threats. The mnemonic offers
a simple and comprehensible classification base. Us-
ing STRIDE in conjuncture with a good understand-
ing of the system’s components, can result in a good
overview of the threats and possible mitigation direc-
tions. As a measure of its success, the STRIDE cate-
gories are used as well in (OWASP, 2015), the threat
ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy
Table 1: IPv6 transition technologies association.
Generic category IPv6 Transition Technology
1 Dual-stack Dual IP Layer Operations(Nordmark and Gilligan, 2005)
2 Single translation NAT64(Bagnulo et al., 2011), SIIT-DC(Anderson, 2015), SA46T-AT(Matsuhira, 2015), IVI(Li et al., 2011b)
3 Double translation 464XLAT(Mawatari et al., 2013), MAP-T(Li et al., 2015), dIVI(Bao et al., 2014)
4 Encapsulation DSLite(Durand et al., 2011), Lightweight 4over6(Tsou et al., 2015), MAP-E(Troan et al., 2015)
modeling process used by the Open Web Application
Security Project (OWASP). Furthermore, in (Gervais,
2012), the STRIDE approach has been used to model
the threats of industrial control systems.
As for the security of IP-based systems, there are
many articles in current literature dedicated to the is-
sues introduced by IPv4 and IPv6. In terms of IPv4
security, we have consulted the following references:
(Harris and Hunt, 1999), (Gont, 2011),(Low, 2001),
(Abad et al., 2007), (Khallouf et al., 2005). As for
IPv6 security, the following documents were very
helpful: (Davies et al., 2007), (Convery and Miller,
2004), (Pilihanto, 2011). These documents have done
a fine job of documenting existing threats for the two
protocols and basic transition mechanisms. However,
a threat model for IPv6 transition technologies has not
emerged so far.
Threat modeling has proved useful for under-
standing the security of intricate systems. The main
reason is its structured approach, which allows one to
discover, categorize and classify the threats accord-
ing to their potential impact on the system. Consid-
ering the complicated nature of IPv6 transition tech-
nologies, threat modeling makes a good candidate for
better understanding their security implications. The
proposed model aims to open this path, which could
lead as well to a better understanding of the inner-
workings of IPv6 transition technologies.
The proposed threat model involves a series of
steps which were inspired by the STRIDE model-
ing approach presented in (McRee, 2009) and the
Open Web Application Security Project (OWASP)
foundation’s application threat modeling guidelines
(OWASP, 2015). In the context of IPv6 transition
technologies we recommend the following steps.
(1) Establish the Function: the function of the
IPv6 transition technology needs to be clearly doc-
umented. Depending on the context, the technol-
ogy can incorporate multiple services, which need to
be clearly identified in order to perform an effective
threat analysis.
(2) Identify the IPv6 Transition Technology
Category: the category should be identified consid-
ering the generic classification defined in Section 2.1.
This step will help build the data flow diagram (DFD)
used in the following steps.
(3) Decompose the Technology: build a data
flow diagram (DFD) and highlight the entry points,
protected resources and trust boundaries. The entry
points should be assigned a level of trust consider-
ing the trust boundaries. The external entities, pro-
cess, data store and data flow elements should be
depicted in the same diagram as defined in (Hernan
et al., 2006). The IP protocol suite and the protocols
used for the designated function should be identified
as well. This can narrow down the attack surface.
(4) Identify the Threats: The STRIDE model as-
sociates the six categories of threats to each of the
elements described in the DFD. Based on this asso-
ciation, we get an initial assessment of the threats as
shown in Table 2. To clarify, a data flow, for example,
is more susceptible to tampering, information disclo-
sure and denial of service threats. The initial threat
assessment must be followed by a detailed analysis
which should consider the protocols used in conjunc-
ture with the transition technology.
Considering the level of trust assigned to each en-
try point, an associated likelihood of attack from that
entry point can be deduced. For example, if the en-
try point is considered trusted, we can assume the
likelihood of an attack is low. By extrapolating, the
six categories of STRIDE attacks could be assigned
a likelihood, considering that their association with
the DFD elements that are entry points. For instance,
if we have an untrusted entry point which is also an
external entity, for which we can have spoofing and
repudiation as potential threats, the two types of at-
tacks can be considered to have a high likelihood, as
they would be exploited from an untrusted entry. Us-
ing this logic, by associating the detailed threats with
the STRIDE model and the DFD elements they could
be applied to, we can assign each threat a likelihood
value. This can represent a base for prioritizing mit-
igation solutions. Each discovered threat should be
documented by using the following format.
Field Name Description
Threat ID A code associated with each identified threat
Description A summarized description of the threat
STRIDE The association with the STRIDE categories
Mitigation Details about existing mitigation solutions
Likelihood Likelihood of the threat being exploited
Validation Empirical validation data
For an easy reference in future publications the
[Threat ID] should follow the format: [Code]-[First
The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6 Transition Technologies
Table 2: STRIDE threats per element.
Spoofing Tampering Repudiation Info Disclosure Denial of Service Elevation of Privilege
Data Store
Data Flow
Author Initials]-[Publication Submission Year]-
[Serial number]. For an author named John Doe,
who is submitting a publication proposal in 2015, an
example ThreatID is: IPv6-JD-2015-1. The serial
number is incremented with each threat found for
a particular protocol or technology. A list of codes
for the basic transition technologies and generic
transition technologies can be found in the Appendix,
Table 4. For the well-known TCP/IP protocol suite
we have used the usual acronyms as codes. As the
subcomponents interact and the used protocols stack,
the threats can fuse and result in convoluted threats
with a higher likelihood of exploitation. Depending
on the list of discovered threats, the possibility of a
fusion between threats should be analyzed.
(6) Review, Repeat and Validate: steps 1 and
3 have to be reviewed in the context of potential
changes in the technology function and associated
protocols. Step 4 should be repeated periodically, as
threats may have been overlooked, or the context set
by steps 1 and 3 may have changed. If the transition
technologies have existing implementations, the anal-
ysis should be confirmed with empirical data. To that
end, penetration testing can be used.
In the following subsections, the proposed threat
modeling technique is used for the four generic IPv6
transition technologies categories defined in Section
2.1. The threat models can be viewed as a starting
point for IPv6 transition technologies associated with
each category.
4.1 Dual-stack IPv6 Transition
4.1.1 Establish the Function
The function for dual-stack transition technologies is
to ensure a safe data exchange over a dual-stack in-
frastructure. In other words, the data can be trans-
fered over both IPv4 and IPv6. From a network ser-
vice perspective, the main function is data forward-
ing. This includes interior gateway routing solutions.
We start with the assumption that services such as ad-
dress provision, DNS resolution or exterior gateway
routing are performed by other nodes within the core
network. This assumption in common for all the four
generic categories of IPv6 transition technologies.
Data store
Trust boundary
Data over
Data store
Customer side
Provider side
Production core
P - protected asset
E - entry point
P, E
P, E
P, E
Data flow
Data over
Data over
Data over
(a) Dual-stack
Data over
Data store
Customer side
Provider side
Production core
P, E
P, E
P, E
Data over
Data over
Data over
(b) Single translation
Data over
Data store
Customer side
Provider side
Production core
P, E
P, E
P, E
Data over
Data over
Data over
P, E
Data over
Data over
(c) Double translation
Data over
Data store
Customer side
Provider side
Production core
P, E
P, E
P, E
Data over
Data over
Data over
P, E
Data over
Data over
(d) Encapsulation
Figure 1: Data Flow Diagrams for the generic IPv6 transi-
tion technologies categories.
4.1.2 Identify the IPv6 Transition Technology
This step is meant for more specific transition tech-
nologies. Since we are targeting the generic category
itself, the step is unnecessary here. This stands for the
other three categories as well.
4.1.3 Decompose the Technology
A DFD for dual-stack transition technologies is pre-
sented in Figure 1(a). The diagram represents the ba-
sic use case and includes a minimal set of elements.
On the customer side, we have a Customer Device
which initiates the data exchange. It represents one
of the entry points of the system and contains im-
ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy
v6 NIC
v4 NIC
v4 NIC
v6 NIC
asamap vyatta
Kali Linux
asamap vyatta
Figure 2: MAP-T Penetration Testbed
portant data, which should be regarded as an asset
and protected. The Customer Device is regarded as
an external element because it is outside the control
zone of the production network. The data request is
transmitted over IPv4 or IPv6 to a Dual-stack node.
The Dual-stack node is another entry point and con-
tains valuable topology information which should to
be protected as well. The Dual-stack node forwards
in turn the data request to the provider data store. The
Data store is another entry point in the system and it
is assumed to contain valuable data. The data reply
is forwarded back and makes its return on the same
The only trusted entry point in the system is the
Dual-stack node. The other two entry points are con-
sidered untrusted, since they are outside the control
of the production network.That means they can be ex-
ploited with a higher likelihood by an attacker. Con-
sidering the data can be transferred over both IPv4
and IPv6, we need to consider IP protocol suites. Fur-
thermore, the possibility of using security and routing
protocols should be considered.
4.1.4 Identify the Threats
By analyzing the DFD in association with the
STRIDE threats per element chart, we can observe
that the Customer Device can be subject to spoofing
and repudiation attacks. It being an untrusted entry
point, it means there is a high likelihood of an attack.
The Dual-stack node can be subject to all six types of
attacks. However, the likelihood of that happening is
low, considering it is a trusted entry point. The Data
flow is vulnerable to tampering, information disclo-
sure and denial of service. Considering it traverses
untrusted parts of the system, the level of likelihood
of an attack on the data flow is high. Lastly, the Data
store could potentially be targeted by tampering, re-
pudiation, information disclosure and denial of ser-
vice attacks. The likelihood for these to happen is
high as well, the data store being an untrusted entry
Tables 5,7, 6, 8, 9 and 10 of the Appendix contain
a non-exhaustive collection of existing threats, which
have been collected by surveying a part of existing
literature on this subject. For further documentation,
each threat has been provided with a reference in the
first column. For reuse purposes, the threats are orga-
nized according to the categories of protocols which
would be necessary for accomplishing the function of
the IPv6 transition technologies.
For dual-stack transition technologies the proto-
col threats associated with the IPv4 suite (Table 5),
IPv6 suite(Table 7), routing (Table 8) and switching
(Table 10) could potentially be exploited from the 3
entries of the system: the untrusted - High likeli-
hood of exploitation Customer device (External en-
tity), trusted - Low likelihood of exploitation Dual-
stack node (Process) and untrusted - High likelihood
of exploitation Provider Data store (data store).
The IPv4 suite, transport layer and most of the
IPv6 suite protocols are associated with all the ele-
ments of the DFD. By extrapolation, their threats have
a high likelihood of occurrence. Some of the IPv6
protocol threats (Table 7), namely ND-MG-2015-3 to
ND-MG-2015-6 and the Layer 2 technologies’ threats
(Table 10) can only be associated with routers or
switches. In this context, they could only be associ-
ated with the Dual-stack node. That means they have
a low likelihood of occurrence. Similarly, the routing
protocols can only be associated with the Dual-stack
node. By association, they also have a low likelihood
of being exploited.
By analyzing the interaction between the three el-
ements of the DFD (Figure 1(a)) and the protocols
used by Dual stack transition technologies, we can
uncover other threats. For example, if the ARP-MG-
2015-1(ARP cache poisoning) is used to perform a
Denial of Service attack on the Dual-stack node from
the Customer device, the likelihood of exploitation
rises for the ND-MG-2015-10 (ND Replay Attacks)
threats. Table 7. ARP-MG-2015-1 could be replaced
by any other DoS threat associated with the IPv4 suite
protocols. This complex threat could only be pre-
vented by ensuring that the IPv4 suite DoS threats are
properly mitigated. Examples of convoluted threats
for the four generic IPv6 transition technologies are
presented in Table 3.
Another convoluted threat can result from exploit-
ing IPv4 or IPv6 spoofing threats to increase the like-
lihood of an attack on routing protocols with sim-
ple authentication, such as or OSPFv3-MG-2015-1,
OSPFv2-MG-2015-1 or RIPv2-MG-2015-1. Since
the attack could be performed from an untrusted entry
point (Customer device or Data store), the likelihood
of the threat being exploited rises to High. This type
of attack can be mitigated by using cryptographic au-
thentication for the routing protocols.
The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6 Transition Technologies
Table 3: Generic IPv6 Transition Technologies Convoluted Threats.
ThreatID Description S T R I D E Mitigation Validation
Generic IPv6 Transition Technologies
1 DS -MG-2015-1 ARP-MG-2015-1 + ND -MG-2015-10 H H H H H
Ensure DoS mitigation for
IPv4 suite protocols; use SEND
2 DS-MG-2015-2 ARP-MG-2015-1 + OSPFv3-MG-1 H H H H H H Use OSPv3 with IPsec
3 1transl -MG-2015-1 IP/ICMP -MG-2015-3 + ND-MG-2015-5 H H H H No widely accepted mitigation X
4 1transl -MG-2015-2 TCP-MG-2015-1 + ND-MG-2015-10 H H H H H
Block packets with non-internal
addresses; use SEND
5 2transl -MG-2015-1 IP/ICMP -MG-2015-4 + ND -MG-2015-4 H H H H H No widely accepted mitigation X
6 2transl -MG-2015-2 IP/ICMP-MG-2015-4 + OSPFv3-MG-2015-1 H H H H H H OSPFv3 with IPsec
7 encaps -MG-2015-1 IPv6-MG-2015-1 + 4encaps -MG-2015-1 H H
Use IPv4 firewall before
L Associated with low likelihood of exploitation H Associated with high likelihood of exploitation
The list of threats can help technology implemen-
tors and network operators alike prioritize the threats
and mitigate accordingly. The protocols which have
threats with no widely accepted mitigation techniques
have been highlighted and should be treated as first
4.1.5 Review, Repeat and Validate
This step is necessary if the technology analyzed or
associated protocols change. For example if the rout-
ing system were to be only OSPFv3, then the threats
associated with other routing protocols could be ig-
nored. Also, the detailed analysis of threats is far
from exhaustive. In terms of convoluted new threats,
only a few are presented as an example. If this
was to be an updated database of threats, it would
need constant update. To further validate the pre-
sented threats, a simple penetration testbed was built.
The details of the testbed are presented in Figure
2. MAP-T (Li et al., 2015) was used as transition
technology. Asamap (Asama, 2014), a transition im-
plementation developed in Japan, was used as the
base for MAP-T. The threats which were successfully
emulated, have been marked accordingly in the last
column of Table 3. In the case of the convoluted
threats identified for Dual-stack transition technolo-
gies, both threats were emulated successfully by per-
forming ARP Cache Spoofing, Neighbor Advertise-
ment (NA) flooding and simple traffic analysis.
4.2 Single Translation Transition
To avoid redundant information, the following three
subsections will only mark the differences with the
threat modeling process presented for Dual-stack
transition technologies.
One of the fundamental differences is that the sin-
gle translation technologies would require a node to
algorithmically translate the IPvX packets to IPvY, as
shown in Figure 1(b). For both translation directions
(4 6 and 6 4) the threats for the IPv4 suite (Table
5), IPv6 suite (Table 7), routing (Table 8) and switch-
ing (Table 10) should be considered.
There are technologies that use stateful mapping
algorithms e.g. Stateful NAT64 (Bagnulo et al.,
2011), which create dynamic correlations between IP
addresses or {IP address, transport protocol, transport
port number} tuples. Consequently, we need to con-
sider the protocols used at the transport layer (Table
6) as part of the attack surface. The threats presented
in Table 9, associated with the IP/ICMP translation
algorithm (IP/ICMP), should be considered as well.
In terms of convoluted threats, one example could
be exploiting the IP/ICMP-MG-2015-3 threat (IPAuth
does not work with IP/ICMP) which would increase
the likelihood of ND-MG-2015-4 (Default router is
killed) or ND-MG-2015-5 (Good router goes bad)
threats being exploited. Since there is no widely-
accepted mitigation for any of the three threats, this
convoluted threat is laking a mitigation solution as
well. Fortunately, both complex threats could not
be validated empirically. An IPsec VPN connec-
tion was successfully established using UDP encap-
sulation between the Windows Host and the Ubuntu
Server. Moreover, the ND-MG-2015-4 and ND-MG-
2015-5 could not be validated empirically, as Asamap
(Asama, 2014) does not accept RA messages when
IPv6 forwarding is enabled.
If the TCP-MG-2015-1 threat (SYN flood) is ex-
ploited from an untrusted entry point, it increases the
likelihood of a ND-MG-2015-10 (ND Replay attacks)
threat. This threat can be mitigated by blocking pack-
ets with non-internal addresses from leaving the net-
work. Both the SYN flood attack and the Neigh-
bor Advertisement (NA) flooding attacks were staged
4.3 Double Translation Transition
The main difference between the Single translation
case and the double translation case is the need for
ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy
an extra translation device as part of the core net-
work (Figure 1(c)). Another important difference
would be that in the untrusted zone, the Customer de-
vice and Data store would employ the same IP suite.
Hence, the considered threats for the untrusted ele-
ments would be either the IPv4 suite (Table 5) or the
IPv6 suite (Table 7) protocol threats. Similar to the
single translation technologies, the routing (Table 8),
switching (Table 10), transport layer (Table 6) and
IP/ICMP (Table 9) threats should be analyzed as well.
The use of stateful translation mechanisms can ex-
pose a double translation technology to the IP/ICMP-
MG-2015-4 threat (DoS by exhaustion of resources).
A convoluted threat can result by exploiting this threat
on one of the translators and the ND-MG-2015-4 or
ND-MG-2015-5 threats on the other translator. This
threat would have a higher likelihood of exploita-
tion since it is associated with an untrusted entry
point. In terms of mitigation, further investigation
is needed, as there are no widely accepted mitiga-
tion techniques. Although the IP/ICMP-MG-2015-
4 threat was replicated with success, the ND-MG-
2015-10 or ND-MG-2015-5 could not be emulated
because of a simple built-in mitigation mechanism
implemented by Asamap (Asama, 2014). Router ad-
vertisement (RA) messages are not accepted while in
IPv6 forwarding mode.
The IP/ICMP-MG-2015-4 threat can also fuse
with the simple authentication threats such as
OSPFv3-MG-2015-1 , OSPFv2-MG-2015-1 or
RIPv2-MG-2015-1 to affect both translating nodes.
The likelihood of the threats become higher by fusing
them, since the flooding attack can be performed
from an untrusted entry point, the customer network.
This threat could be mitigated by using cryptographic
authentication or implementing reverse path checks.
The convoluted threat was validated by flooding the
translation table of the first translator and forcing it to
crash. OSPFv3 information disclosure was emulated
with simple traffic analysis. To validate the other
types of threats, a rogue router instance was created
using Asamap.
4.4 Encapsulation Transition
Similar to double translation IPv6 transition tech-
nologies, encapsulation technologies, the core net-
work traffic is forwarded through at least two de-
vices, an Encapsulator and a Decapsulator (Figure
1(d)). As the main difference, the traffic is encap-
sulated. This means more overhead but also more
support for end-to-end security protocols. Packets
are encapsulated either over IPv4 or IPv6. Conse-
quently, for the untrusted domain devices we would
consider either the IPv4 suite (Table 5) or the IPv6
suite (Table 7) threats. In addition the routing (Ta-
ble 8), switching (Table 10), transport layer (Table 6)
and encapsulation-related (Table 9) threats should be
Convoluted threats can arise by exploiting the
4encaps-MG-2015-1 threat (avoiding IPv4 network
security measures with encapsulation). This threat
can facilitate IPv6 suite DoS threats on the Decapsu-
lator device. This convoluted threat would increase
the likelihood of a successful DoS attack from the
Customer Device. The threat could be mitigated by
making use of an IPv4 firewall before decapsulating
the packets.
The security of IPv6 transition technologies, as the
technologies themselves, are hard to grasp and ana-
lyze. Although many documents have targeted dif-
ferent aspects of the security of these technologies,
a comprehensive threat model has not been proposed
yet. With this article, we want to take a first step in
that direction. Our approach is built around the well-
established STRIDE model, which has proved to be
an adaptive tool for threat modeling. We have used
the proposed threat model to analyze the security is-
sues of the generic IPv6 transition technologies de-
fined in Section 2.1.
One of the limitations of the proposed threat
model is the lack of specificity of the scenario. How-
ever, given the diversity of existing production net-
work this would be close to impossible. This is why
we targeted a very common use case of production
networks and a very basic network function for the
IPv6 transition technologies. The model is a starting
point, which we hope to keep developing in the future.
This hindrance can be extended to the generic
IPv6 transition technologies. However, by being in-
clusive, rather than specific and exclusive, we contend
that the proposed threat model can be applied to most
of the existing IPv6 transition technologies and their
future developments.
The use of STRIDE for IPv6 transition technolo-
gies can be another discussion point. One can claim
that Elevation of Privilege or Repudiation threats are
not exploitable at the level the transition technolo-
gies are used. However, we contend that these threats
are indeed plausible. For instance, by exploiting a
VLAN Hopping threat, an attacker can violate the
isolation principle and by extension perform an ele-
vation of privilege attack. In terms of repudiation, an
The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6 Transition Technologies
attacker could perform a router impersonation attack
and cover his tracks.
A more fundamental hindrance of the approach is
represented by the lack of an associated risk quantifi-
cation step. However, we believe this step to have
deeper implications, particularly implementation-
specific details which should be considered as well.
This motivates us to continue this work by associat-
ing a risk quantification technique to the current threat
model. To that end, staging penetration tests to em-
pirically validate the threats discovered analytically
could also be employed to quantify the risk associated
with particular implementations.
In this article, we have proposed a wide-ranging threat
model for IPv6 transition technologies. As part of
the contribution, this article also provides a mean to
generically classify IPv6 transition technologies. To
prove the adequacy of the proposed threat model, we
have used it to analyze the security threats of the four
generic categories of IPv6 transition technologies.
As part of the threat modeling process, for each
of the four categories we have defined a common use
case, deconstructed the system using Data Flow Di-
agrams (DFDs), and obtained an initial overview of
the security threats by association with the STRIDE
approach. Subsequently, we have documented exist-
ing threats and mitigation solutions for the IP protocol
suites and basic transition technologies representing
dependencies of the system. The documented threats
have been mapped with the STRIDE elements identi-
fied in the DFD, to obtain a rough likelihood for the
threats to be exploited. We have shown how existing
threats can lead to new threats by the interaction be-
tween subcomponents and various protocols. Lastly,
we have empirically validated some of the analyti-
cally discovered threats by building a simple penetra-
tion testbed.
As a summary, the proposed, holistic threat model
has revealed that the concerns related to the security
of IPv6 transition technologies are well-endowed. Al-
though it is too early to say that certain technologies
are more secure than others, we contend that the pro-
posed method can represent the basis for establishing
a methodology that can lead us there. As a general
observation for double translation and encapsulation
technologies, the lack of shared secrets between the
CE and PE devices can have serious consequences on
the core network exploit-ability.
The main contribution of this article is represented
by the proposed threat model. As shown, the threat
model can be used to classify and prioritize already
documented threats. Moreover the threat model can
help discover new threats and indicate their level of
mitigation. As a secondary contribution , this arti-
cle contains a non-exhaustive database of documented
threats associated with IP enabled devices. Moreover,
preliminary penetration test data was introduced for
one of the existing IPv6 transition implementations.
We contend that this approach can be the starting
point for analyzing the threats of specific IPv6 transi-
tion technologies. Moreover, we intend to extend this
work by proposing a risk quantification technique,
which should lead to a security quantification method
for IPv6 transition technologies. The first steps in this
direction were taken by proposing penetration testing
as a validation technique. Although the presented data
is preliminary, we aim to continue this effort in future
This research has been supported by the Strategic
International Collaborative R&D Promotion Project
of the Ministry of Internal Affairs and Commu-
nication, Japan, and by the European Union Sev-
enth Framework Programme (FP7/2007- 2013) under
grant agreement No. 608533 (NECOMA). The opin-
ions expressed in this paper are those of the authors
and do not necessarily reflect the views of the Min-
istry of Internal Affairs and Communications, Japan,
or of the European Commission.
Abad, C. L., Bonilla, R., et al. (2007). An analysis on
the schemes for detecting and preventing arp cache
poisoning attacks. In Distributed Computing Sys-
tems Workshops, 2007. ICDCSW’07. 27th Interna-
tional Conference on, pages 60–60. IEEE.
Anderson, T. (2015). SIIT-DC: Stateless IP/ICMP Trans-
lation for IPv6 Data Centre Environments. draft-ietf-
APNIC (2015). IPv6 measurements for The World.
Arkko, J., Kempf, J., Zill, B., and Nikander, P. (2005). SE-
cure Neighbor Discovery (SEND). RFC 3971 (Pro-
posed Standard). Updated by RFCs 6494, 6495.
Asama, M. (2014). MAP supported Vyatta [Online]. Avail-
Atkinson, R. and Fanto, M. (2007). RIPv2 Cryptographic
Authentication. RFC 4822 (Proposed Standard).
Bagnulo, M., Matthews, P., and van Beijnum, I. (2011).
Stateful NAT64: Network Address and Protocol
Translation from IPv6 Clients to IPv4 Servers. RFC
6146 (Proposed Standard).
ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy
Baker, F., Li, X., Bao, C., and Yin, K. (2011). Framework
for IPv4/IPv6 Translation. RFC 6144 (Informational).
Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and Li,
X. (2010). IPv6 Addressing of IPv4/IPv6 Translators.
RFC 6052 (Proposed Standard).
Bao, C., Li, X., Zhai, Y., and Shang, W. (2014). dIVI: Dual-
Stateless IPv4/IPv6 Translation. draft-xli-behave-
Bellovin, S. M. (1989). Security problems in the tcp/ip
protocol suite. SIGCOMM Comput. Commun. Rev.,
Conta, A. and Gupta, M. (2006). Internet control message
protocol (icmpv6) for the internet protocol version 6
(ipv6) specification. RFC 4443 (Proposed standard).
Convery, S. and Miller, D. (2004). Ipv6 and ipv4 threat
comparison and best-practice evaluation.
Davies, E., Krishnan, S., and Savola, P. (2007).
IPv6 Transition/Co-existence Security Considera-
tions. RFC 4942 (Informational).
Durand, A., Droms, R., Woodyatt, J., and Lee, Y. (2011).
Dual-Stack Lite Broadband Deployments Following
IPv4 Exhaustion. RFC 6333 (Proposed Standard).
Garg, A. and Reddy, A. N. (2004). Mitigation of dos at-
tacks through qos regulation. Microprocessors and
Microsystems, 28(10):521–530.
Gervais, A. (2012). Security analysis of industrial control
systems. Aalto University-KTH Stockholm, Jun, 29.
Gont, F. (2011). Security assessment of the internet protocol
version 4. RFC 6274 (Informational).
Gupta, M. and Melam, N. (2006). Authentica-
tion/Confidentiality for OSPFv3. RFC 4552 (Pro-
posed Standard).
Harris, B. and Hunt, R. (1999). Tcp/ip security threats
and attack methods. Computer Communications,
Hernan, S., Lambert, S., Ostwald, T., and Shostack, A.
(2006). Threat modeling-uncover security design
flaws using the stride approach. MSDN Magazine-
Louisville, pages 68–75.
Huston, G. (2015). IPv4 Address Report.
ITU-T (2013). ITU-T Rec. X.1037 (10/2013) IPv6 techni-
cal security guidelines. Recommendation X.1037.
Khallouf, Z., Roca, V., Moignard, R., and Loye, S. (2005).
A Filtering Approach for an IGMP Flooding Resilient
Infrastrcuture. 4th Conference on Security and Net-
work Architectures(SAR’05), Batz sur Mer, France.
Li, X., Bao, C., and Baker, F. (2011a). IP/ICMP Translation
Algorithm. RFC 6145 (Proposed Standard). Updated
by RFC 6791.
Li, X., Bao, C., Chen, M., Zhang, H., and Wu, J. (2011b).
The China Education and Research Network (CER-
NET) IVI Translation Design and Deployment for the
IPv4/IPv6 Coexistence and Transition. RFC 6219 (In-
Li, X., Bao, C., Dec, W., Troan, O., , Matsushima, S., Mu-
rakami, T., and Taylor, T. (2015). Mapping of Address
and Port using Translation (MAP-T). RFC 7599 (Pro-
posed Standard).
Low, C. (2001). Icmp attacks illustrated. SANS Institute
URL: http://rr. sans. org/threats/ICMP attacks. php
Matsuhira, N. (2015). SA46T Address Translator. draft-
Mawatari, M., Kawashima, M., and Byrne, C. (2013).
464XLAT: Combination of Stateful and Stateless
Translation. RFC 6877.
McRee, R. (2009). IT Infrastructure Threat Modeling
Guide. Microsoft Technet.
Moy, J. (1998). OSPF Version 2. RFC 2328 (INTERNET
STANDARD). Updated by RFCs 5709, 6549, 6845,
Nikander, P., Kempf, J., and Nordmark, E. (2004). IPv6
Neighbor Discovery (ND) Trust Models and Threats.
RFC 3756 (Informational).
Nordmark, E. and Gilligan, R. (2005). Basic Transition
Mechanisms for IPv6 Hosts and Routers. RFC 4213
(Proposed Standard).
NRO (2014). Free Pool of IPv4 Address Space Depleted
[Online]. Available:
OWASP (2015). Application Threat Modeling. OWASP
Pilihanto, A. (2011). A complete guide on ipv6 attack and
defense. Sans. org [online].
Rouiller, S. A. (2003). Virtual lan security: weaknesses and
countermeasures. available at uploads. askapache.
com/2006/12/vlan-security-3. pdf.
Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Mu-
rakami, T., and Taylor, T. (2015). Mapping of Address
and Port with Encapsulation (MAP-E). RFC 7597
(Proposed Standard).
Tsou, T., Cui, Y., Boucadair, M., Farrer, I., and Lee, Y.
(2015). Lightweight 4over6: An Extension to the
Dual-Stack Lite Architecture. RFC 7596 (Proposed
Table 4: ThreatID Codes.
Basic IPv6 transition technologies
IP/ICMP Translation Algorithm RFC6145 IP/ICMP
Encapsulation of
IPv6 in IPv4
RFC4213 4encaps
Generic IPv6 transition technologies
Dual Stack - DS
Single Translation - 1transl
Double Translation - 2transl
Encapsulation - encaps
The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6 Transition Technologies
Table 5: IPv4 suite protocols threats.
ThreatID Description S T R I D E
# #
= = = =
IPv4 Suite Protocols
> > >
(Harris and Hunt, 1999)
IP source address spoofing H H H H
Apply ACLs and filter source address
routed traffic
(Gont, 2011)
Malformed version field H Version field must be checked to be 4
(Gont, 2011)
Packets with a forged DSCP
H H Filter packets with unrecognized DSCP
(Gont, 2011)
Buffer overflow with
IP fragmentation
IP module should implement measures to
avoid illegitimate reassembly
(Harris and Hunt, 1999)
Ping o’death H
Patch software to not accept oversized
ICMP messages
(Bellovin, 1989)
ICMP redirects H H H H H
routing tables should not be modified in
response to ICMP Redirect messages
(Low, 2001)
ICMP sweep for recon H Selective filtering of ICMP messages
(Low, 2001)
ICMP traceroute H Selective filtering of ICMP messages
(Low, 2001)
ICMP firewalk H Selective filtering of ICMP messages
(Low, 2001)
ICMP flooding H Selective filtering of ICMP messages
(Abad et al., 2007)
ARP cache poisoning H H H H H Static ARP entries, arpwatch
(Gont, 2011)
ARP cache overrun H Selectively drop packets
(Khallouf et al., 2005)
IGMP flooding H
selective filtering of IGMP messages,
multicast group authentication
associated with
High likelihood
# external, O process #
Untrusted element with High likelihood
of being exploited
associated with
Low likelihood
>data flow, = data store O
Trusted element with Low likelihood
of being exploited
Table 6: Layer4 Protocols Threats.
ThreatID Description S T R I D E
# #
= = = =
Transport Layer
> > >
(Harris and Hunt, 1999)
SYN flood H
Block packets with non-internal addresses
from leaving the network
(Harris and Hunt, 1999)
SYN/ACK flood H H H L3/L4 Packet Filtering
(Harris and Hunt, 1999)
ACK or ACK-PUSH Flood H H H L3/L4 Packet Filtering
(Harris and Hunt, 1999)
Fragmented ACK Flood H L3/L4 Packet Filtering
(Harris and Hunt, 1999)
TCP Spoofing based on
sequence number prediction
Block packets with non-internal addresses
from leaving the network
(Harris and Hunt, 1999)
TCP session hijacking based
on sequence number prediction
Block packets with non-internal addresses
from leaving the network
(Harris and Hunt, 1999)
L3/L4 Packet Filtering;
Stateful Flow Awareness
(Garg and Reddy, 2004)
UDP flood H QoS regulation; L3/L4 Packet Filtering
(ITU-T, 2013)
Port set exaustion H Address-Dependent Filtering
ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy
Table 7: IPv6 suite protocols threats.
ThreatID Description S T R I D E
# #
= = = =
IPv6 Suite
> > >
(Davies et al., 2007)
Routing header can be used to evade access
Access controls based on destination
(Davies et al., 2007)
Site-scope multicast addresses for
Drop packets with site-scope destination
(Davies et al., 2007)
Anycast traffic identification for
Restrict the use of outside anycast
(Davies et al., 2007)
Extension headers excessive hop-by-hop
H Drop packets with unknown options
(Davies et al., 2007)
Overuse of IPv6 router alert Option H
Filter externally generated Router
Alert packets
(Davies et al., 2007)
IPv6 fragmentation that would potentially
overload the reconstruction buffers
Mandating the size of packet fragments;
drop non-final fragments smaller
than 640 octets
(Davies et al., 2007)
IPv4-Mapped IPv6 Addresses H H
Avoid using IPv4-mapped IPv6
(Conta and Gupta, 2006)
ICMPv6 message spoofing H H Use IPAuth
(Conta and Gupta, 2006)
ICMPv6 Redirects H H H Use IPAuth or ESP
(Conta and Gupta, 2006)
Back-to-back erroneous IP packets H
Implement correctely ICMP error rate
limiting mechanism
(Conta and Gupta, 2006)
Send ICMP Parameter Problem
Message to the multicast source
H H Secure multicast traffic
(Conta and Gupta, 2006)
ICMP messages passed to the
H Use IPSec
(Pilihanto, 2011)
ICMPv6 echo request
for reconnaissance
H Deny inbound ICMPv6 echo request
(Davies et al., 2007)
Address Privacy Extensions Interact
with DDoS Defenses
Tune the change rate of the
node address
(Nikander et al., 2004)
Neighbor Solicitation/Advertisement
(Nikander et al., 2004)
Neighbor Unreachability Detection
(NUD) failure
(Nikander et al., 2004)
Malicious Last Hop Router L L L L L Use SEND
(Nikander et al., 2004)
Default router is ’killed’ L L L L L
No widely accepted mitigation
(Nikander et al., 2004)
Good Router Goes Bad L L L L L
No widely accepted mitigation
(Nikander et al., 2004)
Spoofed Redirect Message L L L L L
Still an issue for the ad-hoc case
(Nikander et al., 2004)
Bogus On-Link Prefix L Use SEND
(Nikander et al., 2004)
Bogus Address Configuration Prefix L
Still an issue for the ad-hoc case
(Nikander et al., 2004)
Parameter Spoofing L L L
Still an issue for the ad-hoc case
(Nikander et al., 2004)
ND Replay attacks H H
Use roughly synchronized clocks
and timestamps; Use SEND
(Nikander et al., 2004)
Neighbor Discovery DoS threat H Rate limit Neighbor Solicitations
(Nikander et al., 2004)
Duplicate Address Detection DoS H Use SEND
(Arkko et al., 2005)
The Authorization Delegation Discovery
process may be vulnerable to DoS
Cache discovered information and limit
the number of discovery processes
(Davies et al., 2007)
Obsolete Home Address Option
in Mobile IPv6
H Secure Binding Update messages
associaced with
High likelihood
# external, O process #
Untrusted element with High likelihood
of being exploited
associated with
High likelihood
>data flow, = data store O
Trusted element with Low likelihood
of being exploited
The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6 Transition Technologies
Table 8: Routing Protocols threats.
ThreatID Description S T R I D E
# #
= = = =
Routing Protocols
> > >
(Atkinson and Fanto, 2007)
RIPv2 simple password authentication
L L L L L L Use cryptographic authentication
(Atkinson and Fanto, 2007)
RIPv2 Security Association expiration L
Let RIPv2 routing fail when the last
key expires
(Atkinson and Fanto, 2007)
RIPv2 Security Association L
The receiver should not try all RIPv2
Security Associations
(Moy, 1998)
OSPFv2 simple password authentication L L L L L L Use cryptographic authentication
(Moy, 1998)
OSPFv2 cryptographic authentication
sequence number prediction
L L L L L L Use cryptographic sequence number
(Gupta and Melam, 2006)
OSPFv3 using the same manual key L L L L L L avoid using manual keys
associaced with
High likelihood
# external, O process #
Untrusted element with High likelihood
of being exploited
associaced with
Low likelihood
>data flow, = data store O
Trusted element with Low likelihood
of being exploited
Table 9: Basic IPv6 Transition Technologies Threats.
ThreatID Description S T R I D E
# #
= = = =
Routing Protocols
> > >
(Bao et al., 2010)
IPv4 address spoofing with
IPv4-embedded IPv6
Implement reverse path checks to verify
that packets are coming from an authorized location.
(Li et al., 2011a)
transport mode ESP will fail with
IPv6-to-IPv4 translation
L Use checksum-neutral addresses
(Li et al., 2011a)
Authentication Headers cannot be used
across an IPv6-to-IPv4
L No widely accepted mitigation
(Li et al., 2011a)
Stateful translators can run out
of resources
L No widely accepted mitigation
(Davies et al., 2007)
Tunneling IPv6 through IPv4 networks
could break IPv4 Network’s security assumptions
route the encapsulated through an IPv4
firewall before decapsulating them
Table 10: L2 Technologies Threats.
ThreatID Description S T R I D E
# #
= = = =
L2 Technologies
> > >
(ITU-T, 2013)
Exhaust a forwarding information base (FIB)
of an L2switch
L IEEE 802.1x authentication
(Rouiller, 2003)
Content Addressable Memory (CAM) Overflow L
Use the port-security
(Rouiller, 2003)
Basic VLAN Hopping L Software update
(Rouiller, 2003)
Double encapsulation VLAN Hopping L L Disable Auto-trunking
(Rouiller, 2003)
Spanning Tree Attack L L Disable STP, Use BPDU Guard
ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy