{"paper_id":"0c8f308b-6c6e-472b-a280-d5388d513f26","body_text":"The Possible Security Issues of the DS-Lite IPv6 Transition Technology | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article The Possible Security Issues of the DS-Lite IPv6 Transition Technology Ameen Al-Azzawi, Gabor Lencse This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-1972342/v1 This work is licensed under a CC BY 4.0 License Status: Posted Version 1 posted You are reading this latest preprint version Abstract This paper focuses on one of the most prominent IPv6 transition technologies named DS-Lite (Dual Stack Lite). The aim is to analyze the security threats that this technology might be vulnerable to. The analysis is based on the STRIDE method that stands for Spoofing, Tampering, Repudiation, Information disclosure and Elevation of privilege. Using the DFD (Data Flow Diagram) of a DS-Lite system, we summarized the potential security vulnerabilities and potential attack points within this infrastructure. We have also built a testbed for DS-Lite topology using several virtual machines, which were created using CentOS Linux images. We used our testbed to perform MitM (Man in the Middle) attack and other type of attacks against the B4 (border gateway) and the AFTR (Address Family Transition Router) and then to monitor their performance and the number of packets being translated under attack by different number of clients using several attacking toolkits. DS-Lite 464XLAT DNS IPv4aaS IPv6 STRIDE Translation Encapsulation Spoofing thc-ipv6 toolkit dns64perf++ port number exhaustion Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 1. Introduction After the depletion of the public IPv4 address pool in 2011 [1], many transition methods were presented to integrate the two IP versions (IPv4 and IPv6) and to tackle the IPv4 depletion challenge. We have conducted a survey of the most prominent IPv6 transition technologies [2], in which we have pointed out that the combination of DNS64 [3] and NAT64 [4] could be a working solution for the communication of IPv6 clients with IPv4 servers and we also showed the drawbacks of this particular technology and its challenges in terms of IPv4 literals communications (connection between IPv4 only devices while having IPv6 island in the middle) and the inability to establish the connection from IPv4 host side [2]. After that came the 464XLAT technology with its double translation mechanism, where two separate translators are deployed CLAT (client-side translator) & PLAT (provider side translator), where some of DNS64 + NAT64 issues were solved [5]. We have presented several papers regarding this transition technology. In [6], we presented the DFD (Data Flow Diagram) of 464XLAT and the security analysis of it by applying STRIDE method, where we showed the vulnerabilities and the potential security threats of this technology. In our next paper [7], we took it one step further when we built a testbed of 464XLAT using Debian based virtual machines and tested the performance of the PLAT under DoS (Denial of Service) attack to test the CPU performance and the pool of the source port numbers. In the latest one [8], we extended the previous paper [7] using a more powerful computer. Therefore, we were able to increase the number of attacking clients (virtual machines) from 1 to 8 clients and test the AFTR performance after attacking it using hping3 command. We proved that PLAT is susceptible to DoS attacks. On the other hand, DS-Lite has its own unique topology and application. It is a promising technology that enables the ISPs (Internet Service Providers) to use only IPv6 in their access and core network, while providing the users with fully functional IPv4 Internet access, too. DS-Lite has the highest deployment rate among the five important IPv4aaS (IPv4-as-a-Service) technologies (464XLAT, DS-Lite, Lw4o6, MAP-E, MAP-T) [9]. The main target of this paper is to build and analyze the DFD of DS-Lite, test its security threats at every inbound and outbound gateway within its infrastructure, then eventually build a testbed for the DS-Lite topology and test its real capability under several kind of attacks scenarios and come up with potential mitigations of the outcome attacks. In Section 2, we discuss the operation of DS-Lite and its structure, section 3 is about tunneling in general and its security concerns. Section 4 discusses the operation of the STRIDE method, its elements and how it works. Section 5 is about applying the STRIDE method on our DS-Lite topology, while section 6 is about the related work that have done before as we mention some previous publications regarding DS-Lite security threats. In section 7, we build the testbed, explain its infrastructure and its topology elements, attacking scenarios and possible mitigation methods. In section 8, we summarize and conclude the value of the results the paper come up with. In this section we also prove the efficiency of DS-Lite and its flexibility to deal with all connection scenarios, especially when a private IPv4 address client wants to communicate with public IPv4 address server while there is IPv6 address island in middle. Finally, we summarize the security analysis of DS-Lite, its vulnerabilities and their mitigations methods. 2. The Operation Of Ds-lite The general purpose of DS-Lite is to provide the home network with IPv4 connectivity across an IPv6-only access network. DS-Lite was presented in RFC 6333 [10], where it consists of two main parts / functions (B4 & AFTR). Figure 1 illustrates the infrastructure of DS-Lite and how it functions. A. B4 (Basic bridging broadband) This router is responsible for encapsulating IPv4 packets into IPv6 ones then send it over IPv6 network till it reaches the AFTR router. It also has another vital role when it processes the returning packets from the AFTR toward the B4, where it de-capsulates the IPv6 packet and extracts the original IPv4 packet from the payload [10]. The tunnel that is created by the customer provided equipment (CPE), which is the B4, is called softwire tunnel which connects the B4 with the AFTR. Some facts about B4 router that was mentioned by RFC-6333 [10]: B4 announces itself as the default IPv4 router, this route is applicable for all IPv4 clients sitting behind this B4 router. B4 router should also announce itself as a DNS server in the DHCP option 6 [10]. As for the operation side, it acts as DNS proxy for all IPv4 clients who are willing to connect with it and beyond, it forwards those requests to the DNS server of the ISP (Internet Service Provider) [10]. B4 also forwards native IPv6 packets to the AFTR without any intervention. The default structure of DS-Lite is as explained above (client → CPE → ISP). However, some devices (IPv4 clients) are connected directly to the ISP without the home gateway. The reason behind that because those devices have the ability to act CPEs themselves [10]. Host based: designed for large-scale deployments and especially when the client is directly connected to the service provider network, which means the IPv4 client, and the CPE are both mounted on the same device [10]. B AFTR (Address-Family transition Router) The AFTR de-capsulates the 4in6 traffic that comes from the B4 router then it translates the IPv4 packet into public IPv4, which means that it also functions as a stateful NAT44 [10]. And, of course, it also performs the reverse functions for the returning packets. The technology in general has two types of topologies (Gateway based & Host based architecture) and each one has its own applications. Gateway based: mostly based in residential broadband infrastructure, where the client and the CPE are based in different but directly connected machines [10]. Host based: designed for large-scale deployments and especially when the client is directly connected to the service provider network, which means the IPv4 client, and the CPE are both mounted on the same device [10]. In this paper, we are focusing on the Gateway based architecture topology because this topology is easier to build for testing purposes and virtual environment. It is the most represented topology in residential households for example where we have IPv4 client > > router > > ISP. The AFTR has two main interfaces (softwire interface & network interface), each one of them faces one end of the device: Softwire interface: its main function is connecting B4 with AFTR and translating the datagram of (softwire identifier + IPv4 + source port) to another source IPv4 and source port. So, it decapsulates the IPv4 in IPv6 datagram (for the packets coming from B4 side) and does the reverse, by encapsulating IPv4 in IPv6 datagram (for the packets heading towards the B4 side). Network interface: sits on the other side of the AFTR (the WAN side) and translates the decapsulated source IPv4 and source port into the interface IP (192.0.2.1) and source port 5000 (just for our example). The interface is also in charge of the translation in the reverse direction (IPv4 server ◊ AFTR ◊ B4), where it translates the original packet’s destination IP & destination port (according to AFTR’s Carrier Grade NAT translation table) to the destination IP and destination port of the softwire. Figure 2 shows the outbound communication between B4 and AFTR. The NAT table in our example is configured in a way that translates any incoming packet with the source IP address: 10.0.0.1 and source port number: 10000 to 192.0.2.1:5000. Once Datagram 1 reaches the B4 router, it will be encapsulated into Datagram 2, which is an IPv4 in IPv6 datagram, then forwarded to the AFTR through softwire tunnel. When the AFTR receives datagram 2, it decapsulates it, extracts the IPv4 datagram from it and forwards it to the stateful NAT function, which performs the followings (according to its NAT table): The received datagram with source IP and port pair of 10.0.0.1:10000 should be translated to datagram 3 with the below specifications: Source IP and port pair: 192.0.2.1:5000. How the AFTR translation table functions? The IPv6 address for the B4 router is called softwire-ID. This ID is being shared by every client that wants to connect with the B4 router and triggers the DS-Lite communication process. Every single client of those is equipped (by the B4 router) with source IPv4 address [RFC 1918] such as 10.0.0.1 and it is unique within its network. When an embedded packet (source IP address: 10.0.0.1, source port number: 10000) is forwarded from B4 to AFTR through softwire tunnel, AFTR combines the softwire ID with this packet’s details as one entry: softwire-id/IPv4/TCP/10000. In fact, this is only half of the entry. The other half will be AFTR network interface IPv4 address, the protocol identifier (e.g., TCP or UDP) and source port number: (192.0.2.1/TCP/5000) as shown in Table 1. The reverse direction of the packet (IPv4 server > AFTR > B4 > IPv4 client) functions in a similar manner: AFTR receives datagram 4 through the network interface with public IPv4 address, then processes it by checking the internal NAT table looking for matching entry. In our case, datagram 4 has the following details: IPv4 destination address: 192.0.2.1. Destination port: 5000. Protocol is TCP. The corresponding entry does exist in the NAT table (see Table 1), AFTR therefore translates the IPv4 packet of datagram 4 to IPv4 destination address: 10.0.0.1 and TCP destination port: 10000. AFTR then encapsulates the translated IPv4 packet into an IPv6 packet and sends datagram 5 over to the B4 router at 2001:db8:0:1::2 IPv6 address (which the AFTR knows from the table entry itself as softwire ID). Table. 1 Dual-Stack Lite Carrier-Grade NAT Translation Table [10] Softwire-ID/IPv4/Protocol/Port IPv4/Protocol/Port 2001:db8:0:1::2/10.0.0.1/TCP/10000 192.0.2.1/TCP/5000 B4 receives Datagram 5, de-capsulates the embedded packet, extracts the original IPv4 packet from the 4in6 Packet and forwards it accordingly to the IPv4 client (10.0.0.1:10000) as datagram 6. Table 2 lists all IP addresses & port numbers for the DS-Lite packet route for datagrams (1–6). To understand the functionality of AFTR translation even more, please refer to RFC 6333 [10], where deep details about the translation steps are explained. 3. Tunneling Table 2 DS-Lite Datagrams Datagram Header Details IPv4 Datagram 1 IPv4 Src : 10.0.0.1 IPv4 Dst : 198.51.100.1 TCP Src: 10000 TCP Dst : 80 IPv6 Datagram 2 IPv6 Src: 2001:db8:0:1::2 IPv6 Dst: 2001:db8:0:1::1 IPv4 Src: 10.0.0.1 IPv4 Dst: 198.51.100.1 TCP Src: 10000 TCP Dst: 80 IPv4 Datagram 3 IPv4 Src: 192.0.2.1 IPv4 Dst: 198.51.100.1 TCP Src: 5000 TCP Dst: 80 IPv4 Datagram 4 IPv4 Src:198.51.100.1 IPv4 Dst: 192.0.2.1 TCP Src: 80 TCP Dst: 5000 IPv6 Datagram 5 IPv6 Src: 2001:db8:0:1::1 IPv6 Dst: 2001:db8:0:1::2 IPv4 Src: 198.51.100.1 IPv4 Dst: 10.0.0.1 TCP Src: 80 TCP Dst: 10000 IPv4 Datagram 6 IPv4 Src: 198.51.100.1 IPv4 Dst: 10.0.0.1 TCP Src: 80 TCP Dst: 10000 A. Tunneling History Tunneling goes back to the 1990s when PPTP (point-to-point tunneling protocol) was presented by Microsoft engineers and some other vendors, where the original purpose was to support windows users with a data encryption, where it gained huge popularity among small and medium size corporations later on and it is in fact still being used to some extent [12]. Ever since it was under the microscope of critics. It was even presented as an RFC [13] in 1999. PPTP functions at Data Layer 2 and uses General Routing Encapsulation (GRE) as packet creation system, where GRE encapsulates the original packet inside another packet. Some vulnerabilities were discovered by Schneier [14] where he showed that PPTP has several weak points such as its Challenge/Response authentication protocol (CHAP), he also presented the fact that PPTP uses a very low security aware hashing algorithm, where eavesdropping was also quite easy to implement. Schneier [14] also emphasized that PPTP uses a low secured encryption standard called MPPE, which has a key that could be easily broken. After that, Microsoft presented another solution called MS-CHAPv1 [15] and then MS-CHAPv2 [16], which is used as one authentication option in Microsoft's implementation of the PPTP protocol for virtual private networks [15]. The most secure tunneling is OpenVPN and it has proven to be very hard to crack [12]. In conclusion, there are alternatives to the regular PPTP such as the IKEv2 and combination of IPsec and L2TP, which is used in Microsoft VPN (Virtual Private Network), and it is safer and quicker than regular PPTP [12]. Tunneling in general can come in so many forms such as MAP-E, 6over4, 6to4, Teredo, 6rd, DS-Lite, etc. [9]. It makes connection between two devices possible despite having different IP version island in the middle just like the case in DS-Lite tunnel example, though it brings some security threats with it. B. Tunneling Issues & Solutions The most serious issue with tunneling is that tunneled IP traffic doesn’t go through the same inspection process that the normal traffic (non-encapsulated packets) will be liable to unless extra dedicated devices are installed on the premise to double check the traffic as deep packet inspection [17]. For Instance, in Teredo tunnel the router will check the IP and UDP layer normally. However, it cannot find out that there is actually another IP layer encapsulated within the UDP payload. Another issue with tunneling is, when the already encapsulated packet is targeting a host that lies further beyond the tunnel endpoint. In this case the machine will normally forward the packet simply to the built-in next hop [17]. The tunnelled data endpoints are aware of the tunnelled data and its encapsulated packets. The network devices in the middle are not, and that could be an issue [17]. A solution is proposed by [17], where in case of IPv6 transition is required, native IPv6 is the way forward in terms of connecting two sides with tunneling solution, such as ISATAP, 6over4, etc. [18], in order to encapsulate traffic between a device and the router on the other side that resides in the same network. All that due to the difficulties that come with inspecting the inner content of encapsulated packet is a quite complicated process. NAT process also presents another challenge when it comes to tunneling, where it opens more doors for attacking possibilities on the incoming NAT interface. Therefore, it is recommended that the NAT interface shouldn’t not be configured by default and only used when it is the last resort [17]. Another recommendation is to deactivate the interface itself after its usage [17]. Furthermore, IP address guessing emerged as a potential risk to the tunnel end point, where some protocols use a regular or a well-known IP address or range of IP addresses. For instance, Teredo uses a specific IP address range in its infrastructure, which makes the tunnel liable to IP address guessing attack. Furthermore, sometimes guessing the IP address gives an indication about which kind of OS is being used. For instance, Teredo implies that the machine is most probably running Microsoft Windows. The solution is for sure no brainer, to avoid those well-known IP address ranges and to use random ones [17]. On the other hand, an adversary can have the ability to alter tunnel’s server settings on the client side while the client itself having no idea about it. One way to avoid such breach, is to use authentication for both tunnel end-points like https [17]. A second mitigation method can be the use of secure ND (Neighbor Discovery) [18] whenever a client receives Router-Advertisement packet. Tunnels in general are less secure than normal conventional links due to the fact that an attacker can Fig. 4 4 in6 tunnel encapsulation overview [21] send an already encapsulated packet to the tunnel end node where it is supposed to be decapsulated [17]. This action might cause an injection of the faulty packet in the decapsulator side. This threat might be avoided by turning on decapsulation check which will drop such malicious packets [20], where a valuable recommendation was also mentioned that it is highly discouraged to set the tunnel interface to reply with acknowledging the existence of a tunnel like “ICMP error message”. In general, [21] has mentioned two important general tunnel security points: • There is no correlation between amount of security regulations and procedures on the tunnel packets and the level of security measures applied of the original packet inside the tunnel (the payload) [21]. • The security header authentication (HA) or encryption security payload (ESP) parameters are the deciding factors for the three security pillars (integrity, authentication, and confidentiality) of any tunnel endpoint [21]. C. Attack Scenarios In [22], the attack possibilities were categorized into three types: • Denial of Service (DoS): the act of sending too many requests to a specific device to overwhelm its computation and processing power or bandwidth in order to force the targeted machine to drop or not serve the useful requests. • Reflecting DoS: where the attacker will reflect the traffic from normal (innocent) machines towards the targeted machine to do the harm. • Service theft: gaining unauthorized access. One of the most used types of tunnels is the well-known 6in4 [23], which has several attacking scenarios. Each element within the IPv6 network sends RA message to declare that it is there and to allow other routers to update their table of existing IPv6 addresses. An attacker might take advantage of this process especially when all routers are sitting on the same network, which gives the possibility to attack the 6to4 router with Route-Advertisement (RA) message, by sending spoofed packet to the victim [22]. The second type is spoofing as explained by [23], where an attacker can take advantage of an existing tunnel and spoof one side of the tunnel endpoint and attack the other side as shown in Fig. 3. The reason behind implementing such an attack is because tunnels are not aware of what’s behind the requester due to the absence of authentication which leads to the fact that a specific tunnel endpoint doesn’t know which other endpoints do reside on the very same tunnel. The tunnel endpoint only assumes that packets do come from the other tunnel endpoint [24]. This lack of knowledge has raised the attention of attackers to exploit it, especially if the attacker’s packet is difficult to trace. That means the attacker is able to conduct sniffing, spoofing and DoS attack by leveraging this vulnerability. IPv6 tunnels have some other weakness, where they are liable to password and “internet key exchange” attacks [25]. The golden rule according to [26] is that the security of the tunnel comes from the security of the tunnel endpoints themselves and the inner packets of the tunnel. If they are secured, then the tunnel in general is secured. So, to list the attacks that tunnels in general liable to, we end up with the followings: • Sniffing. • Spoofing. • DoS. • Password & Internet key exchange. D. Mitigation Methods End-to-end secure communication system such as IPsec [27] can help protect the tunnel endpoint nodes. Packet filters such as firewalls can also be helpful [27]. The only drawback with this solution is the inability to see the content of the packet at the edge firewall when applying filtering method, which means authentication and host validation step must be implemented. Furthermore, some research works suggest the usage of separate firewall filters, one for IPv4 packets and another for IPv6 packets, in order to make sure that every packet is being filtered and examined [23]. Another method is to deny the IPv6 tunnel by blocking a specific protocol and its associated ports [23]. In case of 6in4 tunnel, an attacker might inject an already encapsulated packet within the tunnel, that’s why firewalls can be enabled to inspect tunneled packets and the firewall should also permit any 6in4 traffic which is generated from the same segment or from outside it as well, in order to be able to filter traffic behind the segment as well [23]. Finally, IPsec has the ability to block any traffic that didn’t pass the authentication phase [23]. Table 3 Vulnerability of different DFD Elements to different Threats [32] Element Spoofing Tampering Repudiation Information Disclosure Denial of Service Elevation of Privilege Data Flow ✓ ✓ ✓ Data Stores ✓ ✓ ✓ Processes ✓ ✓ ✓ ✓ ✓ ✓ Interactors ✓ ✓ Another proposal was made by [28], which is based on the validation of the real source IP address by using IP trace-back method , by doing so, the tunnel end point can drop any incoming spoofed IP packet. However, this technique comes also with its limitations, it cannot trace the packet source IP address till the tunnel endpoint node due the stateless IP routing, where a router can only see the next hop IP address, in which the tunnel end node cannot trace the incoming packet till its original sender, which means a full end-to-end route knowledge is unachievable [28]. One more spoofing mitigation trial has been introduced by [29], where it focuses of preventing the spoofed packet at the network edge. The principle is based on using authentication algorithm by the sender, where every packet has a unique generated signature attached to its extension header. Finally, Lee [30] has presented his own spoofing mitigation method, where he tackles sneaky packets, who are trying to avoid filters by presenting packet filtering mechanism using the well-known Linux Netfilter framework [31]. E. DS-Lite tunnel Challenges In fact, the literature is so rich with attack scenarios regarding 6in4 tunnels. However, there is so little to know about 4in6 tunnel in terms of security vulnerabilities. The concept might seem the same, but the implementation might differ a bit, and that leads us to our paper focusing point, DS-Lite and its security analysis. DS-Lite uses 4in6 tunneling, this type of tunneling was first presented in RFC 2473 [21], where IPv6 tunneling basically creates a link (virtual one) between the two ends of the tunnel. The IPv4 original packet will be sent as a payload encapsulated in the IPv6 tunnel packet as shown in Fig. 4. The process begins by grabbing the original IPv4 packet and prepending it to another IPv6 header (tunnel header) and sometimes the extension header, as it is an optional feature, then sending this encapsulated packet through the softwire tunnel to the other tunnel end-point node, where the packet will be decapsulated and the original packet will be extracted and forwarded according to its destination and routing table. For better understanding of 4in6 tunnel components, the below tunnel terminologies had been clarified [21]: • Virtual link: refers to the IPv6 tunnel itself. • Original Packet: the IPv4 packet that we want to send over the link, it consists of two components: packet header and payload • Tunnel IPv6 header: refers to the IPv6 tunnel header without the payload. • Tunnel IPv6 packet: refers to the whole IPv6 tunnel packet (tunnel IPv6 header + original packet). • Tunnel entry-point node: the responsible node for initiating the encapsulation process, also called “encapsulator node”. It is the source of the IPv6 tunnel packet. • Tunnel exit-point node: the responsible node for receiving the encapsulated packet then decapsulates it, extracting the original IPv4 packet components (header + payload) then forwarding the IPv4 packet to its destination, also called “decapsulator node”. It is the destination of the IPv6 tunnel packet. • During packet forwarding process of the tunnel IPv6 packet, IPv4 header’s (the original packet header) TTL value is decremented by 1. Note both end nodes are capable of encapsulation / decapsulation, the naming referred only to the function of the process initiators. DS-Lite has an advantage when it comes to DoS attack from random public IPv4 addresses. This is due to the following process: • AFTR receives an encapsulated packet, then it decapsulates it. • If the extracted packet payload has source IPv4 address that is not private RFC 1918, then it will be immediately dropped. • This built-in security feature gives DS-Lite the ability to stop DoS attacks stemming from unauthorized IPv4 addresses [10]. DS-Lite, however, has a drawback due to the fact that it uses stateful translation on the AFTR side, which makes the machine liable to DoS attacks and limiting its scalability in case of expansion or the need in bigger projects, especially in case of having numerous amount of B4s routers within the infrastructure [11]. 4. Stride Methodology STRIDE stands for Spoofing, Tampering, Repudiation, Information disclosure and Elevation of privilege. The method was explained in detail in [32] and it summarized the general attacks that any network system may be vulnerable to, below is a brief description for each attack: • Spoofing: the claim to be someone you aren’t or the act of some malicious user who pretends to be e.g., your website [32]. • Tampering: the changing in the actual data flow between two nodes [32]. • Repudiation: the ability of the sender to deny the fact that he did send a specific packet or sign a specific document [32]. • Information Disclosure: the access to confidential information that one should not have, like TTL value of a packet or confidential data such as like online banking credentials or any other login credentials [32]. • Denial of Service: the process of overwhelming a specific server or network connection with huge number of useless queries or data in order to block the legitimate ones from getting a reply or even being processed [32]. In another word, DoS makes the targeted machine unavailable for its original purpose. • Elevation of Privileges: the access of a specific user to a certain level of sensitive data which might be strictly confidential file that meant to be for upper management or to root user for instance [32]. According to [32], the best method to test system’s vulnerabilities is to build DFD (Data Flow Diagram) for the system and apply the STRIDE method on it. Table 3 shows the different potential security threats for each DFD element. 5. Applying Stride On Ds-lite The first step in applying the STRIDE method is to build the DFD of the examined system and specify the potential attacking points at each element. Therefore, we built the DFD for DS-Lite in Fig. 5, where it shows the spots (1–11). The security analysis will be divided into several groups such as the traffic between the client and B4, then between B4 and the AFTR, etc. A. IPv4 client. 1) Spoofing : A malicious user might spoof the IP address of the client and attack the B4 router by sending many useless requests to the B4 and fully utilizing its computation power. 2) Repudiation : The request initiator might deny the fact that he made the request in the first place. By doing so, a malicious user might attack the B4 router then deny the fact he was the one who sent this specific request such as echo request, DNS resolution request, etc. B. Data flow from the Client to B4 router. 1) Tampering : An adversary might tamper (change or modify) the content of the flowing packets like IP address, source port number, etc. The attacker might also diverge the packet toward a fraudulent server which might cause FoS (Failure of Service) attack which is the prevention of the legitimate requester from getting a response [1]. 2) Information Disclosure : An attacker might get hold of confidential information like TTL value of a packet, e.g., some sensitive information sent by the client as a plain text or the browsing habit of the client himself [1]. 3) Denial of Service : An attacker sends too many useless requests to the B4 router and blocking the legitimate requester from having his query getting processed. C. Data flow from B4 router to IPv4 client. 1) Tampering : in this case, the potential victim is the client himself, which is vulnerable to an attack at application level such as sending TCP RST signal that will end the already established TCP connection [6] and also deauthentication attack [33] that results in disconnecting the device from the router’s Wi-Fi. In addition to plain text injection attack [33] that allows B4 router to send misleading information to the client such as false routing details. 2) Information Disclosure : an attacker getting access to sensitive information in a malicious way such as an important text sent back by the IPv4 server behind AFTR. 3) Denial of Service : sending high number of forged replies to overwhelm the client and prevent the client from sending more requests to the B4. D. B4 router. 1) Spoofing : Another machine presents itself as the legitimate B4 router and starts communicating with the rest of DS-Lite network elements, which puts everyone that deals with this machine at high risk such as a malicious device initiating a communication with AFTR router and presents itself as the B4 router which leads to whole traffic (from AFTR side) pouring into the wrong direction, by changing the destination IP address of the packet, which results in the original sender not getting a response for his request. Another consequence could be when the malicious server starts recording the data passing through and using it for illegal activities such as blackmailing. 2) Tampering : modifying the current source and destination address of the 4in6 traffic that is being processed within B4 router in order to shift the traffic and prevent it from being sent to the real AFTR and forwards it to a malicious server. Another possibility could be tampering with the IP address/port pair of the sender which results eventually in a different entry in the AFTR translation table and therefore the packet reply will not return back to the original sender. 3) Repudiation : in this case, when the B4 is spoofed, then the malicious user will deny the fact that he sent a specific packet while he did. The obvious solution to this issue is proper logging [6]. 4) Information Disclosure : attacker getting access to sensitive data within the router such as client’s source IP address, TTL value, browsing data, etc. 5) Denial of Service : flooding AFTR router with unnecessary request in order to overwhelm the AFTR and stopping it from processing any further incoming packets, see section V.B.3. 6) Elevation of Privileges : the attacker gets access to high level (privileged) data, and it mainly occurs due to inside job [1], when an employee is implicit in the act. E. Data flow from B4 to AFTR 1) Tampering : 4in6 traffic might be altered, the source IP address or port number are liable to be modified by attacker. 2) Information Disclosure : the access to confidential information in many ways, see section V.B.2. 3) Denial of Service : the flood of useless queries to exhaust the AFTR and hinder its main job, see section V.B.3. F. Data flow from AFTR to B4. 1) Tampering : modifying the traffic details before it reaches the B4 router, such as the source IP address or port number of the 4in6 flowing traffic. 2) Information Disclosure : the unauthorized access to sensible data, see section V.B.2. 3) Denial of Service : flooding the B4 router with useless traffic. See section V.B.3. G. AFTR router. 1) Spoofing : attacker impersonates the AFTR and starts communication with the rest of machines around him such as B4 router and IPv4 server, which might lead to exchanging sensitive data with the wrong person, see section V.D.1. 2) Tampering : changing the content of the 4in6 packet payload, see section V.D.2. 3) Repudiation : hiding the packet sender identity, see section V.D.3. 4) Information Disclosure : the possibility of an attacker getting access to the confidential data, see section V.B.4. 5) Denial of Service : various type of attacks can be described in this section, such as exhausting the AFTR with too many useless requests and hinder the process of encapsulating the desired packet. 6) Elevation of Privileges : the act of unauthorized access to very confidential data center of a specific folder in a malicious way, see section V.D.6 H. Internal connection tracking table of the AFTR. 1) Tampering : an attacker can manipulate the connection tracking table of the AFTR router that saves the incoming 4in6 traffic packet with its source address and port number and map it with a destination IPv4 device according to the stateful NAT rule within the router (see Table 1). So, the manipulation can cause a faulty destination address and disturb the encapsulation process and end up with a packet loss. 2) Denial of Service : flooding the connection tracking table with too many unnecessary entries (false connections) might overwhelm the table beyond its capabilities and cause it to flush its data or saturate the AFTR itself, and that means the AFTR will no longer able to process any incoming packet or at least it will lose some legitimate connections. I. Data flow from AFTR to IPv4 server 1) Tampering : the destination IP of the traffic might be altered and redirected to a malicious server instead of being directed to the legitimate IPv4 server. 2) Information Disclosure : unauthorized access to sensitive data of the IPv4 traffic. 3) Denial of Service : overwhelming the host with too many requests, see section V.C.3 J. Data flow from IPv4 server to AFTR. 1) Tampering : the IPv4 packets might be altered in terms of IP source address or port number, which will definitely change the corresponding 4in6 traffic details. 2) Information Disclosure : unauthorized access to IPv4 traffic before it reaches the AFTR router, which might leak the confidential browsing habit of the client, see section V.B.2. 3) Denial of Service : exhausting the AFTR and its main encapsulation function, see section V.E.3. K. IPv4 server 1) Spoofing : an attacker impersonates the IPv4 server and initiate a communication with AFTR and the rest of DS-Lite Topology. 2) Repudiation : The host (IPv4 sever) might hide his identity, perform all sorts of malicious acts then deny any responsibilities for them. For example, in previous point of spoofing, the attacker might spoof the IPv4 server, performs an attack against AFTR, then denies the fact that he initiated the communication in the first place. 7. Related Work Very few experiments were actually published regarding DS-lite and its security analysis. Therefore, we are grabbing the opportunity to take the lead in this uncharted territory. A survey for the most prominent IPv6 transition technologies and their security analysis was made by us in [9].We mentioned DS-Lite, and classified its security analysis as important but replaceable, and that was due to several issues mentioned by [34] such as the following ones: • The need for two separate physical interfaces at the AFTR. • The need for high scalability at the AFTR side due to the fact that many B4 routers maybe connected to same AFTR [34]. • The location of deploying AFTR router within the ISP network and the trade-off it creates between the high operation cost and installing an extremely powerful AFTR [34]. The trade-off can be explained by dividing the issue in hand into two options: o Deploying AFTR at the edge of the network to cover small area, serves few B4s, requires less powerful AFTR. o Deploying AFTR at the core of the network to cover a big area, covers more B4s, requires extremely powerful AFTR (or even more than one AFTRs) • The complexity of deploying a proxy DNS resolver, which will proxy every DNS query stemming from all IPv4 clients heading towards a DNS server that resides in IPv6 network [34]. Another work by [35] has conducted a security analysis for DS-Lite in terms of its MIB (Management Information Base), and it consists of several objects. MIB is a module that can be used to monitor the AFTR router within DS-Lite infrastructure by leveraging SNMP (Simple Network Management Protocol). According to [35], the most vulnerable objects that are susceptible to attacks are: • Notification threshold objects: an attacker manipulating a threshold’s value to a very low level, which will lead to a flood of useless alarms and thus disrupt the AFTR and its monitoring mechanism, or he sets it to a very high value to the level that makes the idea of setting the alarm literally useless. o DsliteAFTRAlarmConnectNumber: The alarm is sent when the number of current DS-Lite tunnels reached the threshold, which means for every B4 router, the AFTR has to have a separate tunnel for it. o DsliteAFTRAlarmSessionNumber: an alarm will be sent when threshold of sessions per IPv4 users is reached. This metric goes hand in hand with RFC-6333 [10], where AFTR has to be able to log softwire ID, IP, ports, protocol (see table 1) in order keep track of user sessions. o DsliteAFTRAlarmPortNumber: an alarm is to be sent when the threshold for number of ports used by a user is reached or even crossed. • Table entry objects: an attacker can alter the content of such entries causing the drop of legitimate entries or adding harmful and faulty ones: o DsliteTunnelTable: consists of mapping entries of B4 address to AFTR address. o DsliteNATBindTable: contains entries about the current active bindings within the NAT table of the AFTR (see Table 1). What makes those tables’ entries a potential security threat is the possibility of an attacker assessing the number of hosts being served by a single AFTR router, which relevels sensitive information about the whole topology of DS-Lite [35]. A chance of an inside job is also possible, where an internal employee can access the list of hosts that are in active sessions which will be a violation to the subscriber’s privacy [35]. Moreover, RFC-6334 [36] referred to DS-Lite security briefly and recommended that IP firewall must be implemented in order to avoid MitM attack along the softwire connection of DS-Lite. RFC-8513 [37] proposed another method to implement DS-Lite using YANG module which is a schema that facilitates data accessing mechanism through network management protocol like NETCONF and RESTCONF. This module allows the administrator to add some features and addons to the B4 and AFTR interfaces such as “b4-address-change-limit”, “Tunnel-MTU (Maximum Transmission Unit)”, etc. Moreover, RFC-8513 [37] also suggested a solution for DoS attack raising 'b4-address-change-limit'. This value specifies the minimum time between two consecutive changes of the IPv6 address of the B4 device. Setting it to a low value, would enable the attacker to send higher number attacking packets with different source addresses. The recommended mitigation is to set its value to 30 minutes. In RFC-8513 [37], the authors presented the security analysis of their DS-Lite architecture, where emphasized that the main vulnerability is an attacker having access to either B4 or AFTR router and undertaking several kinds of malicious activities. • Manipulating the AFTR IPv6 address on B4 tunnel end point, which will deceive the B4 router and force it to forward the 4in6 traffic to the wrong recipient. • Altering the value of “b4-address-change-limit” which gives the B4 more flexibility in configuring the softwire. An attacker lowering this value will boost the possibility of DoS attack against B4 router. 8. Ds-lite Testbed A. Testbed Topology and specifications As shown in Fig. 6, our testbed consists of five machines (IPv4 client, B4, AFTR, IPv4 server and attacker). They were all based on VMware workstation VMs, and those machines were built upon CentOS-7 images. Every machine had the following specifications: • RAM: 3 GB • Hard disk: 20 GB • CPU: 1 core The host PC that hosted the whole testbed had the below specifications: • OS: Windows 10 Pro. • RAM: 16 GB. • Hard disk: 1TB. • CPU: Intel-Core i7, 4 physical cores. IPIP6 tunnel was built between B4 and AFTR which took care of encapsulating IPv4 packet inside IPv6 tunnel then de-capsulating it. As for the NAT process on AFTR side, iptables rule was configured to masquerade the source IP address to the AFTR’s network interface (ens35). We note that the above setup contains an important simplification compared to Table 1: the Softwire-ID is missing from the connection tracking table. This change did not influence our experiments, whereas it simplified the setup of our testbed: we could use iptables instead of a real AFTR implementation. B. Attack scenarios i. Spoofing Attack from within VMnet-11 (an inside job) The proposed attack as shown in Fig. 6 is Spoofing the ingress tunnel end point (ens39), which is the softwire tunnel interface of the B4 router, then sniffing / logging traffic or perform MitM attack against egress tunnel end point (AFTR). The attack was based on the “thc-ipv6” toolkit [38], which has several tools within it. One powerful tool was chosen to perform the attack (four2six). What it actually does is manually creating a crafted packet of IPv4 inside IPv6 (encapsulated packet) and send it over the channel to the victim (AFTR). This crafted packet is actually a spoofed one imitating that it was sent by the B4 router, where it has the same specifications as of a genuine B4 originated packet: • IPv6 Src: 2001:db8:0:1::2 • IPv6 Dst: 2001:db8:0:1::1 • IPv4 Src: 10.0.0.2 • IPv4 Dst: 198.51.100.2 In fact, the spoofed attack went through AFTR then to the end receiver (IPv4 server) and series of ICMP echo requests and replies had been exchanged between the attacker and victim. In more details, what happened is: • The AFTR received the malicious packet. • The AFTR saw the packet as a 4in6 packet, therefore, it then decapsulated the packet. • The AFTR then forwarded the extracted IPv4 packet with source address of 198.51.100.1 towards the IPv4 server (198.51.100.2). • IPv4 server sent ICMPv4 echo reply back. • The AFTR saw the later packet and encapsulated it in IPv6 packet. • The echo reply from the AFTR, which is an IPv6 packet with IPv4 packet in its payload, is sent back to its destination IPv6 of address 2001:db8:0:1::2. • Figure 7 shows three different terminals, the top one is the incoming packets at attacker interface, the one in the middle is the B4 incoming traffic from the AFTR side, and at the bottom is the incoming traffic at IPv4 client. • B4 received the IPv6 packet carrying an IPv4 packet with ICMP echo reply because it is the legitimate owner of the 2001:db8:0:1::1 IPv6 destination address. • The Attacker saw the same reply because its NIC runs in promiscuous mode. • The interesting thing here is illustrated by IPv4 client receiving an ICMP4 echo reply for a request that he didn’t request in the first place, which has been issued by the attacker initially. • Echo replies in Fig. 7 are circulated in red. ii. Attack from within VMnet-10 (compromised B4 network) It is also worth mentioning that B4 by design is also capable of routing native IPv6 packets, which takes us to Fig. 8, where we added IPv6 address to interface ens38 at the B4 machine in order to process and forward incoming IPv6 packets. A real-life spoofing scenario could also be stopped before reaching our internal network of AFTR (VMnet-11 in our example). Therefore, another attacking scenario was proposed in Fig. 8, where the attacker is not sitting directly in AFTR network, but outside it. The idea behind such an attack is an attacker having access to our home router network, which gives him direct contact with the CPE. This access allows the attacker to send a crafted packet with spoofed IPv6 address of a B4 router or any other IPv6 address from the internal network of AFTR (VMnet-11 in our example). Fortunately for the user, the attack didn’t go through, B4 router was always dropping any incoming packet from the attacker-2 machine that has an IP address (a spoofed one) from the pool of (VMnet-11). It seems like an internal security feature within the machine. iii. Source port exhaustion attack from within VMnet-10 At first, the attack was conducted using the same platform, regular specs windows-based computer, however, the results were not stable and not reproducible due to limited cores on the host PC. Therefore, we made the decision to use the resources of NICT StarBED, Japan. A “P” series node [39] was used, which is a Dell PowerEdge 430 server with the following specifications: Two Intel(R) Xeon(R) CPU E5-2683 v4 @ 2.1 GHz CPUs having 16 cores each and 348 GB 2400MHz DDR4 SDRAM. Windows 10 Pro operating system was installed, and the same process was repeated by building the testbed using VMware workstation player and CentOS-7 based virtual machines. The specifications for each machine were as follow: • RAM: 4 GB • Cores: 4 cores, except for AFTR having 6 cores. • Disk: 20 GB. Before disclosing the attack details, it is important to explain the mathematical sense behind it. In networking world, ports are counted based on 16 bits standard. The 16-bits was chosen when the TCP and UDP standards were designed [40]. As a result, the maximum number of ports equals 2 16 = 65,536. This number applies to TCP and UDP ports. In our experiment, we focus on the UDP ports and how to exhaust them by sending too many queries (UDP requests) in short period of time. However, not all ports on range are usable for establishing new connection, because ports between 1 and 1024 are called well-known ports and they are reserved for specific functions such as FTP, HTTP, DNS, etc. Therefore, the total range of ports that NAPT (Network Address and Port Translation) device can use as UDP source port numbers equals 65,536–1024 = 64,512 ports. Figure 9 shows the attacking scenario-3 by sending too many AAAA queries from “IPv4 Client-1” and “IPv4 Client-2” machines. In order for the attack to function, few files must be correctly configured, such as: • /sys/module/nf_conntrack/parameters/hashsize The HASHSIZE is actually the size of hash table storing the lists of conntrack entries [41], which is better of as base of 2, which means that hashsize could be 2 14 = 16,384. • /proc/sys/net/netfilter/nf_conntrack_max It represents the maximum number of allowed conntrack entries that netfilter can keep running simultaneously. It was set to hashize*8 = 16,384*8 = 131,072. This number will have a significant impact when we run our attack later, so that our NAT table doesn’t get full easily. • /proc/sys/net/netfilter/nf_conntrack_udp_timeout This timeout means that after 30 seconds, the already used UDP ports are ready to be re-assigned by the kernel, we left it out as the default value of 30 seconds. • /etc/security/limits.conf This file controls the number of maximum open files at the same time, where we added the below line: # root hard nofile 1000000 To perform this kind of attack, another tool can be used, where a huge number of DNS queries can be sent to the target machine (AFTR), which is called “dns64perf++” [42] (described in [43]). When all parameters (on the attacking machine side) are set correctly (number of requests, delay between requests, etc.), the AFTR pool of source ports will be exhausted, and the machine will not be able to process incoming packets anymore till the UDP timeout (port allocation timeout in AFTR machine) is up. The below command was used on each of our attacking clients: /dns64perf + + v4 198.51.100.2 53 0.0.0.0/5 60000 1 1 60000 400000 0.1 What this command really does is sending 60,000 queries from each client. For two clients, this number reaches 120,000 queries, which is still under 131,072 (nf_conntrack_max). As a result, our NAT table will not be overfilled with packets that exceed its capacity. Another interesting fact in the command is the delay of 400,000 nanoseconds between queries, which means 2,500 queries/s, which means, for two clients, we are sending a total of 5,000 queries/s. The attack was executed by an automated script from client 1, which does the followings: • Accesses AFTR remotely (via ssh) and runs tshark (traffic monitoring software) and captures the traffic at ens35 interface. • Runs the attack from IPv4-client − 1 (the same machine). • Accesses IPv4 client-2 remotely (via ssh) and runs the same attack with the same parameters. • Waits till attacks are finished on both clients. • Accesses AFTR remotely (via ssh) and stops tshark. • Sends the tshark results as pcap file to the host machine, so it can be read in the Wireshark software. Figure 10 shows the exhaustion of the source ports clearly. To prove that we must have only 64,512 sent queries, which comes from subtracting the well-known 1024 ports from the total of 65,536 ports. Figure 10 shows that AFTR processed only 64,536 packets at ens35 interface. After digging deeper, we found out that there are more packets embedded within Wireshark results such as 20 ICMP and 4 ARP packets. As a result, the reaming packets are 64,536–20 – 4 = 64,512, which is exactly the number we were anticipating. In principle, we sent 60,000 queries from each client (120,000 in total), AFTR was able to process no more than 64,512 packets and it ran out of ports in around 14 seconds. This failure of service supposed to last until UDP session timeout at AFTR is over and new source ports are available to be re-allocated. C. Mitigation method Several IDS & IPS (Intrusion Detection & Prevention systems) were tested in order to identify and drop the spoofed packet from the legitimate one. The process proved to be quite hard to implement, especially when our attacker machine is located inside the access network of the ISP (VMnet-11). Therefore, a workaround had been put in place and iptables rules were emplaced to do the job. 1) First attack mitigation: - An ip6tables rule was configured at AFTR in order to allow the incoming traffic at ens34 interface of the AFTR only under the condition that the incoming packet’s source MAC address belongs to B4 ens39 interface (see Fig. 6). ip6tables -A INPUT -i ens34 -s 2001:db8:0:1::2 -m mac ! --mac-source 00:0c:29:67:14:14 -j DROP 2) Second attack mitigation: - Despite the fact that this attack didn’t go through, and spoofed packet had been dropped, a proposed solution is presented here in case of building the topology using another machine (different Linux distribution for instance), where such attack could be prevented at B4 router side with the following rules: iptables -A FORWARD -i ens38 -s 10.0.0.0/24 -j ACCEPT iptables -A FORWARD -i ens38 -j DROP The first rule accepts packets with source address from our private IPv4 address network (10.0.0.0/24), while the second one drops every packet that approaches ens38 interface and needs to be forwarded. Those two rules take care of a malicious packet as it reaches the B4 side and before it heads towards the AFTR (see Fig. 8). 3) Third attack mitigation method: - One of the ways to mitigate this attack or at least reducing its impact, is by adding two (or more) IP addresses to AFTR ens35 interface (see Fig. 9), where the whole calculation will be double (or triple, depends on how many IP addresses we add) due to the fact that extended NAT works by binding IP / port pair together. The fact that ens35 has two IP addresses now, gives the AFTR more flexibility by having one additional pool of exactly the same port numbers of 64,512 ports, but they will be coupled with another source IP address. In case that two IP addresses were not enough to mitigate the attack, system administrator can easily add third, fourth, and more IP addresses as needed. On the practical side, we added two extra IP addresses on ens35 interface on AFTR. As a result, the AFTR was able to process all incoming 120,000 packets, unlike last time when it stopped after 64,512 packets. Another mitigation method is possible through rate limiting process which limits the number of packets per second that can be sent and received by the NIC (Network Interface Card) [44], it also enables the administrator to assign bandwidth restriction on specific traffic such as ICMP, UDP, etc. Some research work [45] and [46] have proposed the rate limiting mitigation mechanism after noticing the difference and the asymmetry between incoming and outgoing traffic in the designated network. 9. Conclusion We have shown in this paper the significance of transition technologies with the help of tunneling method and how practical it can be. Our testbed on the other hand has proven to be effective in terms of imitation a DS-Lite topology and examining its security vulnerabilities. As DS-Lite would normally function, our IPv4 client didn’t need public IPv4 address at its disposal to communicate with an IPv4 sever despite having an IPv6 island in the middle. Moreover, STRIDE method has also shown that every element within the DS-Lite topology can be targeted in so many ways. Therefore, further analysis and vulnerabilities patching is always required when it comes to IPv6 transition technologies and in especially when tunneling process is involved. The “thc-ipv6” toolkit was a great help and it provided us with variety of tools and attacking possibilities that can be demonstrated even in future research works. One of the most imminent threats that DS-Lite is liable to are DoS, tampering, spoofing and finally port number exhaustion. Declarations Acknowledgement In part, the resources of NICT StarBED, Japan were used for our experiment. The authors thank Shuuhei Takimoto for the opportunity to use the resources. The authors thank Dr. Sándor Répás, András Gerendás and Omar D’yab for their reading and commenting the manuscript. Funding The authors declare that no funds, grants, or other support were received during the preparation of this manuscript. BCompeting Interests The authors have no relevant financial or non-financial interests to disclose. C. Author Contributions All authors contributed to the study conception and design. Material preparation and testbed building by [Ameen Al-Azzawi], with the valuable support from [Gabor Lencse]. The first draft of the manuscript was written by [Ameen Al-Azzawi] and all authors commented on previous versions of the manuscript. All authors read and approved the final manuscript. D. CRediT Taxonomy Conceptualization: [Gabor Lencse]; Methodology: [Ameen Al-Azzawi]; Formal analysis and investigation: [Ameen Al-Azzawi]; Writing - original draft preparation: [Ameen AL-Azzawi]; Writing - review and editing: [Gabor Lencse], [Ameen Al-Azzawi]; Funding acquisition: [None]; Resources: [Ameen Al-Azzawi], [Gabor Lencse]; Supervision: [Gabor Lencse]. E. Data Availability Description Template The automation script used to build the whole topology, especially attacker machine This public GitHub repository of the first author contains several automation scripts to build every machine that were used to build the topology. https://github.com/ameen-mcmxc/DS-Lite_Test_Bed The “pcap” file generated by Wireshark software to capture the traffic at ens35 interface of AFTR machine in case of attack scenario 3. Results of the attack were published in the same public GitHub repository files directory: - https://github.com/ameen-mcmxc/DS-Lite_Test_Bed/blob/main/DNS_Perf_Results.pcap References G. Lencse and Y. Kadobayashi. (2018). Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64. Computers & Security, 77(1), 397-411. https://doi.org/10.1016/j.cose.2018.04.012. A. Al-Azzawi. (2020). Towards the Security Analysis of the Five Most Prominent IPv4aaS Technologies. Acta Technica Jaurinensis. 13(2), 85-98. https://doi.org/10.14513/actatechjaur.v13.n2.530 M. Bagnulo, A Sullivan, P. Matthews and I. Beijnum. (2011). DNS64: DNS extensions for network address translation from IPv6 clients to IPv4 servers. IETF RFC 6147. https://www.rfc-editor.org/info/rfc6147 M. Bagnulo, P. Matthews and I. Beijnum. (2011). Stateful NAT64: Network address and protocol translation from IPv6 clients to IPv4 servers. IETF RFC 6146. https://www.rfc-editor.org/info/rfc6146 M. Mawatari, M. Kawashima, C. Byrne. (2013). 464XLAT: Combination of stateful and stateless translation. IETF RFC 6877. https://www.rfc-editor.org/info/rfc6877 A. Al-Azzawi and G. Lencse. (2020). Towards the Identification of the Possible Security Issues of the 464XLAT IPv6 Transition Technology. In TSP 2020, 439-444. https://www.doi.org/10.1109/TSP49548.2020.9163487. A. Al-Azzawi and G. Lencse, (2021). Testbed for the Security Analysis of the 464XLAT IPv6 Transition Technology in a Virtual Environment. In TSP 2021, 5-9. https://www.doi.org/10.1109/TSP52935.2021.9522598. A. Al-Azzawi and G. Lencse. (2021). Identification of the Possible Security Issues of the 464XLAT IPv6 Transition Technology. Infocommunications Journal. 13(4), 10-18. https://doi.org/10.36244/ICJ.2021.4.2 Lencse, G. and Kadobayashi, Y. (2019). Comprehensive survey of IPv6 transition technologies: A subjective classification for security analysis. IEICE Transactions on Communications, 102 (10), 2021-2035. https://doi.org/10.1587/transcom.2018EBR0002. Durand, A., Droms, R., Woodyatt, J. and Lee, Y. (2011). Dual-stack lite broadband deployments following IPv4 exhaustion. IETF RFC 6333. https://www.rfc-editor.org/info/rfc6333 G. Lencse, J. Palet Martinez, L. Howard, R. Patterson, I. Farrer. (2022). Pros and cons of IPv6 transition technologies for IPv4aaS, Internet Draft. [cited 2022-06-28] [Online]. Available: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-comparison-04. Scott, O. (2019). The PPTP VPN protocol: Is it safe? - Infosec Resources. Retrieved July 22, 2022, from https://resources.infosecinstitute.com/topic/the-pptp-vpn-protocol-is-it-safe Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and Zorn, G. (1999). Point-to-point tunneling protocol (PPTP). IETF RFC 2637. https://www.rfc-editor.org/info/rfc2637 Schneier, B. (1998, November). Cryptanalysis of Microsoft's point-to-point tunneling protocol (PPTP). In Proceedings of the 5th ACM Conference on Computer and Communications Security 132-141. Zorn, Glen, and Steve Cobb. (1998). Microsoft ppp chap extensions. IETF RFC 2433. https://www.rfc-editor.org/info/rfc2433 Zorn, G. (2000). Microsoft PPP CHAP extensions, version 2. IETF RFC 2759. Krishnan, S., D. Thaler, and J. Hoagland. (2011). Security concerns with IP tunneling. IETF RFC 6169. https://www.rfc-editor.org/info/rfc6169 Carpenter, Brian, and Cyndi Jung. (1999). Transmission of IPv6 over IPv4 domains without explicit tunnels. IETF RFC 2529. Arkko, J., Kempf, J., Zill, B. and Nikander, P. (2005). Secure neighbor discovery (SEND). IETF RFC 3971. https://www.rfc-editor.org/info/rfc3971 Nordmark, E. and Inc, R.G. (2005). Basic Transition Mechanisms for IPv6 Hosts and Routers. IETF RFC 4213. Conta, A. and Deering, S. (1998). Generic packet tunneling in IPv6 specification. IETF RFC 2473. https://www.rfc-editor.org/info/rfc2473 Savola, P. and Patel, C. (2004). Security considerations for 6to4. IETF RFC 3964. https://www.rfc-editor.org/info/rfc3964 Abdulla, S.A. (2017). Survey of security issues in IPv4 to IPv6 tunnel transition mechanisms. International Journal of Security and Networks. 12(2), 83-102. Hogg, S. (2007). IPv6: Dual Stack Where You Can; Tunnel Where You Must. Retrieved June 15, 2022, from https://www.networkworld.com/article/2285078/ipv6-dual-stack-where-you-can-tunnel-where-you-must.html Yang, D., Song, X. and Guo, Q. (2010). Security on IPv6. 2nd IEEE International Conference on Advanced Computer Control, Shenyang, China, 323–326. Mi, W. (2014). The Applicability and Security Analysis of IPv6 Tunnel Transition Mechanisms. In International Conference on Algorithms and Architectures for Parallel Processing. 560-570. Springer, Cham. Hei, Y., Katsuno, S. and Ano, S. (2006). An implementation and evaluation of IPv6 end-to-end secure communication system for closed members. In International Symposium on Applications and the Internet Workshops (SAINTW'06). S. A. Amin and S. H. Choong. (2006). On IPv6 Traceback. Proceedings of the International Conference on Advanced Communication Technology (ICACT2006). Xie, L., Bi, J., & Wu, J. (2007). An authentication based source address spoofing prevention method deployed in IPv6 edge network. In International Conference on Computational Science 801-808. Springer, Berlin, Heidelberg. Lee, W. J., Heo, S. Y., Byun, T. Y., Sohn, Y. H., & Han, K. J. (2007, May). A secure packet filtering mechanism for tunneling over Internet. In International Conference on Embedded Software and Systems, 641-652. Springer, Berlin, Heidelberg. J. E. et al. Writing netfilter modules, July 2012. http://inai.de/documents/Netfilter_Modules.pdf. A. Shostack. (2014). Threat Modeling: Designing for Security. Wiley &Sons. Kristiyanto, Y. and Ernastuti, E. (2020). Analysis of Deauthentication Attack on IEEE 802.11 Connectivity Based on IoT Technology Using External Penetration Test. CommIT (Communication and Information Technology) Journal, 14(1), 45-51. Lee, Y., et al. (2013). Deployment considerations for dual-stack lite. IETF RFC 6908. https://www.rfc-editor.org/info/rfc6908 Fu, Y., et al. (2016). Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs). IETF RFC 7870. https://www.rfc-editor.org/info/rfc7870 Hankins, D., and T. Mrugalski. (2011). Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite. IETF RFC 6334. https://www.rfc-editor.org/info/rfc6334 Boucadair, M., C. Jacquenet, and S. Sivakumar. (2019). A YANG Data Model for Dual-Stack Lite (DS-Lite). IETF RFC 8513. https://www.rfc-editor.org/info/rfc8513 van Hauser Heuse, M. (2020). thc-ipv6 (Version 3.8) [Computer software]. https://github.com/vanhauser-thc/thc-ipv6 Making a synthesis emulation in IOT ERA possible Starbed5 Project Website. StarBED5 Project website /StarBED Equipment/. (n.d.). Retrieved from https://starbed.nict.go.jp/en/equipment/ D. P.Reed. (1980). User Datagram Protocol. IETF RFC 768. https://www.rfc-editor.org/info/rfc768 Netfilter conntrack performance tweaking v0.8, https://wiki.khnet.info/index.php/Conntrack_tuning Bakai Dániel: DNS64perf++ program, https://github.com/bakaid/dns64perfpp. G. Lencse, D. Bakai. (2017). Design and implementation of a test program for benchmarking DNS64 servers. IEICE Transactions on Communications, E100-B(6), 948-954. https://doi.org/10.1587/transcom.2016EBN0007 Noormohammadpour, M., & Raghavendra, C. S. (2017). Datacenter traffic control: Understanding techniques and tradeoffs. IEEE Communications Surveys & Tutorials, 20(2), 1492-1525. Gil, T. M., & Poletto, M. (2001). MULTOPS: A Data-Structure for Bandwidth Attack Detection. In 10th USENIX Security Symposium (USENIX Security 01). Mahajan, R., Bellovin, S. M., Floyd, S., Ioannidis, J., Paxson, V., & Shenker, S. (2002). Controlling high bandwidth aggregates in the network. ACM SIGCOMM Computer Communication Review, 32(3), 62-73. Cite Share Download PDF Status: Posted Version 1 posted You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {\"props\":{\"pageProps\":{\"initialData\":{\"identity\":\"rs-1972342\",\"acceptedTermsAndConditions\":true,\"allowDirectSubmit\":true,\"archivedVersions\":[],\"articleType\":\"Research Article\",\"associatedPublications\":[],\"authors\":[{\"id\":130739228,\"identity\":\"0089596d-763d-4041-beaf-c1561e74268b\",\"order_by\":0,\"name\":\"Ameen Al-Azzawi\",\"email\":\"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAAA3klEQVRIiWNgGAWjYDACdgjFwy/B2MAARAwMEoS0MEO1SM5gbGwgSQuDwQ2gHURp4W9mfvzxR81hGePbze0PGHdsk2OQ7jHAq0XiMJuBgcSxwzxmdw4CHXbmtjGDzBn8WhgOMxgkGLDd5jG7kQjU0nY7sUEiB78W+cPsHw4k/LvNYzwDoqWeoBaDwzyGDQfbbvMYSEC0JDAQ0mJ4mKeYsbHvP48E0GEzEs/cNmyTSCvAq0XuePvmjz++pdnzz0h/8OHjjtvy/BLJG/BqQQUJQMxGgvpRMApGwSgYBTgAAPh3SQBHAFA7AAAAAElFTkSuQmCC\",\"orcid\":\"https://orcid.org/0000-0001-7810-8458\",\"institution\":\"Budapest University of Technology and Economics: Budapesti Muszaki es Gazdasagtudomanyi Egyetem\",\"correspondingAuthor\":true,\"submittingAuthor\":false,\"prefix\":\"\",\"firstName\":\"Ameen\",\"middleName\":\"\",\"lastName\":\"Al-Azzawi\",\"suffix\":\"\"},{\"id\":130739229,\"identity\":\"c5be0d81-49c2-4483-a5d1-7e4e709cc612\",\"order_by\":1,\"name\":\"Gabor Lencse\",\"email\":\"\",\"orcid\":\"\",\"institution\":\"Budapest University of Technology and Economics: Budapesti Muszaki es Gazdasagtudomanyi Egyetem\",\"correspondingAuthor\":false,\"submittingAuthor\":false,\"prefix\":\"\",\"firstName\":\"Gabor\",\"middleName\":\"\",\"lastName\":\"Lencse\",\"suffix\":\"\"}],\"badges\":[],\"createdAt\":\"2022-08-17 20:35:51\",\"currentVersionCode\":1,\"declarations\":\"\",\"doi\":\"10.21203/rs.3.rs-1972342/v1\",\"doiUrl\":\"https://doi.org/10.21203/rs.3.rs-1972342/v1\",\"draftVersion\":[],\"editorialEvents\":[],\"editorialNote\":\"\",\"failedWorkflow\":false,\"files\":[{\"id\":25716248,\"identity\":\"1e67d6bc-194b-4af0-a0af-fabc17a6e7be\",\"added_by\":\"auto\",\"created_at\":\"2022-08-26 16:15:52\",\"extension\":\"png\",\"order_by\":1,\"title\":\"Figure 1\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":86086,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eOverview of the DS-Lite Architecture [11]\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"1.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-1972342/v1/b6c9638e804b2464880536ee.png\"},{\"id\":25716250,\"identity\":\"d76bbed3-0f4d-45a0-902a-dfbe1eb8cba6\",\"added_by\":\"auto\",\"created_at\":\"2022-08-26 16:15:52\",\"extension\":\"png\",\"order_by\":2,\"title\":\"Figure 2\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":22473,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eOverview of the DS-Lite Datagram path\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"2.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-1972342/v1/4d4c13ed045d7ff35e744622.png\"},{\"id\":25717088,\"identity\":\"dfc93965-0eff-4a17-8fb7-b47302d8597f\",\"added_by\":\"auto\",\"created_at\":\"2022-08-26 16:30:52\",\"extension\":\"png\",\"order_by\":3,\"title\":\"Figure 3\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":87816,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003e6in4 tunnel attacking scenario [23]\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"3.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-1972342/v1/782858fdc047e6acc1362fd7.png\"},{\"id\":25716257,\"identity\":\"ec1e8214-9dca-46af-a2fd-2386457d8953\",\"added_by\":\"auto\",\"created_at\":\"2022-08-26 16:15:52\",\"extension\":\"png\",\"order_by\":4,\"title\":\"Figure 4\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":29352,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003e4in6 tunnel encapsulation overview [21]\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"4.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-1972342/v1/eb5476e3c09a44c42ee6a425.png\"},{\"id\":25716812,\"identity\":\"fae0cd5f-13c7-4c52-a80c-04cd422730f9\",\"added_by\":\"auto\",\"created_at\":\"2022-08-26 16:25:52\",\"extension\":\"png\",\"order_by\":5,\"title\":\"Figure 5\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":38181,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eOverview of the DS-Lite Architecture\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"5.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-1972342/v1/e07cf813b66b68a478026db9.png\"},{\"id\":25717340,\"identity\":\"8ad282ec-24eb-4819-8cdd-56e47326ffd6\",\"added_by\":\"auto\",\"created_at\":\"2022-08-26 16:35:52\",\"extension\":\"png\",\"order_by\":6,\"title\":\"Figure 6\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":78429,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eDS-Lite Testbed (attack scenario-1)\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"6.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-1972342/v1/fef8fd453742819ac5c26b7d.png\"},{\"id\":25716685,\"identity\":\"3cf76430-14af-4ee9-9f70-ae9648cc84eb\",\"added_by\":\"auto\",\"created_at\":\"2022-08-26 16:20:52\",\"extension\":\"png\",\"order_by\":7,\"title\":\"Figure 7\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":186691,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eSpoofed packet echo reply\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"7.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-1972342/v1/a6c80fb7c4969b9eb3156a71.png\"},{\"id\":25716815,\"identity\":\"dffb3623-4dbc-4068-b57a-a22d8e0d1200\",\"added_by\":\"auto\",\"created_at\":\"2022-08-26 16:25:52\",\"extension\":\"png\",\"order_by\":8,\"title\":\"Figure 8\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":48863,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eDS-Lite Testbed (attack scenario-2)\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"8.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-1972342/v1/115185fac9e1080cb2cb737d.png\"},{\"id\":25716254,\"identity\":\"0f97963c-2d53-4bbf-8728-a5a147f381f1\",\"added_by\":\"auto\",\"created_at\":\"2022-08-26 16:15:52\",\"extension\":\"png\",\"order_by\":9,\"title\":\"Figure 9\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":61171,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eAttacking scenario-3 (AAAA queries)\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"9.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-1972342/v1/c049ce949818e4321e845ef9.png\"},{\"id\":25716680,\"identity\":\"bb4e7fd6-1c04-44e5-a2ba-ebbb8b29da68\",\"added_by\":\"auto\",\"created_at\":\"2022-08-26 16:20:52\",\"extension\":\"png\",\"order_by\":10,\"title\":\"Figure 10\",\"display\":\"\",\"copyAsset\":false,\"role\":\"figure\",\"size\":22563,\"visible\":true,\"origin\":\"\",\"legend\":\"\\u003cp\\u003eLast lines for Wireshark capture at ens35 on AFTR\\u003c/p\\u003e\",\"description\":\"\",\"filename\":\"10.png\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-1972342/v1/bc170c7b902747590adab650.png\"},{\"id\":31636706,\"identity\":\"a64f4f48-8423-4c84-ba58-960dd435cee2\",\"added_by\":\"auto\",\"created_at\":\"2023-01-16 15:38:50\",\"extension\":\"pdf\",\"order_by\":0,\"title\":\"\",\"display\":\"\",\"copyAsset\":false,\"role\":\"manuscript-pdf\",\"size\":1294936,\"visible\":true,\"origin\":\"\",\"legend\":\"\",\"description\":\"\",\"filename\":\"manuscript.pdf\",\"url\":\"https://assets-eu.researchsquare.com/files/rs-1972342/v1/36bf61cc-4215-4327-8093-91ad3bd79080.pdf\"}],\"financialInterests\":\"\",\"formattedTitle\":\"The Possible Security Issues of the DS-Lite IPv6 Transition Technology\",\"fulltext\":[{\"header\":\"1. Introduction\",\"content\":\"\\u003cp\\u003eAfter the depletion of the public IPv4 address pool in 2011 [1], many transition methods were presented to integrate the two IP versions (IPv4 and IPv6) and to tackle the IPv4 depletion challenge. We have conducted a survey of the most prominent IPv6 transition technologies [2], in which we have pointed out that the combination of DNS64 [3] and NAT64 [4] could be a working solution for the communication of IPv6 clients with IPv4 servers and we also showed the drawbacks of this particular technology and its challenges in terms of IPv4 literals communications (connection between IPv4 only devices while having IPv6 island in the middle) and the inability to establish the connection from IPv4 host side [2]. After that came the 464XLAT technology with its double translation mechanism, where two separate translators are deployed CLAT (client-side translator) \\u0026amp; PLAT (provider side translator), where some of DNS64\\u0026thinsp;+\\u0026thinsp;NAT64 issues were solved [5]. We have presented several papers regarding this transition technology. In [6], we presented the DFD (Data Flow Diagram) of 464XLAT and the security analysis of it by applying STRIDE method, where we showed the vulnerabilities and the potential security threats of this technology. In our next paper [7], we took it one step further when we built a testbed of 464XLAT using Debian based virtual machines and tested the performance of the PLAT under DoS (Denial of Service) attack to test the CPU performance and the pool of the source port numbers. In the latest one [8], we extended the previous paper [7] using a more powerful computer. Therefore, we were able to increase the number of attacking clients (virtual machines) from 1 to 8 clients and test the AFTR performance after attacking it using hping3 command. We proved that PLAT is susceptible to DoS attacks.\\u003c/p\\u003e \\u003cp\\u003eOn the other hand, DS-Lite has its own unique topology and application. It is a promising technology that enables the ISPs (Internet Service Providers) to use only IPv6 in their access and core network, while providing the users with fully functional IPv4 Internet access, too. DS-Lite has the highest deployment rate among the five important IPv4aaS (IPv4-as-a-Service) technologies (464XLAT, DS-Lite, Lw4o6, MAP-E, MAP-T) [9].\\u003c/p\\u003e \\u003cp\\u003eThe main target of this paper is to build and analyze the DFD of DS-Lite, test its security threats at every inbound and outbound gateway within its infrastructure, then eventually build a testbed for the DS-Lite topology and test its real capability under several kind of attacks scenarios and come up with potential mitigations of the outcome attacks.\\u003c/p\\u003e \\u003cp\\u003eIn Section 2, we discuss the operation of DS-Lite and its structure, section 3 is about tunneling in general and its security concerns. Section 4 discusses the operation of the STRIDE method, its elements and how it works. Section 5 is about applying the STRIDE method on our DS-Lite topology, while section 6 is about the related work that have done before as we mention some previous publications regarding DS-Lite security threats. In section 7, we build the testbed, explain its infrastructure and its topology elements, attacking scenarios and possible mitigation methods. In section 8, we summarize and conclude the value of the results the paper come up with. In this section we also prove the efficiency of DS-Lite and its flexibility to deal with all connection scenarios, especially when a private IPv4 address client wants to communicate with public IPv4 address server while there is IPv6 address island in middle. Finally, we summarize the security analysis of DS-Lite, its vulnerabilities and their mitigations methods.\\u003c/p\\u003e \\u003cp\\u003e \\u003c/p\\u003e\"},{\"header\":\"2. The Operation Of Ds-lite\",\"content\":\"\\u003cp\\u003eThe general purpose of DS-Lite is to provide the home network with IPv4 connectivity across an IPv6-only access network. DS-Lite was presented in RFC 6333 [10], where it consists of two main parts / functions (B4 \\u0026amp; AFTR). Figure\\u0026nbsp;1 illustrates the infrastructure of DS-Lite and how it functions.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cem\\u003eA. B4 (Basic bridging broadband)\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eThis router is responsible for encapsulating IPv4 packets into IPv6 ones then send it over IPv6 network till it reaches the AFTR router. It also has another vital role when it processes the returning packets from the AFTR toward the B4, where it de-capsulates the IPv6 packet and extracts the original IPv4 packet from the payload [10]. The tunnel that is created by the customer provided equipment (CPE), which is the B4, is called softwire tunnel which connects the B4 with the AFTR.\\u003c/p\\u003e\\n\\u003cp\\u003eSome facts about B4 router that was mentioned by RFC-6333 [10]:\\u003c/p\\u003e\\n\\u003cul\\u003e\\n \\u003cli\\u003e\\n \\u003cp\\u003eB4 announces itself as the default IPv4 router, this route is applicable for all IPv4 clients sitting behind this B4 router.\\u003c/p\\u003e\\n \\u003c/li\\u003e\\n \\u003cli\\u003e\\n \\u003cp\\u003eB4 router should also announce itself as a DNS server in the DHCP option 6 [10].\\u003c/p\\u003e\\n \\u003c/li\\u003e\\n \\u003cli\\u003e\\n \\u003cp\\u003eAs for the operation side, it acts as DNS proxy for all IPv4 clients who are willing to connect with it and beyond, it forwards those requests to the DNS server of the ISP (Internet Service Provider) [10].\\u003c/p\\u003e\\n \\u003c/li\\u003e\\n \\u003cli\\u003e\\n \\u003cp\\u003eB4 also forwards native IPv6 packets to the AFTR without any intervention.\\u003c/p\\u003e\\n \\u003c/li\\u003e\\n \\u003cli\\u003e\\n \\u003cp\\u003eThe default structure of DS-Lite is as explained above (client \\u0026rarr; CPE \\u003cspan style='color: rgb(0, 0, 0); font-family: \\\"Times New Roman\\\"; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;'\\u003e\\u0026rarr;\\u003c/span\\u003e\\u0026nbsp; ISP). However, some devices (IPv4 clients) are connected directly to the ISP without the home gateway. The reason behind that because those devices have the ability to act CPEs themselves [10].\\u003c/p\\u003e\\n \\u003cp\\u003eHost based: designed for large-scale deployments and especially when the client is directly connected to the service provider network, which means the IPv4 client, and the CPE are both mounted on the same device [10].\\u003cbr\\u003e\\u003cbr\\u003e\\u003c/p\\u003e\\n \\u003cp\\u003e\\u003cem\\u003eB AFTR (Address-Family transition Router)\\u003c/em\\u003e\\u003c/p\\u003eThe AFTR de-capsulates the 4in6 traffic that comes from the B4 router then it translates the IPv4 packet into public IPv4, which means that it also functions as a stateful NAT44 [10]. And, of course, it also performs the reverse functions for the returning packets.\\u003cp\\u003eThe technology in general has two types of topologies (Gateway based \\u0026amp; Host based architecture) and each one has its own applications.\\u003c/p\\u003e\\n \\u003c/li\\u003e\\n \\u003cli\\u003eGateway based: mostly based in residential broadband infrastructure, where the client and the CPE are based in different but directly connected machines [10].\\u003c/li\\u003e\\n \\u003cli\\u003eHost based: designed for large-scale deployments and especially when the client is directly connected to the service provider network, which means the IPv4 client, and the CPE are both mounted on the same device [10].\\u003c/li\\u003e\\n\\u003c/ul\\u003e\\n\\u003cp\\u003eIn this paper, we are focusing on the Gateway based architecture topology because this topology is easier to build for testing purposes and virtual environment. It is the most represented topology in residential households for example where we have IPv4 client\\u0026thinsp;\\u0026gt;\\u0026thinsp;\\u0026gt;\\u0026thinsp;router\\u0026thinsp;\\u0026gt;\\u0026thinsp;\\u0026gt;\\u0026thinsp;ISP.\\u003c/p\\u003e\\n\\u003cp\\u003eThe AFTR has two main interfaces (softwire interface \\u0026amp; network interface), each one of them faces one end of the device:\\u003c/p\\u003e\\n\\u003cp\\u003eSoftwire interface: its main function is connecting B4 with AFTR and translating the datagram of (softwire identifier\\u0026thinsp;+\\u0026thinsp;IPv4\\u0026thinsp;+\\u0026thinsp;source port) to another source IPv4 and source port. So, it decapsulates the IPv4 in IPv6 datagram (for the packets coming from B4 side) and does the reverse, by encapsulating IPv4 in IPv6 datagram (for the packets heading towards the B4 side).\\u003c/p\\u003e\\n\\u003cp\\u003eNetwork interface: sits on the other side of the AFTR (the WAN side) and translates the decapsulated source IPv4 and source port into the interface IP (192.0.2.1) and source port 5000 (just for our example). The interface is also in charge of the translation in the reverse direction (IPv4 server \\u0026loz; AFTR \\u0026loz; B4), where it translates the original packet\\u0026rsquo;s destination IP \\u0026amp; destination port (according to AFTR\\u0026rsquo;s Carrier Grade NAT translation table) to the destination IP and destination port of the softwire.\\u003c/p\\u003e\\n\\u003cp\\u003eFigure\\u0026nbsp;2 shows the outbound communication between B4 and AFTR. The NAT table in our example is configured in a way that translates any incoming packet with the source IP address: 10.0.0.1 and source port number: 10000 to 192.0.2.1:5000.\\u003c/p\\u003e\\n\\u003cul\\u003e\\n \\u003cli\\u003e\\n \\u003cp\\u003eOnce Datagram 1 reaches the B4 router, it will be encapsulated into Datagram 2, which is an IPv4 in IPv6 datagram, then forwarded to the AFTR through softwire tunnel.\\u003c/p\\u003e\\n \\u003c/li\\u003e\\n \\u003cli\\u003e\\n \\u003cp\\u003eWhen the AFTR receives datagram 2, it decapsulates it, extracts the IPv4 datagram from it and forwards it to the stateful NAT function, which performs the followings (according to its NAT table):\\u003c/p\\u003e\\n \\u003c/li\\u003e\\n \\u003cli\\u003e\\n \\u003cp\\u003eThe received datagram with source IP and port pair of 10.0.0.1:10000 should be translated to datagram 3 with the below specifications:\\u003c/p\\u003e\\n \\u003cp\\u003e\\u003cbr\\u003e\\u003c/p\\u003e\\n \\u003cul\\u003e\\n \\u003cli\\u003e\\n \\u003cp\\u003eSource IP and port pair: 192.0.2.1:5000.\\u003c/p\\u003e\\n \\u003c/li\\u003e\\n \\u003c/ul\\u003e\\n \\u003cp\\u003e\\u003c/p\\u003e\\u003cbr\\u003e\\n \\u003c/li\\u003e\\n\\u003c/ul\\u003e\\n\\u003cp\\u003eHow the AFTR translation table functions?\\u003c/p\\u003e\\n\\u003cp\\u003eThe IPv6 address for the B4 router is called softwire-ID. This ID is being shared by every client that wants to connect with the B4 router and triggers the DS-Lite communication process. Every single client of those is equipped (by the B4 router) with source IPv4 address [RFC 1918] such as 10.0.0.1 and it is unique within its network.\\u003c/p\\u003e\\n\\u003cp\\u003eWhen an embedded packet (source IP address: 10.0.0.1, source port number: 10000) is forwarded from B4 to AFTR through softwire tunnel, AFTR combines the softwire ID with this packet\\u0026rsquo;s details as one entry: softwire-id/IPv4/TCP/10000. In fact, this is only half of the entry. The other half will be AFTR network interface IPv4 address, the protocol identifier (e.g., TCP or UDP) and source port number: (192.0.2.1/TCP/5000) as shown in Table\\u0026nbsp;1. The reverse direction of the packet (IPv4 server\\u0026thinsp;\\u0026gt;\\u0026thinsp;AFTR\\u0026thinsp;\\u0026gt;\\u0026thinsp;B4\\u0026thinsp;\\u0026gt;\\u0026thinsp;IPv4 client) functions in a similar manner:\\u003c/p\\u003e\\n\\u003cp\\u003eAFTR receives datagram 4 through the network interface with public IPv4 address, then processes it by checking the internal NAT table looking for matching entry. In our case, datagram 4 has the following details:\\u003c/p\\u003e\\n\\u003cul style=\\\"list-style-type: circle;\\\"\\u003e\\n \\u003cli\\u003eIPv4 destination address: 192.0.2.1.\\u003c/li\\u003e\\n \\u003cli\\u003eDestination port: 5000.\\u003c/li\\u003e\\n \\u003cli\\u003e\\u003cspan style='color: rgb(0, 0, 0); font-family: \\\"Times New Roman\\\"; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: left; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial; display: inline !important; float: none;'\\u003eProtocol is TCP.\\u003c/span\\u003e\\u0026nbsp;\\u003c/li\\u003e\\n\\u003c/ul\\u003e\\n\\u003cul\\u003e\\n \\u003cli\\u003e\\n \\u003cp\\u003eThe corresponding entry does exist in the NAT table (see Table\\u0026nbsp;1), AFTR therefore translates the IPv4 packet of datagram 4 to IPv4 destination address: 10.0.0.1 and TCP destination port: 10000.\\u003c/p\\u003e\\n \\u003c/li\\u003e\\n \\u003cli\\u003e\\n \\u003cp\\u003eAFTR then encapsulates the translated IPv4 packet into an IPv6 packet and sends datagram 5 over to the B4 router at 2001:db8:0:1::2 IPv6 address (which the AFTR knows from the table entry itself as softwire ID).\\u003c/p\\u003e\\n \\u003c/li\\u003e\\n\\u003c/ul\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eTable. 1\\u003c/strong\\u003e\\u0026nbsp; Dual-Stack Lite Carrier-Grade NAT Translation Table [10]\\u003c/p\\u003e\\n\\u003ctable border=\\\"1\\\" cellpadding=\\\"0\\\" cellspacing=\\\"0\\\" width=\\\"0\\\"\\u003e\\n \\u003ctbody\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd width=\\\"63.07692307692308%\\\"\\u003e\\n \\u003cp\\u003eSoftwire-ID/IPv4/Protocol/Port\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"36.92307692307692%\\\"\\u003e\\n \\u003cp\\u003eIPv4/Protocol/Port\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd width=\\\"63.07692307692308%\\\"\\u003e\\n \\u003cp\\u003e2001:db8:0:1::2/10.0.0.1/TCP/10000\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"36.92307692307692%\\\"\\u003e\\n \\u003cp\\u003e192.0.2.1/TCP/5000\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003c/tbody\\u003e\\n\\u003c/table\\u003e\\n\\u003cul\\u003e\\n \\u003cli\\u003e\\n \\u003cp\\u003eB4 receives Datagram 5, de-capsulates the embedded packet, extracts the original IPv4 packet from the 4in6 Packet and forwards it accordingly to the IPv4 client (10.0.0.1:10000) as datagram 6.\\u003c/p\\u003e\\n \\u003c/li\\u003e\\n\\u003c/ul\\u003e\\n\\u003cp\\u003eTable 2 lists all IP addresses \\u0026amp; port numbers for the DS-Lite packet route for datagrams (1\\u0026ndash;6).\\u003c/p\\u003e\\n\\u003cp\\u003eTo understand the functionality of AFTR translation even more, please refer to RFC 6333 [10], where deep details about the translation steps are explained.\\u003c/p\\u003e\"},{\"header\":\"3. Tunneling\",\"content\":\"\\u003cp\\u003e\\u003cstrong\\u003eTable 2\\u003c/strong\\u003e\\u0026nbsp; DS-Lite Datagrams\\u003c/p\\u003e\\n\\u003cdiv\\u003e\\n \\u003ctable border=\\\"1\\\" cellpadding=\\\"0\\\" cellspacing=\\\"0\\\" width=\\\"0\\\"\\u003e\\n \\u003ctbody\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd width=\\\"33.910034602076124%\\\"\\u003e\\n \\u003cp\\u003eDatagram\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"66.08996539792388%\\\"\\u003e\\n \\u003cp\\u003eHeader Details\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd width=\\\"33.910034602076124%\\\"\\u003e\\n \\u003cp\\u003eIPv4 Datagram 1\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"66.08996539792388%\\\"\\u003e\\n \\u003cp\\u003eIPv4 Src : 10.0.0.1\\u003c/p\\u003e\\n \\u003cp\\u003eIPv4 Dst : 198.51.100.1\\u003c/p\\u003e\\n \\u003cp\\u003eTCP Src: \\u0026nbsp;10000\\u003c/p\\u003e\\n \\u003cp\\u003eTCP Dst : 80\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd width=\\\"33.910034602076124%\\\"\\u003e\\n \\u003cp\\u003eIPv6 Datagram 2\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"66.08996539792388%\\\"\\u003e\\n \\u003cp\\u003eIPv6 Src: 2001:db8:0:1::2\\u003c/p\\u003e\\n \\u003cp\\u003eIPv6 Dst: 2001:db8:0:1::1\\u003c/p\\u003e\\n \\u003cp\\u003eIPv4 Src: 10.0.0.1\\u003c/p\\u003e\\n \\u003cp\\u003eIPv4 Dst: 198.51.100.1\\u003c/p\\u003e\\n \\u003cp\\u003eTCP Src: 10000\\u003c/p\\u003e\\n \\u003cp\\u003eTCP Dst: 80\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd width=\\\"33.910034602076124%\\\"\\u003e\\n \\u003cp\\u003eIPv4 Datagram 3\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"66.08996539792388%\\\"\\u003e\\n \\u003cp\\u003eIPv4 Src: 192.0.2.1\\u003c/p\\u003e\\n \\u003cp\\u003eIPv4 Dst: 198.51.100.1\\u003c/p\\u003e\\n \\u003cp\\u003eTCP Src: 5000\\u003c/p\\u003e\\n \\u003cp\\u003eTCP Dst: 80\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd width=\\\"33.910034602076124%\\\"\\u003e\\n \\u003cp\\u003eIPv4 Datagram 4\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"66.08996539792388%\\\"\\u003e\\n \\u003cp\\u003eIPv4 Src:198.51.100.1\\u003c/p\\u003e\\n \\u003cp\\u003eIPv4 Dst: 192.0.2.1\\u0026nbsp;\\u003c/p\\u003e\\n \\u003cp\\u003eTCP Src: 80\\u003c/p\\u003e\\n \\u003cp\\u003eTCP Dst: 5000\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd width=\\\"33.910034602076124%\\\"\\u003e\\n \\u003cp\\u003eIPv6 Datagram 5\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"66.08996539792388%\\\"\\u003e\\n \\u003cp\\u003eIPv6 Src: 2001:db8:0:1::1\\u003c/p\\u003e\\n \\u003cp\\u003eIPv6 Dst: 2001:db8:0:1::2\\u003c/p\\u003e\\n \\u003cp\\u003eIPv4 Src: 198.51.100.1\\u003c/p\\u003e\\n \\u003cp\\u003eIPv4 Dst: 10.0.0.1\\u003c/p\\u003e\\n \\u003cp\\u003eTCP Src: 80\\u003c/p\\u003e\\n \\u003cp\\u003eTCP Dst: 10000\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd width=\\\"33.910034602076124%\\\"\\u003e\\n \\u003cp\\u003eIPv4 Datagram 6\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"66.08996539792388%\\\"\\u003e\\n \\u003cp\\u003eIPv4 Src: 198.51.100.1\\u003c/p\\u003e\\n \\u003cp\\u003eIPv4 Dst: 10.0.0.1\\u003c/p\\u003e\\n \\u003cp\\u003eTCP Src: 80\\u003c/p\\u003e\\n \\u003cp\\u003eTCP Dst: \\u0026nbsp;10000\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003c/tbody\\u003e\\n \\u003c/table\\u003e\\n\\u003c/div\\u003e\\n\\u003cp\\u003eA. \\u003cem\\u003eTunneling History\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eTunneling goes back to the 1990s when PPTP (point-to-point tunneling protocol) was presented by Microsoft engineers and some other vendors, where the original purpose was to support windows users with a data encryption, where it gained huge popularity among small and medium size corporations later on and it is in fact still being used to some extent [12]. Ever since it was under the microscope of critics. It was even presented as an RFC [13] in 1999. PPTP functions at Data Layer 2 and uses General Routing Encapsulation (GRE) as packet creation system, where GRE encapsulates the original packet inside another packet. Some vulnerabilities were discovered by Schneier [14] where he showed that PPTP has several weak points such as its Challenge/Response authentication protocol (CHAP), he also presented the fact that PPTP uses a very low security aware hashing algorithm, where eavesdropping was also quite easy to implement. Schneier [14] also emphasized that PPTP uses a low secured encryption standard called MPPE, which has a key that could be easily broken.\\u003c/p\\u003e\\n\\u003cp\\u003eAfter that, Microsoft presented another solution called MS-CHAPv1 [15] and then MS-CHAPv2 [16], which is used as one authentication option in Microsoft\\u0026apos;s implementation of the PPTP protocol for virtual private networks [15].\\u003c/p\\u003e\\n\\u003cp\\u003eThe most secure tunneling is OpenVPN and it has proven to be very hard to crack [12]. In conclusion, there are alternatives to the regular PPTP such as the IKEv2 and combination of IPsec and L2TP, which is used in Microsoft VPN (Virtual Private Network), and it is safer and quicker than regular PPTP [12]. Tunneling in general can come in so many forms such as MAP-E, 6over4, 6to4, Teredo, 6rd, DS-Lite, etc. [9]. It makes connection between two devices possible despite having different IP version island in the middle just like the case in DS-Lite tunnel example, though it brings some security threats with it.\\u003c/p\\u003e\\n\\u003cp\\u003eB. \\u003cem\\u003eTunneling Issues \\u0026amp; Solutions\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eThe most serious issue with tunneling is that tunneled IP traffic doesn\\u0026rsquo;t go through the same inspection process that the normal traffic (non-encapsulated packets) will be liable to unless extra dedicated devices are installed on the premise to double check the traffic as deep packet inspection [17]. For Instance, in Teredo tunnel the router will check the IP and UDP layer normally. However, it cannot find out that there is actually another IP layer encapsulated within the UDP payload.\\u003c/p\\u003e\\n\\u003cp\\u003eAnother issue with tunneling is, when the already encapsulated packet is targeting a host that lies further beyond the tunnel endpoint. In this case the machine will normally forward the packet simply to the built-in next hop [17].\\u003c/p\\u003e\\n\\u003cp\\u003eThe tunnelled data endpoints are aware of the tunnelled data and its encapsulated packets. The network devices in the middle are not, and that could be an issue [17].\\u003c/p\\u003e\\n\\u003cp\\u003eA solution is proposed by [17], where in case of IPv6 transition is required, native IPv6 is the way forward in terms of connecting two sides with tunneling solution, such as ISATAP, 6over4, etc. [18], in order to encapsulate traffic between a device and the router on the other side that resides in the same network. All that due to the difficulties that come with inspecting the inner content of encapsulated packet is a quite complicated process.\\u003c/p\\u003e\\n\\u003cp\\u003eNAT process also presents another challenge when it comes to tunneling, where it opens more doors for attacking possibilities on the incoming NAT interface. Therefore, it is recommended that the NAT interface shouldn\\u0026rsquo;t not be configured by default and only used when it is the last resort [17]. Another recommendation is to deactivate the interface itself after its usage [17].\\u003c/p\\u003e\\n\\u003cp\\u003eFurthermore, IP address guessing emerged as a potential risk to the tunnel end point, where some protocols use a regular or a well-known IP address or range of IP addresses. For instance, Teredo uses a specific IP address range in its infrastructure, which makes the tunnel liable to IP address guessing attack. Furthermore, sometimes guessing the IP address gives an indication about which kind of OS is being used. For instance, Teredo implies that the machine is most probably running Microsoft Windows. The solution is for sure no brainer, to avoid those well-known IP address ranges and to use random ones [17].\\u003c/p\\u003e\\n\\u003cp\\u003eOn the other hand, an adversary can have the ability to alter tunnel\\u0026rsquo;s server settings on the client side while the client itself having no idea about it. One way to avoid such breach, is to use authentication for both tunnel end-points like https [17]. A second mitigation method can be the use of secure ND (Neighbor Discovery) [18] whenever a client receives Router-Advertisement packet. Tunnels in general are less secure than normal conventional links due to the fact that an attacker can \\u003cstrong\\u003eFig. 4 4\\u003c/strong\\u003ein6 tunnel encapsulation overview [21] send an already encapsulated packet to the tunnel end node where it is supposed to be decapsulated [17]. This action might cause an injection of the faulty packet in the decapsulator side. This threat might be avoided by turning on decapsulation check which will drop such malicious packets [20], where a valuable recommendation was also mentioned that it is highly discouraged to set the tunnel interface to reply with acknowledging the existence of a tunnel like \\u0026ldquo;ICMP error message\\u0026rdquo;.\\u003c/p\\u003e\\n\\u003cp\\u003eIn general, [21] has mentioned two important general tunnel security points:\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; There is no correlation between amount of security regulations and procedures on the tunnel packets and the level of security measures applied of the original packet inside the tunnel (the payload) [21].\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; The security header authentication (HA) or encryption security payload (ESP) parameters are the deciding factors for the three security pillars (integrity, authentication, and confidentiality) of any tunnel endpoint [21].\\u003c/p\\u003e\\n\\u003cp\\u003eC. \\u003cem\\u003eAttack Scenarios\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eIn [22], the attack possibilities were categorized into three types:\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Denial of Service (DoS): the act of sending too many requests to a specific device to overwhelm its computation and processing power or bandwidth in order to force the targeted machine to drop or not serve the useful requests.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Reflecting DoS: where the attacker will reflect the traffic from normal (innocent) machines towards the targeted machine to do the harm.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Service theft: gaining unauthorized access.\\u003c/p\\u003e\\n\\u003cp\\u003eOne of the most used types of tunnels is the well-known 6in4 [23], which has several attacking scenarios. Each element within the IPv6 network sends RA message to declare that it is there and to allow other routers to update their table of existing IPv6 addresses. An attacker might take advantage of this process especially when all routers are sitting on the same network, which gives the possibility to attack the 6to4 router with Route-Advertisement (RA) message, by sending spoofed packet to the victim [22]. The second type is spoofing as explained by [23], where an attacker can take advantage of an existing tunnel and spoof one side of the tunnel endpoint and attack the other side as shown in Fig.\\u0026nbsp;3.\\u003c/p\\u003e\\n\\u003cp\\u003eThe reason behind implementing such an attack is because tunnels are not aware of what\\u0026rsquo;s behind the requester due to the absence of authentication which leads to the fact that a specific tunnel endpoint doesn\\u0026rsquo;t know which other endpoints do reside on the very same tunnel. The tunnel endpoint only assumes that packets do come from the other tunnel endpoint [24]. This lack of knowledge has raised the attention of attackers to exploit it, especially if the attacker\\u0026rsquo;s packet is difficult to trace. That means the attacker is able to conduct sniffing, spoofing and DoS attack by leveraging this vulnerability.\\u003c/p\\u003e\\n\\u003cp\\u003eIPv6 tunnels have some other weakness, where they are liable to password and \\u0026ldquo;internet key exchange\\u0026rdquo; attacks [25]. The golden rule according to [26] is that the security of the tunnel comes from the security of the tunnel endpoints themselves and the inner packets of the tunnel. If they are secured, then the tunnel in general is secured. So, to list the attacks that tunnels in general liable to, we end up with the followings:\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Sniffing.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Spoofing.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; DoS.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Password \\u0026amp; Internet key exchange.\\u003c/p\\u003e\\n\\u003cp\\u003eD. \\u003cem\\u003eMitigation Methods\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eEnd-to-end secure communication system such as IPsec [27] can help protect the tunnel endpoint nodes. Packet filters such as firewalls can also be helpful [27]. The only drawback with this solution is the inability to see the content of the packet at the edge firewall when applying filtering method, which means authentication and host validation step must be implemented.\\u003c/p\\u003e\\n\\u003cp\\u003eFurthermore, some research works suggest the usage of separate firewall filters, one for IPv4 packets and another for IPv6 packets, in order to make sure that every packet is being filtered and examined [23]. Another method is to deny the IPv6 tunnel by blocking a specific protocol and its associated ports [23]. In case of 6in4 tunnel, an attacker might inject an already encapsulated packet within the tunnel, that\\u0026rsquo;s why firewalls can be enabled to inspect tunneled packets and the firewall should also permit any 6in4 traffic which is generated from the same segment or from outside it as well, in order to be able to filter traffic behind the segment as well [23]. Finally, IPsec has the ability to block any traffic that didn\\u0026rsquo;t pass the authentication phase [23].\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eTable 3\\u003c/strong\\u003e Vulnerability of different DFD Elements to different Threats [32]\\u003c/p\\u003e\\n\\u003cdiv align=\\\"center\\\"\\u003e\\n \\u003ctable border=\\\"1\\\" cellpadding=\\\"0\\\" cellspacing=\\\"0\\\" width=\\\"0\\\"\\u003e\\n \\u003ctbody\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd width=\\\"13.706293706293707%\\\"\\u003e\\n \\u003cp\\u003eElement\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" width=\\\"8.251748251748252%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"13.006993006993007%\\\"\\u003e\\n \\u003cp\\u003eSpoofing\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"15.244755244755245%\\\"\\u003e\\n \\u003cp\\u003eTampering\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"16.783216783216783%\\\"\\u003e\\n \\u003cp\\u003eRepudiation\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"13.426573426573427%\\\"\\u003e\\n \\u003cp\\u003eInformation Disclosure\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"8.671328671328672%\\\"\\u003e\\n \\u003cp\\u003eDenial of Service\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"10.909090909090908%\\\"\\u003e\\n \\u003cp\\u003eElevation of Privilege\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd width=\\\"13.706293706293707%\\\"\\u003e\\n \\u003cp\\u003eData Flow\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" width=\\\"8.251748251748252%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"13.006993006993007%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"15.244755244755245%\\\"\\u003e\\n \\u003cp\\u003e✓\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"16.783216783216783%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"13.426573426573427%\\\"\\u003e\\n \\u003cp\\u003e✓\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"8.671328671328672%\\\"\\u003e\\n \\u003cp\\u003e✓\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"10.909090909090908%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd width=\\\"13.706293706293707%\\\"\\u003e\\n \\u003cp\\u003eData Stores\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" width=\\\"8.251748251748252%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"13.006993006993007%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"15.244755244755245%\\\"\\u003e\\n \\u003cp\\u003e✓\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"16.783216783216783%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"13.426573426573427%\\\"\\u003e\\n \\u003cp\\u003e✓\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"8.671328671328672%\\\"\\u003e\\n \\u003cp\\u003e✓\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"10.909090909090908%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd width=\\\"13.706293706293707%\\\"\\u003e\\n \\u003cp\\u003eProcesses\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" width=\\\"8.251748251748252%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"13.006993006993007%\\\"\\u003e\\n \\u003cp\\u003e✓\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"15.244755244755245%\\\"\\u003e\\n \\u003cp\\u003e✓\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"16.783216783216783%\\\"\\u003e\\n \\u003cp\\u003e✓\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"13.426573426573427%\\\"\\u003e\\n \\u003cp\\u003e✓\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"8.671328671328672%\\\"\\u003e\\n \\u003cp\\u003e✓\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"10.909090909090908%\\\"\\u003e\\n \\u003cp\\u003e✓\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd width=\\\"13.706293706293707%\\\"\\u003e\\n \\u003cp\\u003eInteractors\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" width=\\\"8.251748251748252%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"13.006993006993007%\\\"\\u003e\\n \\u003cp\\u003e✓\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"15.244755244755245%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"16.783216783216783%\\\"\\u003e\\n \\u003cp\\u003e✓\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"13.426573426573427%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"8.671328671328672%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd width=\\\"10.909090909090908%\\\"\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003c/tbody\\u003e\\n \\u003c/table\\u003e\\n\\u003c/div\\u003e\\n\\u003cp\\u003eAnother proposal was made by [28], which is based on the validation of the real source IP address by using IP trace-back method\\u003ca class=\\\"FNLink\\\" href=\\\"#Fn1\\\" id=\\\"#FNLinkFn1\\\"\\u003e\\u003c/a\\u003e, by doing so, the tunnel end point can drop any incoming spoofed IP packet. However, this technique comes also with its limitations, it cannot trace the packet source IP address till the tunnel endpoint node due the stateless IP routing, where a router can only see the next hop IP address, in which the tunnel end node cannot trace the incoming packet till its original sender, which means a full end-to-end route knowledge is unachievable [28].\\u003c/p\\u003e\\n\\u003cp\\u003eOne more spoofing mitigation trial has been introduced by [29], where it focuses of preventing the spoofed packet at the network edge. The principle is based on using authentication algorithm by the sender, where every packet has a unique generated signature attached to its extension header.\\u003c/p\\u003e\\n\\u003cp\\u003eFinally, Lee [30] has presented his own spoofing mitigation method, where he tackles sneaky packets, who are trying to avoid filters by presenting packet filtering mechanism using the well-known Linux Netfilter framework [31].\\u003c/p\\u003e\\n\\u003cp\\u003eE. \\u003cem\\u003eDS-Lite tunnel Challenges\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eIn fact, the literature is so rich with attack scenarios regarding 6in4 tunnels. However, there is so little to know about 4in6 tunnel in terms of security vulnerabilities. The concept might seem the same, but the implementation might differ a bit, and that leads us to our paper focusing point, DS-Lite and its security analysis.\\u003c/p\\u003e\\n\\u003cp\\u003eDS-Lite uses 4in6 tunneling, this type of tunneling was first presented in RFC 2473 [21], where IPv6 tunneling basically creates a link (virtual one) between the two ends of the tunnel. The IPv4 original packet will be sent as a payload encapsulated in the IPv6 tunnel packet as shown in Fig.\\u0026nbsp;4.\\u003c/p\\u003e\\n\\u003cp\\u003eThe process begins by grabbing the original IPv4 packet and prepending it to another IPv6 header (tunnel header) and sometimes the extension header, as it is an optional feature, then sending this encapsulated packet through the softwire tunnel to the other tunnel end-point node, where the packet will be decapsulated and the original packet will be extracted and forwarded according to its destination and routing table.\\u003c/p\\u003e\\n\\u003cp\\u003eFor better understanding of 4in6 tunnel components, the below tunnel terminologies had been clarified [21]:\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Virtual link: refers to the IPv6 tunnel itself.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Original Packet: the IPv4 packet that we want to send over the link, it consists of two components: packet header and payload\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Tunnel IPv6 header: refers to the IPv6 tunnel header without the payload.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Tunnel IPv6 packet: refers to the whole IPv6 tunnel packet (tunnel IPv6 header\\u0026thinsp;+\\u0026thinsp;original packet).\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Tunnel entry-point node: the responsible node for initiating the encapsulation process, also called \\u0026ldquo;encapsulator node\\u0026rdquo;. It is the source of the IPv6 tunnel packet.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Tunnel exit-point node: the responsible node for receiving the encapsulated packet then decapsulates it, extracting the original IPv4 packet components (header\\u0026thinsp;+\\u0026thinsp;payload) then forwarding the IPv4 packet to its destination, also called \\u0026ldquo;decapsulator node\\u0026rdquo;. It is the destination of the IPv6 tunnel packet.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; During packet forwarding process of the tunnel IPv6 packet, IPv4 header\\u0026rsquo;s (the original packet header) TTL value is decremented by 1.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eNote\\u003c/strong\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eboth end nodes are capable of encapsulation / decapsulation, the naming referred only to the function of the process initiators. DS-Lite has an advantage when it comes to DoS attack from random public IPv4 addresses. This is due to the following process:\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; AFTR receives an encapsulated packet, then it decapsulates it.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; If the extracted packet payload has source IPv4 address that is not private RFC 1918, then it will be immediately dropped.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; This built-in security feature gives DS-Lite the ability to stop DoS attacks stemming from unauthorized IPv4 addresses [10].\\u003c/p\\u003e\\n\\u003cp\\u003eDS-Lite, however, has a drawback due to the fact that it uses stateful translation on the AFTR side, which makes the machine liable to DoS attacks and limiting its scalability in case of expansion or the need in bigger projects, especially in case of having numerous amount of B4s routers within the infrastructure [11].\\u003c/p\\u003e\"},{\"header\":\"4. Stride Methodology\",\"content\":\"\\u003cp\\u003eSTRIDE stands for Spoofing, Tampering, Repudiation, Information disclosure and Elevation of privilege. The method was explained in detail in [32] and it summarized the general attacks that any network system may be vulnerable to, below is a brief description for each attack:\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Spoofing: the claim to be someone you aren\\u0026rsquo;t or the act of some malicious user who pretends to be e.g., your website [32].\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Tampering: the changing in the actual data flow between two nodes [32].\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Repudiation: the ability of the sender to deny the fact that he did send a specific packet or sign a specific document [32].\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Information Disclosure: the access to confidential information that one should not have, like TTL value of a packet or confidential data such as like online banking credentials or any other login credentials [32].\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Denial of Service: the process of overwhelming a specific server or network connection with huge number of useless queries or data in order to block the legitimate ones from getting a reply or even being processed [32]. In another word, DoS makes the targeted machine unavailable for its original purpose.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Elevation of Privileges: the access of a specific user to a certain level of sensitive data which might be strictly confidential file that meant to be for upper management or to root user for instance [32].\\u003c/p\\u003e\\n\\u003cp\\u003eAccording to [32], the best method to test system\\u0026rsquo;s vulnerabilities is to build DFD (Data Flow Diagram) for the system and apply the STRIDE method on it. Table 3 shows the different potential security threats for each DFD element.\\u003c/p\\u003e\"},{\"header\":\"5. Applying Stride On Ds-lite\",\"content\":\"\\u003cp\\u003eThe first step in applying the STRIDE method is to build the DFD of the examined system and specify the potential attacking points at each element. Therefore, we built the DFD for DS-Lite in Fig.\\u0026nbsp;5, where it shows the spots (1\\u0026ndash;11). The security analysis will be divided into several groups such as the traffic between the client and B4, then between B4 and the AFTR, etc.\\u003c/p\\u003e\\n\\u003cp\\u003eA. \\u003cem\\u003eIPv4 client.\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003e1) \\u003cem\\u003eSpoofing\\u003c/em\\u003e: A malicious user might spoof the IP address of the client and attack the B4 router by sending many useless requests to the B4 and fully utilizing its computation power.\\u003c/p\\u003e\\n\\u003cp\\u003e2) \\u003cem\\u003eRepudiation\\u003c/em\\u003e: The request initiator might deny the fact that he made the request in the first place. By doing so, a malicious user might attack the B4 router then deny the fact he was the one who sent this specific request such as echo request, DNS resolution request, etc.\\u003c/p\\u003e\\n\\u003cp\\u003eB. \\u003cem\\u003eData flow from the Client to B4 router.\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003e1) \\u003cem\\u003eTampering\\u003c/em\\u003e: An adversary might tamper (change or modify) the content of the flowing packets like IP address, source port number, etc. The attacker might also diverge the packet toward a fraudulent server which might cause FoS (Failure of Service) attack which is the prevention of the legitimate requester from getting a response [1].\\u003c/p\\u003e\\n\\u003cp\\u003e2) \\u003cem\\u003eInformation Disclosure\\u003c/em\\u003e: An attacker might get hold of confidential information like TTL value of a packet, e.g., some sensitive information sent by the client as a plain text or the browsing habit of the client himself [1].\\u003c/p\\u003e\\n\\u003cp\\u003e3) \\u003cem\\u003eDenial of Service\\u003c/em\\u003e: An attacker sends too many useless requests to the B4 router and blocking the legitimate requester from having his query getting processed.\\u003c/p\\u003e\\n\\u003cp\\u003eC. \\u003cem\\u003eData flow from B4 router to IPv4 client.\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003e1) \\u003cem\\u003eTampering\\u003c/em\\u003e: in this case, the potential victim is the client himself, which is vulnerable to an attack at application level such as sending TCP RST signal that will end the already established TCP connection [6] and also deauthentication attack [33] that results in disconnecting the device from the router\\u0026rsquo;s Wi-Fi. In addition to plain text injection attack [33] that allows B4 router to send misleading information to the client such as false routing details.\\u003c/p\\u003e\\n\\u003cp\\u003e2) \\u003cem\\u003eInformation Disclosure\\u003c/em\\u003e: an attacker getting access to sensitive information in a malicious way such as an important text sent back by the IPv4 server behind AFTR.\\u003c/p\\u003e\\n\\u003cp\\u003e3) \\u003cem\\u003eDenial of Service\\u003c/em\\u003e: sending high number of forged replies to overwhelm the client and prevent the client from sending more requests to the B4.\\u003c/p\\u003e\\n\\u003cp\\u003eD. \\u003cem\\u003eB4 router.\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003e1) \\u003cem\\u003eSpoofing\\u003c/em\\u003e: Another machine presents itself as the legitimate B4 router and starts communicating with the rest of DS-Lite network elements, which puts everyone that deals with this machine at high risk such as a malicious device initiating a communication with AFTR router and presents itself as the B4 router which leads to whole traffic (from AFTR side) pouring into the wrong direction, by changing the destination IP address of the packet, which results in the original sender not getting a response for his request. Another consequence could be when the malicious server starts recording the data passing through and using it for illegal activities such as blackmailing.\\u003c/p\\u003e\\n\\u003cp\\u003e2) \\u003cem\\u003eTampering\\u003c/em\\u003e: modifying the current source and destination address of the 4in6 traffic that is being processed within B4 router in order to shift the traffic and prevent it from being sent to the real AFTR and forwards it to a malicious server. Another possibility could be tampering with the IP address/port pair of the sender which results eventually in a different entry in the AFTR translation table and therefore the packet reply will not return back to the original sender.\\u003c/p\\u003e\\n\\u003cp\\u003e3) \\u003cem\\u003eRepudiation\\u003c/em\\u003e: in this case, when the B4 is spoofed, then the malicious user will deny the fact that he sent a specific packet while he did. The obvious solution to this issue is proper logging [6].\\u003c/p\\u003e\\n\\u003cp\\u003e4) \\u003cem\\u003eInformation Disclosure\\u003c/em\\u003e: attacker getting access to sensitive data within the router such as client\\u0026rsquo;s source IP address, TTL value, browsing data, etc.\\u003c/p\\u003e\\n\\u003cp\\u003e5) \\u003cem\\u003eDenial of Service\\u003c/em\\u003e: flooding AFTR router with unnecessary request in order to overwhelm the AFTR and stopping it from processing any further incoming packets, see section V.B.3.\\u003c/p\\u003e\\n\\u003cp\\u003e6) \\u003cem\\u003eElevation of Privileges\\u003c/em\\u003e: the attacker gets access to high level (privileged) data, and it mainly occurs due to inside job [1], when an employee is implicit in the act.\\u003c/p\\u003e\\n\\u003cp\\u003eE. \\u003cem\\u003eData flow from B4 to AFTR\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003e1) \\u003cem\\u003eTampering\\u003c/em\\u003e: 4in6 traffic might be altered, the source IP address or port number are liable to be modified by attacker.\\u003c/p\\u003e\\n\\u003cp\\u003e2) \\u003cem\\u003eInformation Disclosure\\u003c/em\\u003e: the access to confidential information in many ways, see section V.B.2.\\u003c/p\\u003e\\n\\u003cp\\u003e3) \\u003cem\\u003eDenial of Service\\u003c/em\\u003e: the flood of useless queries to exhaust the AFTR and hinder its main job, see section V.B.3.\\u003c/p\\u003e\\n\\u003cp\\u003eF. \\u003cem\\u003eData flow from AFTR to B4.\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003e1) \\u003cem\\u003eTampering\\u003c/em\\u003e: modifying the traffic details before it reaches the B4 router, such as the source IP address or port number of the 4in6 flowing traffic.\\u003c/p\\u003e\\n\\u003cp\\u003e2) \\u003cem\\u003eInformation Disclosure\\u003c/em\\u003e: the unauthorized access to sensible data, see section V.B.2.\\u003c/p\\u003e\\n\\u003cp\\u003e3) \\u003cem\\u003eDenial of Service\\u003c/em\\u003e: flooding the B4 router with useless traffic. See section V.B.3.\\u003c/p\\u003e\\n\\u003cp\\u003eG. \\u003cem\\u003eAFTR router.\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003e1) \\u003cem\\u003eSpoofing\\u003c/em\\u003e: attacker impersonates the AFTR and starts communication with the rest of machines around him such as B4 router and IPv4 server, which might lead to exchanging sensitive data with the wrong person, see section V.D.1.\\u003c/p\\u003e\\n\\u003cp\\u003e2) \\u003cem\\u003eTampering\\u003c/em\\u003e: changing the content of the 4in6 packet payload, see section V.D.2.\\u003c/p\\u003e\\n\\u003cp\\u003e3) \\u003cem\\u003eRepudiation\\u003c/em\\u003e: hiding the packet sender identity, see section V.D.3.\\u003c/p\\u003e\\n\\u003cp\\u003e4) \\u003cem\\u003eInformation Disclosure\\u003c/em\\u003e: the possibility of an attacker getting access to the confidential data, see section V.B.4.\\u003c/p\\u003e\\n\\u003cp\\u003e5) \\u003cem\\u003eDenial of Service\\u003c/em\\u003e: various type of attacks can be described in this section, such as exhausting the AFTR with too many useless requests and hinder the process of encapsulating the desired packet.\\u003c/p\\u003e\\n\\u003cp\\u003e6) \\u003cem\\u003eElevation of Privileges\\u003c/em\\u003e: the act of unauthorized access to very confidential data center of a specific folder in a malicious way, see section V.D.6\\u003c/p\\u003e\\n\\u003cp\\u003eH. \\u003cem\\u003eInternal connection tracking table of the AFTR.\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003e1) \\u003cem\\u003eTampering\\u003c/em\\u003e: an attacker can manipulate the connection tracking table of the AFTR router that saves the incoming 4in6 traffic packet with its source address and port number and map it with a destination IPv4 device according to the stateful NAT rule within the router (see Table 1). So, the manipulation can cause a faulty destination address and disturb the encapsulation process and end up with a packet loss.\\u003c/p\\u003e\\n\\u003cp\\u003e2) \\u003cem\\u003eDenial of Service\\u003c/em\\u003e: flooding the connection tracking table with too many unnecessary entries (false connections) might overwhelm the table beyond its capabilities and cause it to flush its data or saturate the AFTR itself, and that means the AFTR will no longer able to process any incoming packet or at least it will lose some legitimate connections.\\u003c/p\\u003e\\n\\u003cp\\u003eI. \\u003cem\\u003eData flow from AFTR to IPv4 server\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003e1) \\u003cem\\u003eTampering\\u003c/em\\u003e: the destination IP of the traffic might be altered and redirected to a malicious server instead of being directed to the legitimate IPv4 server.\\u003c/p\\u003e\\n\\u003cp\\u003e2) \\u003cem\\u003eInformation Disclosure\\u003c/em\\u003e: unauthorized access to sensitive data of the IPv4 traffic.\\u003c/p\\u003e\\n\\u003cp\\u003e3) \\u003cem\\u003eDenial of Service\\u003c/em\\u003e: overwhelming the host with too many requests, see section V.C.3\\u003c/p\\u003e\\n\\u003cp\\u003eJ. \\u003cem\\u003eData flow from IPv4 server to AFTR.\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003e1) \\u003cem\\u003eTampering\\u003c/em\\u003e: the IPv4 packets might be altered in terms of IP source address or port number, which will definitely change the corresponding 4in6 traffic details.\\u003c/p\\u003e\\n\\u003cp\\u003e2) \\u003cem\\u003eInformation Disclosure\\u003c/em\\u003e: unauthorized access to IPv4 traffic before it reaches the AFTR router, which might leak the confidential browsing habit of the client, see section V.B.2.\\u003c/p\\u003e\\n\\u003cp\\u003e3) \\u003cem\\u003eDenial of Service\\u003c/em\\u003e: exhausting the AFTR and its main encapsulation function, see section V.E.3.\\u003c/p\\u003e\\n\\u003cp\\u003eK. \\u003cem\\u003eIPv4 server\\u003c/em\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003e1) \\u003cem\\u003eSpoofing\\u003c/em\\u003e: an attacker impersonates the IPv4 server and initiate a communication with AFTR and the rest of DS-Lite Topology.\\u003c/p\\u003e\\n\\u003cp\\u003e2) \\u003cem\\u003eRepudiation\\u003c/em\\u003e: The host (IPv4 sever) might hide his identity, perform all sorts of malicious acts then deny any responsibilities for them. For example, in previous point of spoofing, the attacker might spoof the IPv4 server, performs an attack against AFTR, then denies the fact that he initiated the communication in the first place.\\u003c/p\\u003e\"},{\"header\":\"7. Related Work\",\"content\":\"\\u003cp\\u003eVery few experiments were actually published regarding DS-lite and its security analysis. Therefore, we are grabbing the opportunity to take the lead in this uncharted territory. A survey for the most prominent IPv6 transition technologies and their security analysis was made by us in [9].We mentioned DS-Lite, and classified its security analysis as important but replaceable, and that was due to several issues mentioned by [34] such as the following ones:\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; The need for two separate physical interfaces at the AFTR.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; The need for high scalability at the AFTR side due to the fact that many B4 routers maybe connected to same AFTR [34].\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; The location of deploying AFTR router within the ISP network and the trade-off it creates between the high operation cost and installing an extremely powerful AFTR [34]. The trade-off can be explained by dividing the issue in hand into two options:\\u003c/p\\u003e\\n\\u003cp\\u003eo Deploying AFTR at the edge of the network to cover small area, serves few B4s, requires less powerful AFTR.\\u003c/p\\u003e\\n\\u003cp\\u003eo Deploying AFTR at the core of the network to cover a big area, covers more B4s, requires extremely powerful AFTR (or even more than one AFTRs)\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; The complexity of deploying a proxy DNS resolver, which will proxy every DNS query stemming from all IPv4 clients heading towards a DNS server that resides in IPv6 network [34].\\u003c/p\\u003e\\n\\u003cp\\u003eAnother work by [35] has conducted a security analysis for DS-Lite in terms of its MIB (Management Information Base), and it consists of several objects. MIB is a module that can be used to monitor the AFTR router within DS-Lite infrastructure by leveraging SNMP (Simple Network Management Protocol). According to [35], the most vulnerable objects that are susceptible to attacks are:\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Notification threshold objects: an attacker manipulating a threshold\\u0026rsquo;s value to a very low level, which will lead to a flood of useless alarms and thus disrupt the AFTR and its monitoring mechanism, or he sets it to a very high value to the level that makes the idea of setting the alarm literally useless.\\u003c/p\\u003e\\n\\u003cp\\u003eo DsliteAFTRAlarmConnectNumber: The alarm is sent when the number of current DS-Lite tunnels reached the threshold, which means for every B4 router, the AFTR has to have a separate tunnel for it.\\u003c/p\\u003e\\n\\u003cp\\u003eo DsliteAFTRAlarmSessionNumber: an alarm will be sent when threshold of sessions per IPv4 users is reached. This metric goes hand in hand with RFC-6333 [10], where AFTR has to be able to log softwire ID, IP, ports, protocol (see table 1) in order keep track of user sessions.\\u003c/p\\u003e\\n\\u003cp\\u003eo DsliteAFTRAlarmPortNumber: an alarm is to be sent when the threshold for number of ports used by a user is reached or even crossed.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Table entry objects: an attacker can alter the content of such entries causing the drop of legitimate entries or adding harmful and faulty ones:\\u003c/p\\u003e\\n\\u003cp\\u003eo DsliteTunnelTable: consists of mapping entries of B4 address to AFTR address.\\u003c/p\\u003e\\n\\u003cp\\u003eo DsliteNATBindTable: contains entries about the current active bindings within the NAT table of the AFTR (see Table\\u0026nbsp;1).\\u003c/p\\u003e\\n\\u003cp\\u003eWhat makes those tables\\u0026rsquo; entries a potential security threat is the possibility of an attacker assessing the number of hosts being served by a single AFTR router, which relevels sensitive information about the whole topology of DS-Lite [35]. A chance of an inside job is also possible, where an internal employee can access the list of hosts that are in active sessions which will be a violation to the subscriber\\u0026rsquo;s privacy [35]. Moreover, RFC-6334 [36] referred to DS-Lite security briefly and recommended that IP firewall must be implemented in order to avoid MitM attack along the softwire connection of DS-Lite.\\u003c/p\\u003e\\n\\u003cp\\u003eRFC-8513 [37] proposed another method to implement DS-Lite using YANG module which is a schema that facilitates data accessing mechanism through network management protocol like NETCONF and RESTCONF. This module allows the administrator to add some features and addons to the B4 and AFTR interfaces such as \\u0026ldquo;b4-address-change-limit\\u0026rdquo;, \\u0026ldquo;Tunnel-MTU (Maximum Transmission Unit)\\u0026rdquo;, etc.\\u003c/p\\u003e\\n\\u003cp\\u003eMoreover, RFC-8513 [37] also suggested a solution for DoS attack raising \\u0026apos;b4-address-change-limit\\u0026apos;. This value specifies the minimum time between two consecutive changes of the IPv6 address of the B4 device. Setting it to a low value, would enable the attacker to send higher number attacking packets with different source addresses. The recommended mitigation is to set its value to 30 minutes.\\u003c/p\\u003e\\n\\u003cp\\u003eIn RFC-8513 [37], the authors presented the security analysis of their DS-Lite architecture, where emphasized that the main vulnerability is an attacker having access to either B4 or AFTR router and undertaking several kinds of malicious activities.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Manipulating the AFTR IPv6 address on B4 tunnel end point, which will deceive the B4 router and force it to forward the 4in6 traffic to the wrong recipient.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u0026bull; Altering the value of \\u0026ldquo;b4-address-change-limit\\u0026rdquo; which gives the B4 more flexibility in configuring the softwire. An attacker lowering this value will boost the possibility of DoS attack against B4 router.\\u003c/p\\u003e\"},{\"header\":\"8. Ds-lite Testbed\",\"content\":\"\\u003cp\\u003eA. \\u003cem\\u003eTestbed Topology and specifications\\u003c/em\\u003e\\u003c/p\\u003e \\u003cp\\u003eAs shown in Fig.\\u0026nbsp;6, our testbed consists of five machines (IPv4 client, B4, AFTR, IPv4 server and attacker). They were all based on VMware workstation VMs, and those machines were built upon CentOS-7 images. Every machine had the following specifications:\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; RAM: 3 GB\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; Hard disk: 20 GB\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; CPU: 1 core\\u003c/p\\u003e \\u003cp\\u003eThe host PC that hosted the whole testbed had the below specifications:\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; OS: Windows 10 Pro.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; RAM: 16 GB.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; Hard disk: 1TB.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; CPU: Intel-Core i7, 4 physical cores.\\u003c/p\\u003e \\u003cp\\u003eIPIP6 tunnel was built between B4 and AFTR which took care of encapsulating IPv4 packet inside IPv6 tunnel then de-capsulating it. As for the NAT process on AFTR side, iptables rule was configured to masquerade the source IP address to the AFTR\\u0026rsquo;s network interface (ens35).\\u003c/p\\u003e \\u003cp\\u003eWe note that the above setup contains an important simplification compared to Table\\u0026nbsp;1: the Softwire-ID is missing from the connection tracking table. This change did not influence our experiments, whereas it simplified the setup of our testbed: we could use \\u003cb\\u003eiptables\\u003c/b\\u003e instead of a real AFTR implementation.\\u003c/p\\u003e \\u003cp\\u003eB. \\u003cem\\u003eAttack scenarios\\u003c/em\\u003e\\u003c/p\\u003e \\u003cp\\u003ei. \\u003cem\\u003eSpoofing Attack from within VMnet-11 (an inside job)\\u003c/em\\u003e\\u003c/p\\u003e \\u003cp\\u003eThe proposed attack as shown in Fig.\\u0026nbsp;6 is Spoofing the ingress tunnel end point (ens39), which is the softwire tunnel interface of the B4 router, then sniffing / logging traffic or perform MitM attack against egress tunnel end point (AFTR).\\u003c/p\\u003e \\u003cp\\u003eThe attack was based on the \\u0026ldquo;thc-ipv6\\u0026rdquo; toolkit [38], which has several tools within it. One powerful tool was chosen to perform the attack (four2six). What it actually does is manually creating a crafted packet of IPv4 inside IPv6 (encapsulated packet) and send it over the channel to the victim (AFTR).\\u003c/p\\u003e \\u003cp\\u003eThis crafted packet is actually a spoofed one imitating that it was sent by the B4 router, where it has the same specifications as of a genuine B4 originated packet:\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; IPv6 Src: 2001:db8:0:1::2\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; IPv6 Dst: 2001:db8:0:1::1\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; IPv4 Src: 10.0.0.2\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; IPv4 Dst: 198.51.100.2\\u003c/p\\u003e \\u003cp\\u003eIn fact, the spoofed attack went through AFTR then to the end receiver (IPv4 server) and series of ICMP echo requests and replies had been exchanged between the attacker and victim. In more details, what happened is:\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; The AFTR received the malicious packet.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; The AFTR saw the packet as a 4in6 packet, therefore, it then decapsulated the packet.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; The AFTR then forwarded the extracted IPv4 packet with source address of 198.51.100.1 towards the IPv4 server (198.51.100.2).\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; IPv4 server sent ICMPv4 echo reply back.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; The AFTR saw the later packet and encapsulated it in IPv6 packet.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; The echo reply from the AFTR, which is an IPv6 packet with IPv4 packet in its payload, is sent back to its destination IPv6 of address 2001:db8:0:1::2.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; Figure\\u0026nbsp;7 shows three different terminals, the top one is the incoming packets at attacker interface, the one in the middle is the B4 incoming traffic from the AFTR side, and at the bottom is the incoming traffic at IPv4 client.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; B4 received the IPv6 packet carrying an IPv4 packet with ICMP echo reply because it is the legitimate owner of the 2001:db8:0:1::1 IPv6 destination address.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; The Attacker saw the same reply because its NIC runs in promiscuous mode.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; The interesting thing here is illustrated by IPv4 client receiving an ICMP4 echo reply for a request that he didn\\u0026rsquo;t request in the first place, which has been issued by the attacker initially.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; Echo replies in Fig.\\u0026nbsp;7 are circulated in red.\\u003c/p\\u003e \\u003cp\\u003eii. \\u003cem\\u003eAttack from within VMnet-10 (compromised B4 network)\\u003c/em\\u003e\\u003c/p\\u003e \\u003cp\\u003eIt is also worth mentioning that B4 by design is also capable of routing native IPv6 packets, which takes us to Fig.\\u0026nbsp;8, where we added IPv6 address to interface ens38 at the B4 machine in order to process and forward incoming IPv6 packets.\\u003c/p\\u003e \\u003cp\\u003eA real-life spoofing scenario could also be stopped before reaching our internal network of AFTR (VMnet-11 in our example). Therefore, another attacking scenario was proposed in Fig.\\u0026nbsp;8, where the attacker is not sitting directly in AFTR network, but outside it. The idea behind such an attack is an attacker having access to our home router network, which gives him direct contact with the CPE. This access allows the attacker to send a crafted packet with spoofed IPv6 address of a B4 router or any other IPv6 address from the internal network of AFTR (VMnet-11 in our example).\\u003c/p\\u003e \\u003cp\\u003eFortunately for the user, the attack didn\\u0026rsquo;t go through, B4 router was always dropping any incoming packet from the attacker-2 machine that has an IP address (a spoofed one) from the pool of (VMnet-11). It seems like an internal security feature within the machine.\\u003c/p\\u003e \\u003cp\\u003eiii. \\u003cem\\u003eSource port exhaustion attack from within VMnet-10\\u003c/em\\u003e\\u003c/p\\u003e \\u003cp\\u003eAt first, the attack was conducted using the same platform, regular specs windows-based computer, however, the results were not stable and not reproducible due to limited cores on the host PC. Therefore, we made the decision to use the resources of NICT StarBED, Japan. A \\u0026ldquo;P\\u0026rdquo; series node [39] was used, which is a Dell PowerEdge 430 server with the following specifications: Two Intel(R) Xeon(R) CPU E5-2683 v4 @ 2.1 GHz CPUs having 16 cores each and 348 GB 2400MHz DDR4 SDRAM.\\u003c/p\\u003e \\u003cp\\u003eWindows 10 Pro operating system was installed, and the same process was repeated by building the testbed using VMware workstation player and CentOS-7 based virtual machines. The specifications for each machine were as follow:\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; RAM: 4 GB\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; Cores: 4 cores, except for AFTR having 6 cores.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; Disk: 20 GB.\\u003c/p\\u003e \\u003cp\\u003eBefore disclosing the attack details, it is important to explain the mathematical sense behind it. In networking world, ports are counted based on 16 bits standard. The 16-bits was chosen when the TCP and UDP standards were designed [40]. As a result, the maximum number of ports equals 2\\u003csup\\u003e16\\u003c/sup\\u003e = 65,536. This number applies to TCP and UDP ports. In our experiment, we focus on the UDP ports and how to exhaust them by sending too many queries (UDP requests) in short period of time. However, not all ports on range are usable for establishing new connection, because ports between 1 and 1024 are called well-known ports and they are reserved for specific functions such as FTP, HTTP, DNS, etc. Therefore, the total range of ports that NAPT (Network Address and Port Translation) device can use as UDP source port numbers equals 65,536\\u0026ndash;1024\\u0026thinsp;=\\u0026thinsp;64,512 ports.\\u003c/p\\u003e \\u003cp\\u003eFigure\\u0026nbsp;9 shows the attacking scenario-3 by sending too many AAAA queries from \\u0026ldquo;IPv4 Client-1\\u0026rdquo; and \\u0026ldquo;IPv4 Client-2\\u0026rdquo; machines. In order for the attack to function, few files must be correctly configured, such as:\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; /sys/module/nf_conntrack/parameters/hashsize\\u003c/p\\u003e \\u003cp\\u003eThe HASHSIZE is actually the size of hash table storing the lists of conntrack entries [41], which is better of as base of 2, which means that hashsize could be 2\\u003csup\\u003e14\\u003c/sup\\u003e = 16,384.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; /proc/sys/net/netfilter/nf_conntrack_max\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003eIt represents the maximum number of allowed conntrack entries that netfilter can keep running simultaneously. It was set to hashize*8\\u0026thinsp;=\\u0026thinsp;16,384*8\\u0026thinsp;=\\u0026thinsp;131,072. This number will have a significant impact when we run our attack later, so that our NAT table doesn\\u0026rsquo;t get full easily.\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; /proc/sys/net/netfilter/nf_conntrack_udp_timeout\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003eThis timeout means that after 30 seconds, the already used UDP ports are ready to be re-assigned by the kernel, we left it out as the default value of 30 seconds.\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; /etc/security/limits.conf\\u003c/p\\u003e \\u003cp\\u003eThis file controls the number of maximum open files at the same time, where we added the below line:\\u003cdiv class=\\\"BlockQuote\\\"\\u003e\\u003cp\\u003e# root hard nofile 1000000\\u003c/p\\u003e\\u003c/div\\u003e\\u003c/p\\u003e \\u003cp\\u003eTo perform this kind of attack, another tool can be used, where a huge number of DNS queries can be sent to the target machine (AFTR), which is called \\u0026ldquo;dns64perf++\\u0026rdquo; [42] (described in [43]). When all parameters (on the attacking machine side) are set correctly (number of requests, delay between requests, etc.), the AFTR pool of source ports will be exhausted, and the machine will not be able to process incoming packets anymore till the UDP timeout (port allocation timeout in AFTR machine) is up. The below command was used on each of our attacking clients:\\u003c/p\\u003e \\u003cp\\u003e \\u003cb\\u003e/dns64perf\\u0026thinsp;+\\u0026thinsp;+\\u0026thinsp;v4 198.51.100.2 53 0.0.0.0/5 60000 1 1 60000 400000 0.1\\u003c/b\\u003e \\u003c/p\\u003e \\u003cp\\u003eWhat this command really does is sending 60,000 queries from each client. For two clients, this number reaches 120,000 queries, which is still under 131,072 (nf_conntrack_max). As a result, our NAT table will not be overfilled with packets that exceed its capacity. Another interesting fact in the command is the delay of 400,000 nanoseconds between queries, which means 2,500 queries/s, which means, for two clients, we are sending a total of 5,000 queries/s.\\u003c/p\\u003e \\u003cp\\u003eThe attack was executed by an automated script from client 1, which does the followings:\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; Accesses AFTR remotely (via ssh) and runs tshark (traffic monitoring software) and captures the traffic at ens35 interface.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; Runs the attack from IPv4-client \\u0026minus;\\u0026thinsp;1 (the same machine).\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; Accesses IPv4 client-2 remotely (via ssh) and runs the same attack with the same parameters.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; Waits till attacks are finished on both clients.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; Accesses AFTR remotely (via ssh) and stops tshark.\\u003c/p\\u003e \\u003cp\\u003e\\u0026bull; Sends the tshark results as pcap file to the host machine, so it can be read in the Wireshark software.\\u003c/p\\u003e \\u003cp\\u003eFigure\\u0026nbsp;10 shows the exhaustion of the source ports clearly. To prove that we must have only 64,512 sent queries, which comes from subtracting the well-known 1024 ports from the total of 65,536 ports. Figure\\u0026nbsp;10 shows that AFTR processed only 64,536 packets at ens35 interface. After digging deeper, we found out that there are more packets embedded within Wireshark results such as 20 ICMP and 4 ARP packets. As a result, the reaming packets are 64,536\\u0026ndash;20 \\u0026ndash; 4\\u0026thinsp;=\\u0026thinsp;64,512, which is exactly the number we were anticipating.\\u003c/p\\u003e \\u003cp\\u003eIn principle, we sent 60,000 queries from each client (120,000 in total), AFTR was able to process no more than 64,512 packets and it ran out of ports in around 14 seconds. This failure of service supposed to last until UDP session timeout at AFTR is over and new source ports are available to be re-allocated.\\u003c/p\\u003e \\u003cp\\u003eC. \\u003cem\\u003eMitigation method\\u003c/em\\u003e\\u003c/p\\u003e \\u003cp\\u003eSeveral IDS \\u0026amp; IPS (Intrusion Detection \\u0026amp; Prevention systems) were tested in order to identify and drop the spoofed packet from the legitimate one. The process proved to be quite hard to implement, especially when our attacker machine is located inside the access network of the ISP (VMnet-11). Therefore, a workaround had been put in place and \\u003cb\\u003eiptables\\u003c/b\\u003e rules were emplaced to do the job.\\u003c/p\\u003e \\u003cp\\u003e1) \\u003cem\\u003eFirst attack mitigation: -\\u003c/em\\u003e\\u003c/p\\u003e \\u003cp\\u003eAn \\u003cb\\u003eip6tables\\u003c/b\\u003e rule was configured at AFTR in order to allow the incoming traffic at ens34 interface of the AFTR only under the condition that the incoming packet\\u0026rsquo;s source MAC address belongs to B4 ens39 interface (see Fig.\\u0026nbsp;6).\\u003c/p\\u003e \\u003cp\\u003e \\u003cb\\u003eip6tables -A INPUT -i ens34 -s 2001:db8:0:1::2 -m mac ! --mac-source 00:0c:29:67:14:14 -j DROP\\u003c/b\\u003e \\u003c/p\\u003e \\u003cp\\u003e2) \\u003cem\\u003eSecond attack mitigation: -\\u003c/em\\u003e\\u003c/p\\u003e \\u003cp\\u003eDespite the fact that this attack didn\\u0026rsquo;t go through, and spoofed packet had been dropped, a proposed solution is presented here in case of building the topology using another machine (different Linux distribution for instance), where such attack could be prevented at B4 router side with the following rules:\\u003c/p\\u003e \\u003cp\\u003e \\u003cb\\u003eiptables -A FORWARD -i ens38 -s 10.0.0.0/24 -j ACCEPT\\u003c/b\\u003e \\u003c/p\\u003e \\u003cp\\u003e \\u003cb\\u003eiptables -A FORWARD -i ens38 -j DROP\\u003c/b\\u003e \\u003c/p\\u003e \\u003cp\\u003eThe first rule accepts packets with source address from our private IPv4 address network (10.0.0.0/24), while the second one drops every packet that approaches ens38 interface and needs to be forwarded. Those two rules take care of a malicious packet as it reaches the B4 side and before it heads towards the AFTR (see Fig.\\u0026nbsp;8).\\u003c/p\\u003e \\u003cp\\u003e3) \\u003cem\\u003eThird attack mitigation method: -\\u003c/em\\u003e\\u003c/p\\u003e \\u003cp\\u003eOne of the ways to mitigate this attack or at least reducing its impact, is by adding two (or more) IP addresses to AFTR ens35 interface (see Fig.\\u0026nbsp;9), where the whole calculation will be double (or triple, depends on how many IP addresses we add) due to the fact that extended NAT works by binding IP / port pair together. The fact that ens35 has two IP addresses now, gives the AFTR more flexibility by having one additional pool of exactly the same port numbers of 64,512 ports, but they will be coupled with another source IP address. In case that two IP addresses were not enough to mitigate the attack, system administrator can easily add third, fourth, and more IP addresses as needed. On the practical side, we added two extra IP addresses on ens35 interface on AFTR. As a result, the AFTR was able to process all incoming 120,000 packets, unlike last time when it stopped after 64,512 packets.\\u003c/p\\u003e \\u003cp\\u003eAnother mitigation method is possible through rate limiting process which limits the number of packets per second that can be sent and received by the NIC (Network Interface Card) [44], it also enables the administrator to assign bandwidth restriction on specific traffic such as ICMP, UDP, etc. Some research work [45] and [46] have proposed the rate limiting mitigation mechanism after noticing the difference and the asymmetry between incoming and outgoing traffic in the designated network.\\u003c/p\\u003e\"},{\"header\":\"9. Conclusion\",\"content\":\"\\u003cp\\u003eWe have shown in this paper the significance of transition technologies with the help of tunneling method and how practical it can be. Our testbed on the other hand has proven to be effective in terms of imitation a DS-Lite topology and examining its security vulnerabilities. As DS-Lite would normally function, our IPv4 client didn\\u0026rsquo;t need public IPv4 address at its disposal to communicate with an IPv4 sever despite having an IPv6 island in the middle. Moreover, STRIDE method has also shown that every element within the DS-Lite topology can be targeted in so many ways. Therefore, further analysis and vulnerabilities patching is always required when it comes to IPv6 transition technologies and in especially when tunneling process is involved. The \\u0026ldquo;thc-ipv6\\u0026rdquo; toolkit was a great help and it provided us with variety of tools and attacking possibilities that can be demonstrated even in future research works. One of the most imminent threats that DS-Lite is liable to are DoS, tampering, spoofing and finally port number exhaustion.\\u003c/p\\u003e\"},{\"header\":\"Declarations\",\"content\":\"\\u003cp\\u003e\\u003cstrong\\u003eAcknowledgement\\u003c/strong\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eIn part, the resources of NICT StarBED, Japan were used for our experiment. The authors thank Shuuhei Takimoto for the opportunity to use the resources.\\u003c/p\\u003e\\n\\u003cp\\u003eThe authors thank Dr. S\\u0026aacute;ndor R\\u0026eacute;p\\u0026aacute;s, Andr\\u0026aacute;s Gerend\\u0026aacute;s and Omar D\\u0026rsquo;yab for their reading and commenting the manuscript.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eFunding\\u003c/strong\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eThe authors declare that no funds, grants, or other support were received during the preparation of this manuscript.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eBCompeting Interests\\u003c/strong\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eThe authors have no relevant financial or non-financial interests to disclose.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eC. Author Contributions\\u003c/strong\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eAll authors contributed to the study conception and design. Material preparation and testbed building by [Ameen Al-Azzawi], with the valuable support from [Gabor Lencse]. The first draft of the manuscript was written by [Ameen Al-Azzawi] and all authors commented on previous versions of the manuscript. All authors read and approved the final manuscript.\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eD. CRediT Taxonomy\\u003c/strong\\u003e\\u003c/p\\u003e\\n\\u003cp\\u003eConceptualization: [Gabor Lencse]; Methodology: [Ameen Al-Azzawi]; Formal analysis and investigation: [Ameen Al-Azzawi]; Writing - original draft preparation: [Ameen AL-Azzawi]; Writing - review and editing: [Gabor Lencse], [Ameen Al-Azzawi]; Funding acquisition: [None]; Resources: [Ameen Al-Azzawi], [Gabor Lencse]; Supervision: [Gabor Lencse].\\u003c/p\\u003e\\n\\u003cp\\u003e\\u003cstrong\\u003eE. Data Availability\\u003c/strong\\u003e\\u003c/p\\u003e\\n\\u003ctable border=\\\"1\\\" cellpadding=\\\"0\\\" width=\\\"0\\\"\\u003e\\n \\u003ctbody\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd valign=\\\"top\\\" width=\\\"27.551020408163264%\\\"\\u003e\\n \\u003cp\\u003e\\u003cstrong\\u003eDescription\\u003c/strong\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" width=\\\"72.44897959183673%\\\"\\u003e\\n \\u003cp\\u003e\\u003cstrong\\u003eTemplate\\u003c/strong\\u003e\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd valign=\\\"top\\\" width=\\\"27.551020408163264%\\\"\\u003e\\n \\u003cp\\u003eThe automation script used to build the whole topology, especially attacker machine\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" width=\\\"72.44897959183673%\\\"\\u003e\\n \\u003cp\\u003eThis public GitHub repository of the first author contains several automation scripts to build every machine that were used to build the topology.\\u003c/p\\u003e\\n \\u003cp\\u003ehttps://github.com/ameen-mcmxc/DS-Lite_Test_Bed\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003ctr\\u003e\\n \\u003ctd valign=\\\"top\\\" width=\\\"27.551020408163264%\\\"\\u003e\\n \\u003cp\\u003eThe \\u0026ldquo;pcap\\u0026rdquo; file generated by Wireshark software to capture the traffic at ens35 interface of AFTR machine in case of attack scenario 3.\\u003c/p\\u003e\\n \\u003cp\\u003e\\u0026nbsp;\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003ctd valign=\\\"top\\\" width=\\\"72.44897959183673%\\\"\\u003e\\n \\u003cp\\u003eResults of the attack were published in the same public GitHub repository files directory: -\\u003c/p\\u003e\\n \\u003cp\\u003ehttps://github.com/ameen-mcmxc/DS-Lite_Test_Bed/blob/main/DNS_Perf_Results.pcap\\u003c/p\\u003e\\n \\u003c/td\\u003e\\n \\u003c/tr\\u003e\\n \\u003c/tbody\\u003e\\n\\u003c/table\\u003e\"},{\"header\":\"References\",\"content\":\"\\u003col\\u003e\\n\\u003cli\\u003eG. Lencse and Y. Kadobayashi. (2018). Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64. Computers \\u0026amp; Security, 77(1), 397-411. https://doi.org/10.1016/j.cose.2018.04.012. \\u003c/li\\u003e\\n\\u003cli\\u003eA. Al-Azzawi. (2020). Towards the Security Analysis of the Five Most Prominent IPv4aaS Technologies. Acta Technica Jaurinensis. 13(2), 85-98. https://doi.org/10.14513/actatechjaur.v13.n2.530\\u003c/li\\u003e\\n\\u003cli\\u003eM. Bagnulo, A Sullivan, P. Matthews and I. Beijnum. (2011). DNS64: DNS extensions for network address translation from IPv6 clients to IPv4 servers. IETF RFC 6147. https://www.rfc-editor.org/info/rfc6147\\u003c/li\\u003e\\n\\u003cli\\u003eM. Bagnulo, P. Matthews and I. Beijnum. (2011). Stateful NAT64: Network address and protocol translation from IPv6 clients to IPv4 servers. IETF RFC 6146. https://www.rfc-editor.org/info/rfc6146\\u003c/li\\u003e\\n\\u003cli\\u003eM. Mawatari, M. Kawashima, C. Byrne. (2013). 464XLAT: Combination of stateful and stateless translation. IETF RFC 6877. https://www.rfc-editor.org/info/rfc6877\\u003c/li\\u003e\\n\\u003cli\\u003eA. Al-Azzawi and G. Lencse. (2020). Towards the Identification of the Possible Security Issues of the 464XLAT IPv6 Transition Technology. In TSP 2020, 439-444. https://www.doi.org/10.1109/TSP49548.2020.9163487.\\u003c/li\\u003e\\n\\u003cli\\u003eA. Al-Azzawi and G. Lencse, (2021). Testbed for the Security Analysis of the 464XLAT IPv6 Transition Technology in a Virtual Environment. In TSP 2021, 5-9. https://www.doi.org/10.1109/TSP52935.2021.9522598.\\u003c/li\\u003e\\n\\u003cli\\u003eA. Al-Azzawi and G. Lencse. (2021). Identification of the Possible Security Issues of the 464XLAT IPv6 Transition Technology. Infocommunications Journal. 13(4), 10-18. https://doi.org/10.36244/ICJ.2021.4.2\\u003c/li\\u003e\\n\\u003cli\\u003eLencse, G. and Kadobayashi, Y. (2019). Comprehensive survey of IPv6 transition technologies: A subjective classification for security analysis. IEICE Transactions on Communications, 102 (10), 2021-2035. https://doi.org/10.1587/transcom.2018EBR0002.\\u003c/li\\u003e\\n\\u003cli\\u003eDurand, A., Droms, R., Woodyatt, J. and Lee, Y. (2011). Dual-stack lite broadband deployments following IPv4 exhaustion. IETF RFC 6333. https://www.rfc-editor.org/info/rfc6333\\u003c/li\\u003e\\n\\u003cli\\u003eG. Lencse, J. Palet Martinez, L. Howard, R. Patterson, I. Farrer. (2022). Pros and cons of IPv6 transition technologies for IPv4aaS, Internet Draft. [cited 2022-06-28] [Online]. Available: https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-comparison-04.\\u003c/li\\u003e\\n\\u003cli\\u003eScott, O. (2019). The PPTP VPN protocol: Is it safe? - Infosec Resources. Retrieved July 22, 2022, from https://resources.infosecinstitute.com/topic/the-pptp-vpn-protocol-is-it-safe\\u003c/li\\u003e\\n\\u003cli\\u003eHamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and Zorn, G. (1999). Point-to-point tunneling protocol (PPTP). IETF RFC 2637. https://www.rfc-editor.org/info/rfc2637\\u003c/li\\u003e\\n\\u003cli\\u003eSchneier, B. (1998, November). Cryptanalysis of Microsoft\\u0026apos;s point-to-point tunneling protocol (PPTP). In Proceedings of the 5th ACM Conference on Computer and Communications Security 132-141.\\u003c/li\\u003e\\n\\u003cli\\u003eZorn, Glen, and Steve Cobb. (1998). Microsoft ppp chap extensions. IETF RFC 2433. https://www.rfc-editor.org/info/rfc2433\\u003c/li\\u003e\\n\\u003cli\\u003eZorn, G. (2000). Microsoft PPP CHAP extensions, version 2. IETF RFC 2759.\\u003c/li\\u003e\\n\\u003cli\\u003eKrishnan, S., D. Thaler, and J. Hoagland. (2011). Security concerns with IP tunneling. IETF RFC 6169. https://www.rfc-editor.org/info/rfc6169\\u003c/li\\u003e\\n\\u003cli\\u003eCarpenter, Brian, and Cyndi Jung. (1999). Transmission of IPv6 over IPv4 domains without explicit tunnels. IETF RFC 2529.\\u003c/li\\u003e\\n\\u003cli\\u003eArkko, J., Kempf, J., Zill, B. and Nikander, P. (2005). Secure neighbor discovery (SEND). IETF RFC 3971. https://www.rfc-editor.org/info/rfc3971\\u003c/li\\u003e\\n\\u003cli\\u003eNordmark, E. and Inc, R.G. (2005). Basic Transition Mechanisms for IPv6 Hosts and Routers. IETF RFC 4213.\\u003c/li\\u003e\\n\\u003cli\\u003eConta, A. and Deering, S. (1998). Generic packet tunneling in IPv6 specification. IETF RFC 2473. https://www.rfc-editor.org/info/rfc2473\\u003c/li\\u003e\\n\\u003cli\\u003eSavola, P. and Patel, C. (2004). Security considerations for 6to4. IETF RFC 3964. https://www.rfc-editor.org/info/rfc3964\\u003c/li\\u003e\\n\\u003cli\\u003eAbdulla, S.A. (2017). Survey of security issues in IPv4 to IPv6 tunnel transition mechanisms. International Journal of Security and Networks. 12(2), 83-102.\\u003c/li\\u003e\\n\\u003cli\\u003eHogg, S. (2007). IPv6: Dual Stack Where You Can; Tunnel Where You Must. Retrieved June 15, 2022, from https://www.networkworld.com/article/2285078/ipv6-dual-stack-where-you-can-tunnel-where-you-must.html\\u003c/li\\u003e\\n\\u003cli\\u003eYang, D., Song, X. and Guo, Q. (2010). Security on IPv6. 2nd IEEE International Conference on Advanced Computer Control, Shenyang, China, 323\\u0026ndash;326.\\u003c/li\\u003e\\n\\u003cli\\u003eMi, W. (2014). The Applicability and Security Analysis of IPv6 Tunnel Transition Mechanisms. In International Conference on Algorithms and Architectures for Parallel Processing. 560-570. Springer, Cham.\\u003c/li\\u003e\\n\\u003cli\\u003eHei, Y., Katsuno, S. and Ano, S. (2006). An implementation and evaluation of IPv6 end-to-end secure communication system for closed members. In International Symposium on Applications and the Internet Workshops (SAINTW\\u0026apos;06).\\u003c/li\\u003e\\n\\u003cli\\u003eS. A. Amin and S. H. Choong. (2006). On IPv6 Traceback. Proceedings of the International Conference on Advanced Communication Technology (ICACT2006).\\u003c/li\\u003e\\n\\u003cli\\u003eXie, L., Bi, J., \\u0026amp; Wu, J. (2007). An authentication based source address spoofing prevention method deployed in IPv6 edge network. In International Conference on Computational Science 801-808. Springer, Berlin, Heidelberg. \\u003c/li\\u003e\\n\\u003cli\\u003eLee, W. J., Heo, S. Y., Byun, T. Y., Sohn, Y. H., \\u0026amp; Han, K. J. (2007, May). A secure packet filtering mechanism for tunneling over Internet. In International Conference on Embedded Software and Systems, 641-652. Springer, Berlin, Heidelberg.\\u003c/li\\u003e\\n\\u003cli\\u003eJ. E. et al. Writing netfilter modules, July 2012. http://inai.de/documents/Netfilter_Modules.pdf.\\u003c/li\\u003e\\n\\u003cli\\u003eA. Shostack. (2014). Threat Modeling: Designing for Security. Wiley \\u0026amp;Sons.\\u003c/li\\u003e\\n\\u003cli\\u003eKristiyanto, Y. and Ernastuti, E. (2020). Analysis of Deauthentication Attack on IEEE 802.11 Connectivity Based on IoT Technology Using External Penetration Test. CommIT (Communication and Information Technology) Journal, 14(1), 45-51.\\u003c/li\\u003e\\n\\u003cli\\u003eLee, Y., et al. (2013). Deployment considerations for dual-stack lite. IETF RFC 6908. https://www.rfc-editor.org/info/rfc6908\\u003c/li\\u003e\\n\\u003cli\\u003eFu, Y., et al. (2016). Dual-Stack Lite (DS-Lite) Management Information Base (MIB) for Address Family Transition Routers (AFTRs). IETF RFC 7870. https://www.rfc-editor.org/info/rfc7870\\u003c/li\\u003e\\n\\u003cli\\u003eHankins, D., and T. Mrugalski. (2011). Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite. IETF RFC 6334. https://www.rfc-editor.org/info/rfc6334\\u003c/li\\u003e\\n\\u003cli\\u003eBoucadair, M., C. Jacquenet, and S. Sivakumar. (2019). A YANG Data Model for Dual-Stack Lite (DS-Lite). IETF RFC 8513. https://www.rfc-editor.org/info/rfc8513\\u003c/li\\u003e\\n\\u003cli\\u003evan Hauser Heuse, M. (2020). thc-ipv6 (Version 3.8) [Computer software]. https://github.com/vanhauser-thc/thc-ipv6\\u003c/li\\u003e\\n\\u003cli\\u003eMaking a synthesis emulation in IOT ERA possible Starbed5 Project Website. StarBED5 Project website /StarBED Equipment/. (n.d.). Retrieved from https://starbed.nict.go.jp/en/equipment/ \\u003c/li\\u003e\\n\\u003cli\\u003eD. P.Reed. (1980). User Datagram Protocol. IETF RFC 768. https://www.rfc-editor.org/info/rfc768\\u003c/li\\u003e\\n\\u003cli\\u003eNetfilter conntrack performance tweaking v0.8, https://wiki.khnet.info/index.php/Conntrack_tuning \\u003c/li\\u003e\\n\\u003cli\\u003eBakai D\\u0026aacute;niel: DNS64perf++ program, https://github.com/bakaid/dns64perfpp.\\u003c/li\\u003e\\n\\u003cli\\u003eG. Lencse, D. Bakai. (2017). Design and implementation of a test program for benchmarking DNS64 servers. IEICE Transactions on Communications, E100-B(6), 948-954. https://doi.org/10.1587/transcom.2016EBN0007\\u003c/li\\u003e\\n\\u003cli\\u003eNoormohammadpour, M., \\u0026amp; Raghavendra, C. S. (2017). Datacenter traffic control: Understanding techniques and tradeoffs. IEEE Communications Surveys \\u0026amp; Tutorials, 20(2), 1492-1525.\\u003c/li\\u003e\\n\\u003cli\\u003eGil, T. M., \\u0026amp; Poletto, M. (2001). MULTOPS: A Data-Structure for Bandwidth Attack Detection. In 10th USENIX Security Symposium (USENIX Security 01).\\u003c/li\\u003e\\n\\u003cli\\u003eMahajan, R., Bellovin, S. M., Floyd, S., Ioannidis, J., Paxson, V., \\u0026amp; Shenker, S. (2002). Controlling high bandwidth aggregates in the network. ACM SIGCOMM Computer Communication Review, 32(3), 62-73.\\u003c/li\\u003e\\n\\u003c/ol\\u003e\"}],\"fulltextSource\":\"\",\"fullText\":\"\",\"funders\":[],\"hasAdminPriorityOnWorkflow\":false,\"hasManuscriptDocX\":true,\"hasOptedInToPreprint\":true,\"hasPassedJournalQc\":\"\",\"hasAnyPriority\":false,\"hideJournal\":true,\"highlight\":\"\",\"institution\":\"\",\"isAcceptedByJournal\":false,\"isAuthorSuppliedPdf\":false,\"isDeskRejected\":\"\",\"isHiddenFromSearch\":false,\"isInQc\":false,\"isInWorkflow\":false,\"isPdf\":false,\"isPdfUpToDate\":true,\"isWithdrawnOrRetracted\":false,\"journal\":{\"display\":true,\"email\":\"info@researchsquare.com\",\"identity\":\"researchsquare\",\"isNatureJournal\":false,\"hasQc\":true,\"allowDirectSubmit\":true,\"externalIdentity\":\"\",\"sideBox\":\"\",\"snPcode\":\"\",\"submissionUrl\":\"/submission\",\"title\":\"Research Square\",\"twitterHandle\":\"researchsquare\",\"acdcEnabled\":true,\"dfaEnabled\":false,\"editorialSystem\":\"\",\"reportingPortfolio\":\"\",\"inReviewEnabled\":false,\"inReviewRevisionsEnabled\":true},\"keywords\":\"DS-Lite, 464XLAT, DNS, IPv4aaS, IPv6, STRIDE, Translation, Encapsulation, Spoofing, thc-ipv6 toolkit, dns64perf++, port number exhaustion\",\"lastPublishedDoi\":\"10.21203/rs.3.rs-1972342/v1\",\"lastPublishedDoiUrl\":\"https://doi.org/10.21203/rs.3.rs-1972342/v1\",\"license\":{\"name\":\"CC BY 4.0\",\"url\":\"https://creativecommons.org/licenses/by/4.0/\"},\"manuscriptAbstract\":\"\\u003cp\\u003eThis paper focuses on one of the most prominent IPv6 transition technologies named DS-Lite (Dual Stack Lite). The aim is to analyze the security threats that this technology might be vulnerable to. The analysis is based on the STRIDE method that stands for Spoofing, Tampering, Repudiation, Information disclosure and Elevation of privilege. Using the DFD (Data Flow Diagram) of a DS-Lite system, we summarized the potential security vulnerabilities and potential attack points within this infrastructure. We have also built a testbed for DS-Lite topology using several virtual machines, which were created using CentOS Linux images. We used our testbed to perform MitM (Man in the Middle) attack and other type of attacks against the B4 (border gateway) and the AFTR (Address Family Transition Router) and then to monitor their performance and the number of packets being translated under attack by different number of clients using several attacking toolkits.\\u003c/p\\u003e\",\"manuscriptTitle\":\"The Possible Security Issues of the DS-Lite IPv6 Transition Technology\",\"msid\":\"\",\"msnumber\":\"\",\"nonDraftVersions\":[{\"code\":1,\"date\":\"2022-08-26 16:15:49\",\"doi\":\"10.21203/rs.3.rs-1972342/v1\",\"editorialEvents\":[{\"type\":\"communityComments\",\"content\":0}],\"status\":\"published\",\"journal\":{\"display\":true,\"email\":\"info@researchsquare.com\",\"identity\":\"researchsquare\",\"isNatureJournal\":false,\"hasQc\":true,\"allowDirectSubmit\":true,\"externalIdentity\":\"\",\"sideBox\":\"\",\"snPcode\":\"\",\"submissionUrl\":\"/submission\",\"title\":\"Research Square\",\"twitterHandle\":\"researchsquare\",\"acdcEnabled\":true,\"dfaEnabled\":false,\"editorialSystem\":\"\",\"reportingPortfolio\":\"\",\"inReviewEnabled\":false,\"inReviewRevisionsEnabled\":true}}],\"origin\":\"\",\"ownerIdentity\":\"2ce4ea4a-c964-40ff-8fc3-98655a1b8b66\",\"owner\":[],\"postedDate\":\"August 26th, 2022\",\"published\":true,\"recentEditorialEvents\":[],\"rejectedJournal\":[],\"revision\":\"\",\"amendment\":\"\",\"status\":\"posted\",\"subjectAreas\":[],\"tags\":[],\"updatedAt\":\"2023-01-16T15:38:42+00:00\",\"versionOfRecord\":[],\"versionCreatedAt\":\"2022-08-26 16:15:49\",\"video\":\"\",\"vorDoi\":\"\",\"vorDoiUrl\":\"\",\"workflowStages\":[]},\"version\":\"v1\",\"identity\":\"rs-1972342\",\"journalConfig\":\"researchsquare\"},\"__N_SSP\":true},\"page\":\"/article/[identity]/[[...version]]\",\"query\":{\"redirect\":\"/article/rs-1972342\",\"identity\":\"rs-1972342\",\"version\":[\"v1\"]},\"buildId\":\"WrCJVZZCHTDjtuVLN7oU0\",\"isFallback\":false,\"isExperimentalCompile\":false,\"dynamicIds\":[84888],\"gssp\":true,\"scriptLoader\":[]}","source_license":"CC-BY-4.0","license_restricted":false}