Ipv4 Address Sharing Mechanism Classification And

Total Page:16

File Type:pdf, Size:1020Kb

Ipv4 Address Sharing Mechanism Classification And This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. IEEE/ACM TRANSACTIONS ON NETWORKING 1 IPv4 Address Sharing Mechanism Classification and Tradeoff Analysis Nejc Škoberne, Olaf Maennel, Iain Phillips, Randy Bush, Jan Zorz, and Mojca Ciglaric Abstract—The growth of the Internet has made IPv4 addresses andonlyone/22prefix (1024 IPv4 addresses). Such allocations a scarce resource. Due to slow IPv6 deployment, IANA-level IPv4 are too small to satisfy current growth rates. address exhaustion was reached before the world could transition The only long-term solution to the IPv4 address exhaustion to an IPv6-only Internet. The continuing need for IPv4 reacha- bility will only be supported by IPv4 address sharing. This paper problem is transition to the IPv6 protocol, which enables ad- reviews ISP-level address sharing mechanisms, which allow In- dressing large numbers of Internet devices [2]. However, today ternet service providers to connect multiple customers who share we observe little IPv6 deployment. IPv6 penetration at content a single IPv4 address. Some mechanisms come with severe and un- providers (top 500 Web sites) is about 24% globally [3] as of predicted consequences, and all of them come with tradeoffs. We March 15, 2013, while is somethingmorethan1%attheuser propose a novel classification, which we apply to existing mech- anisms such as NAT444 and DS-Lite and proposals such as 4rd, side [4] as of the same date. As IPv4 and IPv6 are incompatible, MAP, etc. Our tradeoff analysis reveals insights into many prob- IPv6 designers envisioned a dual-stack deployment [5], with the lems including: abuse attribution, performance degradation, ad- aim that by the time the IPv4 address space became depleted, dress and port usage efficiency, direct intercustomer communica- IPv6 would be universally deployed. Unfortunately, this did not tion, and availability. happen, though some Internet service provider (ISP) backbones Index Terms—Address family translation, address plus port have moved to dual-stack in the last few years. Thus, the IPv4 (A+P), carrier grade NAT (CGN), IPv4 address sharing, IPv6 protocol remains the predominant protocol and will do for some transition, network address translation (NAT). time during which the coexistence of both Internets needs to be maintained [6]. Eventually, IPv6 will become ubiquitous, and IPv4 no longer of interest. I. INTRODUCTION Some ISPs do not have enough IPv4 addresses to provide a dedicated IPv4 address to each customer. To support continued growth, individual IPv4 addresses will have to be shared be- N FEBRUARY 3, 2011, the Internet Assigned Num- tween multiple customers, which we refer to as “ISP-level ad- O bers Authority (IANA) announced that the pool of dress sharing.” However, the consequences of deployment of public IPv4 Internet addresses had become depleted. Conse- these mechanisms for the Internet users is not well understood. quently, Regional Internet Registries (RIRs) were left with Unfortunately, ISPs often do not have enough information only the addresses they had been assigned prior to this date. On about the potential consequences of their decisions. April 15, 2011, the Asia-Pacific Network Information Center • Would the deployment of a double network address trans- (APNIC) activated its “last /8 address policy” [1]. Similarly, lation (NAT) mechanism prevent Xbox LIVE customers on September 14, 2012, the Réseaux IP Européens Network who share the same IP address from playing games online Coordination Centre (RIPE NCC) activated its last /8 policy. and ultimately lead to loss of many customers and poten- This means that any organization applying to these RIRs for tially to a bad reputation for that ISP? IPv4 address space will receive a maximum allocation of one • Will cyber-criminals be untraceable because content providers (today) only log time and IP address of the attacker, but not source ports? Manuscript received May 25, 2012; revised October 30, 2012; accepted Feb- ruary 18, 2013; approved by IEEE/ACM TRANSACTIONS ON NETWORKING Ed- •Doesthedeployment of a particular mechanism create itorM.Allman.ThisworkwassupportedinpartbytheEuropeanUnion,the provider lock-in, so that the customers have to use, say, the European Social Fund, and the Cisco University Research Program Fund, a Internet TV service of their ISP as competitors’ services corporate-advised fund of Silicon Valley Community Foundation, under Grant 2011–89493(3696). fail to work? N. Škoberne is with Viris, Ljubljana 1000, Slovenia (e-mail: [email protected]). •Willthe End-to-End Principle, which is one of the core O. Maennel, I. Phillips are with the Department of Computer Science, Lough- principles of the Internet [7], become even more endan- borough University, Loughborough LE11 3TU, U.K. (e-mail: olaf@maennel. net; [email protected]). gered with ISP-level address sharing? R. Bush is with the Internet Initiative Japan, Kapa’au, HI 96755 USA (e-mail: •Willall new protocols have to tunnel over HTTP as this [email protected]). may be the only remaining application-layer protocol that J. Zorz is with the Go6 Institute, Skofja Loka 4220, Slovenia (e-mail: [email protected]). traverses address sharing devices? M. Ciglaric is with the University of Ljubljana, Ljubljana 1000, Slovenia This paper presents a systematic approach to classifying and an- (e-mail: [email protected]). alyzingexistingIPv4addresssharingmechanisms.Tocompare Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. and to understand them, we abstract some of their details and ex- Digital Object Identifier 10.1109/TNET.2013.2256147 plore the whole solution space. First, we define the classification 1063-6692/$31.00 © 2013 IEEE This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. 2 IEEE/ACM TRANSACTIONS ON NETWORKING as it is infeasible to change deployed hosts, e.g., it was years after the IPv6 RFC was published until Windows XP had pro- duction-ready IPv6 support. Second, every customer is assumed to have a CPE, even though some mechanisms allow for con- necting end-host directly to the access network. CPE, however, may be modified or replaced for the purpose of deploying some mechanism. This paper has four main contributions. First, it provides a classification of IPv4 address sharing mechanisms by proposing and explaining five dimensions. Each has multiple properties Fig. 1. ISP topology. For the sake of simplicity, two customer networks are (Section III-B). shown, though realistically there could be thousands or millions of them. Next, we classify the mechanisms into nine classes and re- view them. We aim to find general similarities that facilitate un- derstanding and discussion of such technologies (Section III-C). dimensions and properties. Then, we infer nine classes catego- Third, we discuss the properties of the mechanisms based rizing existing mechanisms. Similar mechanisms are classified on the proposed classification. We also identify and describe into the same class. the most important practical technical issues related to specific Our main research objective is to propose a classification for properties of each approach (Section IV). IPv4 address sharing mechanisms. We feel the need for such Finally, we present an analysis qualitatively describing the classification is significant: revealing gaps and conflicts, while tradeoffs between the classification dimensions. The analysis new Internet Drafts of address sharing proposals keep coming, aims at guiding ISPs through their decisions and at providing many of them expiring after a year or two. Other networking re- a grounding for future research in this area (Section V). search papers focus on these drafts arbitrarily, while they could focus on whole classes instead and thus gain more universal II. BACKGROUND AND RELATED WORK value. Additional classes might be defined in the future. Further- more, our results will inform the design of new address sharing CPEs can share a public IPv4 address in two ways: mechanisms. 1) Carrier-Grade NAT (CGN): using a translator with a Net- We consider networks where address sharing must be used, work Address and Port Translation (NAPT) function lo- including broadband ISPs providing internet access to large cated in the core of the ISP’s network, which multiplexes numbers of customers. However, this excludes mobile ISPs multiple CPEs on a single IPv4 address; even though their number of subscribers have long surpassed 2) Address-Plus-Port (A+P): by communicating in a port-re- the number of wired subscriptions. We believe ISP-level stricted manner, where bits from the port field are used to address sharing will have stronger impact on wired users extend the IPv4 address field, i.e., choosing a source port than on mobile ones, as nonmobile end-hosts usually have for outgoing packets from a subset of the whole 16-bit port higher requirements, e.g., peer-to-peer networking, than mobile range and receiving incoming packets destined to a port end-hosts. Moreover, it is common practice for mobile users from the same subset. For this to work, the CPEs have to use WiFi networks when available, so their device becomes to port-restrict outgoing packets and the gateways have to another end-host in our topology. We only consider unicast; route incoming packets using the destination port. multicast is out of scope. We use the terms port and flow in the We only consider A+P CPE and not A+P end-hosts. A+P CPE context of transport-layer protocols like TCP and UDP. therefore must perform a (port restricted) NAPT function to sup- First, we review terms we use for the topology of an ISP; see port multiple end-hosts. Fig. 1: In the time of dial-up Internet access, IP addresses were • ISP network: the network of the Internet service provider, shared over time using Dynamic Host Configuration Pro- which also contains the access network; tocol (DHCP) or other provisioning protocols.
Recommended publications
  • Ipv6 Multicast Layer 3 Features
    Chapter 13 IPv6 Multicast Support Prerequisites for IPv6 Multicast 13 IPv6 Multicast Support • Prerequisites for IPv6 Multicast, page 13-1 • Restrictions for IPv6 Multicast, page 13-1 • Information About IPv6 Multicast Support, page 13-2 • How to Configure IPv6 Multicast Support, page 13-4 • Verifying the IPv6 Multicast Layer 3 Configuration, page 13-4 Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page: http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html Participate in the Technical Documentation Ideas forum Prerequisites for IPv6 Multicast None. Restrictions for IPv6 Multicast • The PFC and DFCs provide hardware support for the following: – Completely switched IPv6 multicast flows – IPv6 PIM-Sparse Mode (PIM-SM) (S,G) and (*,G) forwarding – Multicast RPF check for IPv6 PIM-SM (S,G) traffic using the NetFlow table – Rate limiting of IPv6 PIM-SM (S,G) traffic that fails the multicast RPF check – Static IPv6 multicast routes – SSM Mapping for IPv6 (PIM-SSM) – IPv6 multicast forwarding information base (MFIB) using the NetFlow table – IPv6 distributed MFIB (dMFIB) using the NetFlow table – Link-local and link-global IPv6 multicast scopes – Egress multicast replication with the ipv6 mfib hardware-switching command – Ingress interface statistics for multicast routes (egress interface statistics not available) – RPR and RPR+ redundancy mode (see Chapter 9, “Route Processor Redundancy
    [Show full text]
  • Ipv6-Only Deployment in Broadband and Cellular Networks Ipv4aas (As-A-Service)
    IPv6-only Deployment in Broadband and Cellular Networks IPv4aaS (as-a-Service) LACNIC 32 / LACNOG 2019 October, 2019 Panamá @JordiPalet ([email protected]) - 1 Transition / Co-Existence Techniques • IPv6 has been designed for easing the transition and coexistence with IPv4 • Several strategies have been designed and implemented for coexisting with IPv4 hosts, grouped in three categories: – Dual stack: Simultaneous support for both IPv4 and IPv6 stacks – Tunnels: IPv6 packets encapsulated in IPv4 ones • This has been the commonest choice • Today expect IPv4 packets in IPv6 ones! – Translation: Communication of IPv4-only and IPv6- only. Initially discouraged and only “last resort” (imperfect). Today no other choice! • Expect to use them in combination! - 2 Dual-Stack Approach • When adding IPv6 to a system, do not delete IPv4 – This multi-protocol approach is familiar and well-understood (e.g., for AppleTalk, IPX, etc.) – In the majority of the cases, IPv6 is be bundled with all the OS release, not an extra-cost add-on • Applications (or libraries) choose IP version to use – when initiating, based on DNS response: • if (dest has AAAA record) use IPv6, else use IPv4 – when responding, based on version of initiating packet • This allows indefinite co-existence of IPv4 and IPv6, and gradual app-by-app upgrades to IPv6 usage • A6 record is experimental - 3 Dual-Stack Approach IPv6 IPv6 IPv4 IPv4 Application Application Application Application TCP/UDP TCP/UDP TCP/UDP IPv6 IPv6 IPv4 IPv4 IPv6-only stack Dual-stack (IPv4 & IPv6) IPv4-only
    [Show full text]
  • Ipv6 Multicast Layer 3 Features
    CHAPTER 52 IPv6 Multicast Support • Prerequisites for IPv6 Multicast, page 52-1 • Restrictions for IPv6 Multicast, page 52-1 • Information About IPv6 Multicast Support, page 52-2 • How to Configure IPv6 Multicast Support, page 52-4 • Verifying the IPv6 Multicast Layer 3 Configuration, page 52-4 Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page: http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html Participate in the Technical Documentation Ideas forum Prerequisites for IPv6 Multicast None. Restrictions for IPv6 Multicast • The PFC and DFCs provide hardware support for the following: – Completely switched IPv6 multicast flows – IPv6 PIM-Sparse Mode (PIM-SM) (S,G) and (*,G) forwarding – Multicast RPF check for IPv6 PIM-SM (S,G) traffic using the NetFlow table – Rate limiting of IPv6 PIM-SM (S,G) traffic that fails the multicast RPF check – Static IPv6 multicast routes – SSM Mapping for IPv6 (PIM-SSM) – IPv6 multicast forwarding information base (MFIB) using the NetFlow table – IPv6 distributed MFIB (dMFIB) using the NetFlow table – Link-local and link-global IPv6 multicast scopes Supervisor Engine 2T Software Configuration Guide, Release 15.4SY 52-1 Chapter 52 IPv6 Multicast Support Information About IPv6 Multicast Support – Egress multicast replication with the ipv6 mfib hardware-switching command – Ingress interface statistics for multicast routes (egress interface statistics
    [Show full text]
  • State of the Ipv6 Adoption (And When Can We Turn Off Ipv4?)
    State of the IPv6 adoption (and when can we turn off IPv4?) Ole Trøan @ NORDUnet 2012 NOSTG 2012-09-19 © 20122010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 1 IPv6 DNS <AAAA, A> IPv4 CGN Considerations : Transparency to application, Innovation, Scale, Security, Cost • IANA, APNIC, and RIPE has run out • After inventing Automatic Tunnels, 6over4, 6to4, ISATAP, Teredo, SIIT, NAT-PT we found ‘one’ transition mechanism that stuck – 6rd, (and “reinvented” NAT-PT). • Then “moved on”: CGNs, DS-lite, A+P, Public 4over6, Lightweight 4over6, dIVI, dIVI-PD, 4rd-{u,h}, MAP-{E,T}, 464XLAT Is this preparing for turning off IPv4? Or is it head in the sand, IPv4 life extensions? • Implementations: Maturing but still feature gaps • Deployment: Millions © 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 3 © 2012 Cisco and/or its affiliates. All rights reserved. 5 Do I pay less ? NAT’s are good. Where is the Any new RFC1918 gives me network? Where is the content? applications? security, and IPv4 Too much pain & address runout is no gain my ISP’s problem. Device User Enterprise ISP The network is not ready, Content users don’t care and I don’t want to risk a poor end- user experience today for potential gains tomorrow “A deadlock, stalemate, impasse; a roughly equal (frequently unsatisfactory) outcome to a conflict in which there is no clear © 2010 Cisco and/or its affiliates. All rights reserved. winner or loser,” Cisco Confidential 6 © 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 7 © 2010 Cisco and/or its affiliates.
    [Show full text]
  • D3.2 Analysis of Ipv4-Ipv6
    Ref. Ares(2021)1534648 - 28/02/2021 Alternative Bearers for Rail (AB4Rail) Ref. Ares 2020)3856873 - 22/07/2020 Alternative Bearers for Rail (AB4Rail) D3.2 Analysis of IPv4-IPv6 Document Manager Alessandro Vizzarri (RDL) Programme S2R-OC-IP2-02-2020 Project Name Alternative Bearers for Rail Project acronym: AB4RAIL Grant agreement no: 101014517 Project Coordinator RADIOLABS (RDL) WP leader RDL Deliverable ID: AB4Rail-WP3-D3.2-RDL-PU-v0.0-Analysis of IPv4-IPv6 Title: Analysis of IPv4-IPv6 Work Package: WP3 WP Duration (in months): 18 Actual submission date: 28 Feb. 2021 Dissemination level: PU Approval Status Romeo Giuliano (USGM), Prepared by: Alessandro Vizzarri (RDL), Franco Mazzenga (RDL) Approved by (WP Leader): Alessandro Vizzarri (RDL) Approved by Technical and Project Manager: Alessandro Vizzarri (RDL) Approved by (Project Coordinator): Franco Mazzenga (RDL) Alternative Bearers for Rail (AB4Rail) Ref. Ares 2020)3856873 - 22/07/2020 CONTRIBUTING PARTNERS Name Company/Organization Role/Title Romeo Giuliano Università degli Studi Document Manager/main drafter Guglielmo Marconi (USGM) Franco Mazzenga Radiolabs (RDL) Contributor Alessandro Vizzarri Radiolabs (RDL) Contributor REVISION TABLE Revision Date Modified pages Modified Sections Comments 0.0 28 Feb. 2021 DISTRIBUTION LIST Name Company/Organization Role/Title Franco Mazzenga RDL Project Coordinator Gorazd Marinic Shif2Rail Shif2Rail Programme Officer Disclaimers This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 101014517. The information and views set out in this document are those of the author(s) and do not necessarily reflect the official opinion of Shift2Rail Joint Undertaking. The JU does not guarantee the accuracy of the data included in this article.
    [Show full text]
  • ETSI White Paper on Ipv6 Best Practices, Benefits, Transition
    ETSI White Paper No. 35 IPv6 Best Practices, Benefits, Transition Challenges and the Way Forward First edition – August 2020 ISBN No. 979-10-92620-31-1 ETSI 06921 Sophia Antipolis CEDEX, France Tel +33 4 92 94 42 00 [email protected] www.etsi.org Contributing organizations and authors CAICT Zhiruo Liu China Telecom Chongfeng Xie, Cong Li Cisco Patrick Wetterwald, Pascal Thubert, Francois Clad Hewlett-Packard Enterprise Yanick Pouffary Huawei Giuseppe Fioccola, Xipeng Xiao, Georgios Karagiannis, Shucheng(Will) Liu KPN Eduard Metz Luxembourg University Latif Ladid PT Telecom Jose Cananao, Jose Palma Post Luxembourg Sébastien Lourdez Telefonica Luis M. Contreras IPv6 Best Practices, Benefits, Transition Challenges and the Way Forward 2 Contents Contributing organizations and authors 2 Contents 3 Executive Summary 6 1 Background 8 1.1 Why should IPv6 become a priority again? 8 1.2 Goals of this White Paper 9 2 IPv6 progress in the last 5 years 10 2.1 Devices supporting IPv6 10 2.2 Content (web sites, cloud services) supporting IPv6 11 2.3 Networks supporting IPv6 12 2.4 Number of IPv6 users 12 2.5 Amount of IPv6 traffic 13 2.6 IPv6 standardization progress 14 3 IPv6 service design for Mobile, Fixed broadband and enterprises 14 3.1 IPv6 transition solutions from operator perspective 15 3.1.1 For IPv6 introduction 16 3.1.2 For IPv6-only service delivery 17 3.2 IPv6 prefix and address assignment at the CPEs 22 3.2.1 For MBB UEs 23 3.2.2 For FBB RGs 23 3.2.3 For Enterprise CPEs 23 3.3 IPv6 Packet Transport 24 3.4 IPv6 deployment inside enterprise
    [Show full text]
  • The Evolution of Ipv6 Transition Technologies Apipv6tf, APNIC 35
    The evolution of IPv6 transition technologies APIPv6TF, APNIC 35 Innovative solutions for tomorrow’s challenges Jouni Korhonen Renesas Mobile Corporation The evolution of IPv6 transition technologies 27 February 2013 1 ©2012 Renesas Mobile Corporation. All rights reserved. Overview § IETF has worked on a plethora of IPv6 transition mechanisms. § The activity is still ongoing trying to address different types on deployment scenarios. § There is still need to provide IPv4 access and extend IPv4 lifetime when ISPs deploy IPv6 in their backbone. § This presentation goes through recent IPv6 transition activities in IETF. We do not repeat the existing technologies.. 2 ©2012 Renesas Mobile Corporation. All rights reserved. Evolution of IPv6 transition technologies in IETF This “roadmap” lacks tools from Ongoing.. the mobility and security camps: MAP-DHCP MAP DSMIPv6, PMIPv6, (MOB)IKE etc.. MAP-DEPLOYMENT ~Done and running code ~Done and running code IVI dIVI dIVI-pd MAP-T NAT64 XLAT464 MAP-E SAM 4rd NAT-PT Public 4over6 4rd-(H,U) NAT464 DS-lite Lightweight 4over6 Remember PNAT & BIH? Stateless DS-lite Done and deployable.. A+P Ongoing.. 6to4 (RFC3056) 6rd (RFC5969) Configured tunnels RFC1933 Automatic tunnels 6over4 ISATAP Tunnel brokers Done and deployed.. Teredo BGP tunnels Softwire mesh 6PE 6VPE Original picture modified with the permission of Ole Troan 3 ©2012 Renesas Mobile Corporation. All rights reserved. Common trends for recent work @ IETF § Offer IPv4 end user service over IPv6(-only) ISP backbone. § Assume dual-stack service for customers. § IPv4 lifetime extension either using A+P or making end user IPv4 number “insignificant”. § Push (NAT44) state at the customer edge.
    [Show full text]
  • Analysis and Comparison of Tunneling Based Ipv6 Transition Mechanisms
    International Journal of Applied Engineering Research ISSN 0973-4562 Volume 12, Number 6 (2017) pp. 894-897 © Research India Publications. http://www.ripublication.com Analysis and Comparison of Tunneling based IPv6 Transition Mechanisms Pyung Soo Kim System Software Solution Lab., Department of Electronic Engineering, Korea Polytechnic University, 237 Sangidaehak-ro, Siheung-si, Gyeonggi-do, 429-793, Korea. ORCID: 000-0002-9589-446X Abstract STANDARDS DEVELOPMENT ORGANIZATION FOR TUNNELING BASED IPV6 TRANSITION In this paper, a number of tunneling based IPv6 transition MECHANISMS mechanisms are surveyed, analyzed and compared. Firstly, the standards development organization to standardize tunneling The IETF (Internet Engineering Task Force) is the body that based IPv6 transition mechanisms is introduced. Secondly, defines standard Internet operating protocols such as TCP/IP. various tunneling based mechanisms are analyzed. Thirdly, The Internet Engineering Task Force (IETF) is a global these mechanisms are compared from a variety of views. community of volunteers that develops standards used billions of times by companies, organizations, and individuals every Keywords: IPv4, IPv6, Transition, Tunneling. day around the world, including those that provide a foundation for email, domain names, and the Web. Standards are expressed in the form of Requests for Comments (RFCs). INTRODUCTION The Softwires Working Group, called the softwire WG in Although IPv4 has been the most dominant internet protocol, IETF is just set up to define a standard way to specify the the recent exponential growth of Internet-enabled devices, standardization of discovery, control and encapsulation such as smart phones, tablets, laptops, industrial technologies, methods for connecting IPv4 networks across IPv6 networks appliances, and their increasing requirement of IP addresses and IPv6 networks across IPv4 networks in a way that will cannot be fulfilled because of the limited number of IP encourage multiple, inter-operable implementations.
    [Show full text]
  • Impact of Ipv4-Ipv6 Coexistence in Cloud Virtualization Environment
    Impact of IPv4-IPv6 Coexistence in Cloud Virtualization Environment Mohammad Aazam1, Eui-Nam Huh2 Innovative Cloud and Security Lab, Department of Computer Engineering Kyung Hee University, Suwon, South Korea. [email protected] [email protected] Abstract— Since January 2011, IPv4 address space has exhausted routed from that IPv4 network. Network layer virtualization and IPv6 is taking up the place as successor. Coexistence of IPv4 provides a very useful mean to achieve the coexistence of both and IPv6 bears problem of incompatibility, as IPv6 and IPv4 these versions of IP, described more in section II. As IPv4 and headers are different from each other, thus, cannot interoperate IPv6 headers are different from each other in terms of the with each other directly. The IPv6 transitioning techniques are header format (fields, the address format and address size are still not mature, causing hindrance in the deployment of IPv6 and development of next generation Internet. Until IPv6 completely different), so some mechanism is always required that makes it takes over from IPv4, they will both coexist. For IPv4-IPv6 possible to route the packet between different islands, i.e. the coexistence, three solutions are possible: a) making every device IPv4 island and the IPv6 island. For this purpose, three dual stack, b) translation, c) tunneling. Tunneling stands out as mechanisms: dual stack, translation, and tunneling, are the best possible solution. Among the IPv6 tunneling techniques, available in the literature [11]. this paper evaluates the impact of three recent IPv6 tunneling techniques: 6to4, Teredo, and ISATAP, in cloud virtualization Dual stack means nodes (routers and other IP devices) can environment.
    [Show full text]
  • A Comprehensive Threat Model for Ipv6 Transition Technologies
    The STRIDE Towards IPv6: A Comprehensive Threat Model for IPv6 Transition Technologies M. Georgescu, H. Hazeyama, T. Okuda, Y. Kadobayashi and S. Yamaguchi Nara Institute of Science and Technology, 891-6 Takayama, Ikoma, Nara, Japan Keywords: IPv6 Transition Technologies, Threat Model, STRIDE, Dual-stack, Single Translation, Double Translation, Encapsulation. Abstract: The IPv6 worldwide deployment rate is still a single figure. This is due to the many challenges introduced by the transition period through which both IPv4 and IPv6 will need to coexist. One of the biggest concerns related to the IPv6 transition is security, which is more difficult to ensure in a heterogeneous environment. To clarify the security threats introduced by IPv6 transition technologies, this article proposes a comprehensive threat model built around the established STRIDE approach. To verify the usefulness of the proposed model, a threat analysis of four generic categories of IPv6 transition technologies is performed. Existing and new threats are documented, classified and prioritized. To further validate some of the documented threats, preliminary penetration test data is presented. 1 INTRODUCTION headers, stateless autoconfiguration), or not-feasible (e.g. widespread deployment of IPv6 with IPsec). The IPv4 address space exhaustion is imminent and The IPv6 transition has further aggravated these chal- can affect the further expansion of the Internet. The lenges as transition technologies are generally ex- Internet Assigned Numbers Authority (IANA) has al- posed to the threats associated with both IP versions located on February 3rd 2011 the last blocks of IPv4 and hybrid blends, depending on the subcomponents. addresses (NRO, 2014). Four out of the five Regional When building an IPv6 transition plan, security Internet Registries (RIR) have entered the last stage is arguably the biggest concern for network opera- of IPv4 exhaustion.
    [Show full text]
  • Transition from Ipv4 to Ipv6: a State-Of-The-Art Survey Peng Wu, Yong Cui, Jianping Wu, Jiangchuan Liu, Chris Metz
    This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. IEEE COMMUNICATIONS SURVEYS & TUTORIALS, ACCEPTED FOR PUBLICATION 1 Transition from IPv4 to IPv6: A State-of-the-Art Survey Peng Wu, Yong Cui, Jianping Wu, Jiangchuan Liu, Chris Metz Abstract—In the process of Internet evolution, the transition of Internet-enabled mobile devices increases rapidly. This from IPv4 to IPv6 has become inevitable and fairly urgent. IANA leads to continuous demands for new IP address allocation, (Internet Assigned Numbers Authority) has finally exhausted which seems impossible to satisfy with IPv4. ChinaTelecom, the global IPv4 address space, which leaves the community no choice but pushes forward the IPv6 transition process. IPv4 one of the largest telecom ISPs (Internet Service Providers) and IPv6 networks both will exist during the transition period, in the world claims that by the end of 2012, they will use while the two are not compatible in nature. Therefore it is up all the IPv4 addresses they have acquired or can acquire. indispensable to maintain the availability, as well as to provide Besides, the prefix de-aggregation caused by address block the inter-communication ability of IPv4 and IPv6. Years ago a subdivision, multihoming and traffic engineering has caused series of transition techniques were actually proposed. However, because of their technical immatureness, they failed to cover a burst in Global IPv4 RIB (Routing Information Base) and the solution space well. Some of these techniques were even FIB (Forwarding Information Base). The Internet is suffering obsoletedbyIETFduetotheirflaws.
    [Show full text]
  • A Functional and Performance-Oriented Comparison of Transition Mechanisms for Internet Transition from Ipv4 to Ipv6 Protocol
    A Functional and Performance-Oriented Comparison of Transition Mechanisms for Internet Transition from IPv4 to IPv6 Protocol A Nejc Škoberne T F C I S D P C I S Ljubljana, 2013 . A Functional and Performance-Oriented Comparison of Transition Mechanisms for Internet Transition from IPv4 to IPv6 Protocol A Nejc Škoberne T F C I S D P C I S Ljubljana, 2013 . APPROVAL I hereby declare that this submission is my own work and that to the best of my knowledge, it contains no material previously published or written by another person nor material which to a substantial extent has been accepted for the award of any other degree or diploma of the university or other institute of higher learning, except where due acknowledgement has been made. — Nejc Škoberne — December 2013 T dr. Mojca Ciglarič Assistant Professor of Computer and Information Science dr. Andrej Kos Associate Professor of Electrical Engineering dr. Zoran Bosnić Assistant Professor of Computer and Information Science Dr Olaf Maennel Lecturer of Computer Science Loughborough University . PREVIOUS PUBLICATIONS I hereby declare that the research reported herein was previously published/submitted for publication in peer reviewed journals or publicly presented at the following occa- sions: [1] N. Škoberne, O. Maennel, I. Phillips, R. Bush, J. Žorž and M. Ciglarič. IPv4 Address Sharing Mechanism Classification and Tradeoff Analysis. IEEE/ACM Transactions on Networking, volume PP, number 99, 2013. doi: 10.1109/TNET.2013.2256147 [2] N. Škoberne and M. Ciglarič. Practical Evaluation of Stateful NAT64/DNS64 Translation. Advances in Electrical and Computer Engineering, volume 11, number 3, pages 49-54, 2011.
    [Show full text]