DOCSLIB.ORG

Ipv4 Exhaustion: NAT and Transition to Ipv6 for Service Providers

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Ipv4 Exhaustion: NAT and Transition to Ipv6 for Service Providers IPv4 Exhaustion: NAT and Transition to IPv6 for Service Providers Rajiv Asati, Distinguished Engineer, Cisco BRKSPG-2602 Cisco Spark Questions? Use Cisco Spark to chat with the speaker after the session How 1. Find this session in the Cisco Live Mobile App 2. Click “Join the Discussion” 3. Install Spark or go directly to the space 4. Enter messages/questions in the space Cisco Spark spaces will be cs.co/ciscolivebot#BRKSPG-2602 available until July 3, 2017. © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public Hmmm…….. CGNAT issue or something else ? IPv4 – Classic But spare parts have run out BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 5 IPv6 – Next Gen Getting to full parity and end-end use takes time Caution: New road may be needed BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 6 Transition Technologies Driving your classic IPv4 (or next gen IPv6) around BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 7 Abstract • Any service provider that has exhausted its IPv4 address pool, will not only have to deploy/offer IPv6, but also employ IPv4 sharing. This is because chunk of content may be reachable only via IPv4 internet, even though majority is available via IPv6 internet. • This session discusses few mechanisms such as MAP-T/E, 464XLAT, DS-Lite and CGN 64/44 etc. that facilitate IPv4 sharing with and without IPv6. It contrasts stateful and stateless translation techniques as well. • 6rd is included for reference as well. • This session is intended for Service Providers. BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 8 Agenda • Goal of Transition Technologies • Overview of Transition Technologies • Dual Stack – Impact ( & Happy Eyeballs) • IPv4 Address Sharing - Impact • CGN 44, DS-Lite, 6rd, MAP • CGN 64 for IPv6-only • Conclusion Recommended Approach for IPv6 Dual-Stack Deployment (per IETF RFC 4213) IPv4+IPv6 Hosts (Dual Stack) • Dual-Stack all the way to the hosts * • Hosts: Windows, OSX, iOS, Android, Linux etc. • Routers: IOS etc. IPv4+IPv6 Network • But note… • IPv4 exhaustion is underway • Every host can NOT be assigned an IPv4 address • Two protocol stacks to be managed in network IPv4 and/or IPv6 Destinations * RFC7755 suggests Single-stack IPv6 for DC BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 11 Recommended Approach for IPv6 Dual-Stack Deployment (per IETF RFC 4213), since 2005 • Dual-Stack to the “hosts” (= consumption devices) • ~90% of Desktop hosts and ~99% of Mobile hosts support it (..go away WinXP ) Source – Mobile Operating System, Statistica, Jan 2017 Source – Desktop Operating System, Netmarketshare, Jan’14-Dec’16 BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 12 IPv4 Address Depletion Causes Impact differently • The ISP Impact: • Lack of IPv4 addresses for users • Harder to grow the business • The User Impact (explicit or implicit): • IP reputation (more on this later) • IPv4 address sharing • Breaks applications • Complicates operating servers • Limits UDP/TCP ports per user • IPv6 enabled services are catching up BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 14 Transition Technologies • How do we migrate from IPv4 to IPv6? • Short term1: can’t enable IPv6 immediately, need more IPv4 (or share IPv4) • Short term2: enable IPv6 immediately, need more IPv4 (or share IPv4) • Long term: simple network, single protocol – IPv6 • What does this really mean? • IPv6 to co-exist with IPv4 • IPv4 address sharing to become wide-spread • IPv6 to interoperate with IPv4 Transition technologies pave the way to move from IPv4 to IPv6 BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 16 Agenda • Goal of Transition Technologies • Overview of Transition Technologies • Dual Stack – Impact ( & Happy Eyeballs) • IPv4 Address Sharing - Impact • CGN 44, DS-Lite, 6rd, MAP • CGN 64 for IPv6-only • Conclusion Towards IPv6 …with or without IPv4 Transition Technologies in One Slide This is Obtain More IPv4 Addresses This is where IPv4 Share IPv4 Addresses where we are: we CGN DualDual CGN CGN CGN CGN have to Stack Stack 44 44 44* 64 be: Mostly ? MAP IPv4 & + + + + 6rd IPv6 Dual (Dual- DS- Single Address Stack Stack) Lite -Stack Mostly Run-out IPv6; 1. CGN = Carrier Grade NAT - Stateful 2. Modified to support DS-Lite BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 18 Towards IPv6 …with or without IPv4 . This is Obtain More IPv4 Addresses This is where IPv4 Share IPv4 Addresses where we are: we CGNCGN DualDual CGN 44 CGN CGN have to StackStack 44 * 64 Mostly + MAP be: + + + IPv4 & 6rd 6rd IPv6 Dual (Dual- DS- Single Address Stack Stack) Lite -Stack Mostly Run-out IPv6; 1. CGN = Carrier Grade NAT - Stateful 2. Modified to support DS-Lite BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 19 Towards IPv6 …with or without IPv4 Transition Technologies in One Slide Options Arbitrary IP CPE LAN CPE WAN Tunnel or In-network Extra CPE addressing of IPv4 or IPv6 IPv4 or IPv6 Translate? “State”? features? CPE? 0 Single-Stack IPv4 IPv4 -NA- -NA- Yes No 1 Dual-Stack IPv4 + IPv6 IPv4+IPv6 -NA- -NA- Yes No** 2 Single-Stack IPv4 IPv4 Translate Yes (CGN44) Yes No 3 Dual-Stack IPv4 + IPv6 IPv4+IPv6 Translate Yes (CGN44) Yes No** 4 DS-Lite IPv4 + IPv6 IPv6 Both Yes (CGN44) Yes Yes 5 6rd IPv4 + IPv6 IPv4 Tunnel No No Yes 6 6rd + CGN IPv4 + IPv6 IPv4 Both Yes (CGN44) No Yes 7 MAP IPv4 + IPv6 IPv6 Either No Yes* Yes 8 Single-Stack IPv6 IPv6 Translate Yes (CGN64) Yes Yes|No * Allows both arbitrary and algorithmic mapping ** Changes needed if IPv6 is not supported by existing CPE BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 20 Agenda • Goal of Transition Technologies • Overview of Transition Technologies • Single-Stack IPv4 – Obtain more IPv4 • Dual Stack – Impact ( & Happy Eyeballs) • IPv4 Address Sharing - Impact • CGN 44, DS-Lite, 6rd, MAP • Single-Stack IPv6 & CGN 64 • Conclusion 0. Obtain IPv4 Addresses Host/CPE gets just IPv4 prefixes This is Obtain More IPv4 Addresses This is where IPv4 Share IPv4 Addresses where we are: we CGNCGN Dual CGN 44 CGN CGN have to Stack 44 * 64 Mostly + MAP be: + + + IPv4 & 6rd Dual (Dual6rd- DS- Single Address Stack Stack) Lite -Stack Mostly Run-out IPv6; 1. CGN = Carrier Grade NAT - Stateful 2. Modified to support DS-Lite BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 22 0. Obtain IPv4 Addresses • Obtain IPv4 addresses from Regional Internet Registry (RIRs) or open market • RIR: May Not have any left. • Open market: USD $10-$15 per IPv4 address • IPv6, well, is optional • ADVANTAGES: • No CGN, no address sharing, no operational changes • No need to press for IPv6 deployment • DISADVANTAGES : • If business growing, delaying the inevitable • Geo-location needs to be updated (mileage varies) • No IPv6 deployed • Reputation might be bad BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 23 Agenda • Goal of Transition Technologies • Overview of Transition Technologies • Single-Stack IPv4 – Obtain more IPv4 • Dual Stack – Impact ( & Happy Eyeballs) • IPv4 Address Sharing - Impact • CGN 44, DS-Lite, 6rd, MAP • Single-Stack IPv6 & CGN 64 • Conclusion 1. Dual-Stack Host/CPE gets both IPv4 and IPv6 prefixes This is Obtain More IPv4 Addresses This is where IPv4 Share IPv4 Addresses where we are: we CGNCGN DualDual CGN 44 CGN CGN have to Stack Stack 44 * 64 Mostly + MAP be: + + + IPv4 & 6rd 6rd IPv6 Dual (Dual- DS- Single Address Stack Stack) Lite -Stack Mostly Run-out IPv6; 1. CGN = Carrier Grade NAT - Stateful 2. Modified to support DS-Lite BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 25 1. Dual Stack The Reality • Reality: More and more IPv4 address sharing (NAT, MAP) • Covered in co-existence section later on. • Hosts should prefer IPv6 to IPv4 • Generally necessary • Without this preference, IPv4 would persist until IPv4 is turned off IPv6 Road • But what if IPv6 is broken? Overloaded??? • IPv6 peering is down ... • Tunnel is down ... • (Microsoft IPv6 NCSI is down....) BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 27 1. Dual Stack Do I use IPv6 or IPv4 ? • Dual-stack client connecting to dual-stack server • IPv6 is preferred by default (RFC6724) • If IPv6 is slower, then users blame IPv6 and may disable IPv6! • IPv6 better not be slower than IPv4 • Who can guarantee that ! • What if IPv6 is broken altogether? • What if IPv6 is broken to few websites? BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 28 1. Dual Stack Problem: IPv6 is Broken to a certain website? BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 29 1. Dual Stack Solution – Happy Eyeballs (RFC6555) Note: Slight Preference is given to IPv6 connection BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 30 1. Dual Stack Solution – Happy Eyeballs Optimization (RFC6555) BRKSPG-2602 © 2017 Cisco and/or its affiliates. All rights reserved. Cisco Public 31 1. Dual-Stack Happy Eyeballs (RFC6555) • Users are happy • Aimed initially at web browsing • Web browsing is the most common application • Fast response even if IPv6 (or IPv4) path is down • Network administrators are happy • Users no longer trying to disable IPv6 • Reduces IPv4 usage (reduces load on CGN) • Content providers are happy Source: http://seclists.org/nanog/2016/Jun/809 • Improved geolocation and DoS visibility with IPv6 BRKSPG-2602 © 2017 Cisco and/or its affiliates.
Load more

Recommended publications
  • (IETF) D. Wing Request for Comments: 6555 A
    Internet Engineering Task Force (IETF) D. Wing Request for Comments: 6555 A. Yourtchenko Category: Standards Track Cisco ISSN: 2070-1721 April 2012 Happy Eyeballs: Success with Dual-Stack Hosts Abstract When a server's IPv4 path and protocol are working, but the server's IPv6 path and protocol are not working, a dual-stack client application experiences significant connection delay compared to an IPv4-only client. This is undesirable because it causes the dual- stack client to have a worse user experience. This document specifies requirements for algorithms that reduce this user-visible delay and provides an algorithm. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6555. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
    [Show full text]
  • Performance Analysis and Comparison of 6To4 Relay Implementations
    (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 4, No. 9, 2013 Performance Analysis and Comparison of 6to4 Relay Implementations Gábor Lencse Sándor Répás Department of Telecommunications Department of Telecommunications Széchenyi István University Széchenyi István University Győr, Hungary Győr, Hungary Abstract—the depletion of the public IPv4 address pool may delegated the last five “/8” IPv4 address blocks to the five speed up the deployment of IPv6. The coexistence of the two Regional Internet Registries in 2011 [3]. Therefore an versions of IP requires some transition mechanisms. One of them important upcoming coexistence issue is the problem of an is 6to4 which provides a solution for the problem of an IPv6 IPv6 only client and an IPv4 only server, because internet capable device in an IPv4 only environment. From among the service providers (ISPs) can still supply the relatively small several 6to4 relay implementations, the following ones were number of new servers with IPv4 addresses from their own selected for testing: sit under Linux, stf under FreeBSD and stf pool but the huge number of new clients can get IPv6 addresses under NetBSD. Their stability and performance were investigat- only. DNS64 [4] and NAT64 [5] are the best available ed in a test network. The increasing measure of the load of the techniques that make it possible for an IPv6 only client to 6to4 relay implementations was set by incrementing the number communicate with an IPv4 only server. Another very important of the client computers that provided the traffic. The packet loss and the response time of the 6to4 relay as well as the CPU coexistence issue comes from the case when the ISP does not utilization and the memory consumption of the computer support IPv6 but the clients do and they would like to running the tested 6to4 relay implementations were measured.
    [Show full text]
  • Deploying Ipv6 in Fixed and Mobile Broadband Access Networks
    Deploying IPv6 in Fixed and Mobile Broadband Access Networks Tomás Lynch – Ericsson Jordi Palet Mar8nez – Consulintel Ariel Weher – LACNOG Agenda (1/2) • IPv6 in Broadband Networks – Where are we? • IPv6 TransiHon Mechanisms for Broadband Networks • IPv6 Prefix Assignment • Deployment of IPv6 in Mobile Broadband Networks • Deployment of IPv6 in PPPoE & IPoE Networks • Deployment of IPv6 in Cable Networks Agenda (2/2) • Current IPv6 Deployments in Broadband Access Networks • Other Systems Involved in IPv6 Deployment • IPv6 TransiHon Planning • Useful Documents • Conclusions IPv6 in Broadband Networks Where Are We? IPv4 Yes, the IPv4 pool IPv4 with NAT But we can use IPv4 and NAT!!! Yeah, right … IPv6 Why IPv6? Move to IPv6 Now! New Business Operaonal OpportuniHes Needs Allows continuous growth Simplify service of Internet business providers operations Ready for Cloud and M2M IPv4 Address (moving towards 50 billion) Depletion Increasing government New business models regulations requiring IPv6 deployment IPv6 Readiness – No Excuses! › Laptops, pads, mobile phones, dongles, CPEs: Ready! – OS: 90% of all Operating systems are IPv6 capable – Browsers are ready! – Mobile devices: Android, IOS6, LTE devices are ready! – Mobile Apps: More than 85% with IPv6 support – CPEs: More than 45% support IPv6 IPv6 Traffic is Growing – No Excuses! In LACNIC23, May 2015 • Peru 13% • World 6% Source: Google IPv6 StasHcs - 8/16/2015 So ISP what are you doing? • You may have IPv6 in your backbone: – Dual stack backbone, 6PE, 6VPE – Easy stuff! • Loopbacks, IGP (yes, ISIS is great), we love to configure BGP! – If not, what are you waiHng for? • What about your customers? – Mobile broadband: customers change their phone more quickly than their clothes, easy stuff but those GGSN licenses are killing me.
    [Show full text]
  • Ipv6-Only Deployment in Broadband and Cellular Networks Ipv4 As-A-Service
    IPv6-only Deployment in Broadband and Cellular Networks IPv4 as-a-Service LACNIC31 May, 2019 Punta Cana, DO @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 stack IPv6
    [Show full text]
  • Guidelines for the Secure Deployment of Ipv6
    Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks NIST Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 December 2010 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Dr. Patrick D. Gallagher, Director GUIDELINES FOR THE SECURE DEPLOYMENT OF IPV6 Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-119 Natl. Inst. Stand. Technol. Spec. Publ. 800-119, 188 pages (Dec. 2010) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately.
    [Show full text]
  • Deploy CGN to Retain Ipv4 Addressing While Transitioning to Ipv6
    White Paper Deploy CGN to Retain IPv4 Addressing While Transitioning to IPv6 The IANA ran out of IPv4 addresses to allocate in February 2011, and the Regional Internet Registries (RIR) will have assigned most of their addresses by the end of 2011. The world is faced with the fundamental problem of IPv4 address space exhaustion. There is a huge demand for IP addresses resulting from the explosive growth of mobile devices, including smartphones, portable gaming consoles, tablets, laptops and netbooks, and machine-to- machine modules. Figure 1 shows the expected growth in mobile phones alone. The number of mobile subscribers is expected to be 4.5 billion by 2014. Figure 1. Expected Mobile Phone Growth (in Millions) (Source: IDC) Preserve IPv4 Addressing with CGN Service providers are looking for ways to extend the use of the IPv4 addresses they have during their transition to IPv6. IPv4 addresses are still valid and ubiquitous, and not everyone is using IPv6 yet, so the two addressing schemes will coexist for a long time. Although new IPv4 addresses are not available, there is a short-term alternative that ensures your business continuity. That alternative is Carrier Grade NAT (CGN), a solution that service providers can employ today to extend their use of IPv4 addresses. The extension is achieved in two ways: IPv4 addresses are extended because they are translated from many private addresses to one public address. The extension is also a time extension–-service providers can continue using IPv4-only networks for a while. Cisco’s approach to help customers as they transition to IPv6 is to “Preserve, Prepare and Prosper.” CGN helps customers “Preserve” the present mode of operation.
    [Show full text]
  • Implications of Large Scale Network Address Translation (NAT)
    Implications of Large Scale Network Address Translation (NAT) A BROADBAND INTERNET TECHNICAL ADVISORY GROUP TECHNICAL WORKING GROUP REPORT A Near-Uniform Agreement Report (100% Consensus Achieved) Issued: March 2012 Copyright / Legal Notice Copyright © Broadband Internet Technical Advisory Group, Inc. 2012. All rights reserved. This document may be reproduced and distributed to others so long as such reproduction or distribution complies with Broadband Internet Technical Advisory Group, Inc.’s Intellectual Property Rights Policy, available at www.bitag.org, and any such reproduction contains the above copyright notice and the other notices contained in this section. This document may not be modified in any way without the express written consent of the Broadband Internet Technical Advisory Group, Inc. This document and the information contained herein is provided on an “AS IS” basis and BITAG AND THE CONTRIBUTORS TO THIS REPORT MAKE NO (AND HEREBY EXPRESSLY DISCLAIM ANY) WARRANTIES (EXPRESS, IMPLIED OR OTHERWISE), INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE, OR TITLE, RELATED TO THIS REPORT, AND THE ENTIRE RISK OF RELYING UPON THIS REPORT OR IMPLEMENTING OR USING THE TECHNOLOGY DESCRIBED IN THIS REPORT IS ASSUMED BY THE USER OR IMPLEMENTER. The information contained in this Report was made available from contributions from various sources, including members of Broadband Internet Technical Advisory Group, Inc.’s Technical Working Group and others. Broadband Internet Technical Advisory Group, Inc. takes no position regarding the validity or scope of any intellectual property rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this Report or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights.
    [Show full text]
  • Ipv6 Transition Strategies
    IPv6 Transition Strategies Philip Smith <[email protected]> MENOG 14 Dubai 1st April 2014 Last updated 5th March 2014 1 Presentation Slides p Will be available on n http://thyme.apnic.net/ftp/seminars/ MENOG14-IPv6-Transition.pdf n And on the MENOG14 website p Feel free to ask questions any time Introduction Why should we care? 3 “The times, They are a’ changin’” IPv4 All Gone! Source: ipv4.potaroo.net (Jan 2014) 4 Is IPv4 really running out? p Yes! n IANA IPv4 free pool ran out on 3rd February 2011 n RIR IPv4 free pool will run out soon after n www.potaroo.net/tools/ipv4/ p (depends on RIR soft-landing policies) p The runout gadgets and widgets are now watching when the RIR pools will run out: n inetcore.com/project/ipv4ec/index_en.html n ipv6.he.net/statistics/ 5 Strategies available for Service Providers p Do nothing n Wait and see what competitors do n Business not growing, so don’t care what happens p Extend life of IPv4 n Force customers to NAT n Buy IPv4 address space on the marketplace p Deploy IPv6 n Dual-stack infrastructure n IPv6 and NATed IPv4 for customers n 6rd (Rapid Deploy) with native or NATed IPv4 for customers n 464XLAT with native IPv6 and NATed IPv4 for customers n Or other combinations of IPv6, IPv4 and NAT 6 Definition of Terms 7 Dual-Stack Networks p Both IPv4 and IPv6 have been fully deployed across all the infrastructure n Routing protocols handle IPv4 and IPv6 n Content, application, and services available on IPv4 and IPv6 p End-users use dual-stack network transparently: n If DNS returns IPv6 address for domain
    [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]
  • Ipv4 Exhaustion: NAT and Transition to Ipv6 for Service Providers
    BRKSPG-2602 IPv4 Exhaustion: NAT and Transition to IPv6 for Service Providers Rajiv Asati, Distinguished Engineer, Cisco Cisco Spark Questions? Use Cisco Spark to communicate with the speaker after the session How 1. Find this session in the Cisco Live Mobile App 2. Click “Join the Discussion” 3. Install Spark or go directly to the space 4. Enter messages/questions in the space cs.co/ciscolivebot#BRKSPG-2602 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public Hmmm……..CGNAT issue or something else ? IPv4 – Classic But spare parts have run out BRKSPG-2602 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 5 IPv6 – Next Gen Getting to full parity and end-end use takes time Caution: New road may be needed BRKSPG-2602 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 6 Transition Technologies Driving your classic IPv4 (or next gen IPv6) around BRKSPG-2602 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 7 Abstract • Any service provider that has exhausted its IPv4 address pool, will not only have to deploy/offer IPv6, but also employ IPv4 sharing. This is because chunk of content may be reachable only via IPv4 internet, even though majority is available via IPv6 internet. • This session discusses few mechanisms such as MAP-T/E, 464XLAT, DS-Lite and CGN 64/44 etc. that facilitate IPv4 sharing with and without IPv6. It contrasts stateful and stateless translation techniques as well. • 6rd is included for reference as well. • This session is intended for Service Providers. BRKSPG-2602 © 2018 Cisco and/or its affiliates.
    [Show full text]
  • Configuring IP Address Sharing in a Large Scale Network: DNS64/NAT64
    DEPLOYMENT GUIDE Version 1.4 IMPORTANT: This guide has been archived. While the content in this guide is still valid for the products and version listed in the document, it is no longer being updated and may refer to F5 or 3rd party products or versions that have reached end-of-life or end-of-support. See https://support.f5.com/csp/article/K11163 for more information. Configuring IP Address Sharing in a Large Scale Network: DNS64/NAT64 Archived Table of Contents Table of Contents Configuring IP address sharing in a large scale network ........................................................... 1 Product versions and revision history ................................................................................. 1 Configuring the BIG-IP LTM for the private IPv4 network ...................................................... 2 Creating the SNAT Pool .........................................................................................................2 Supporting NAT with active FTP mode (optional) ........................................................... 5 Configuring the BIG-IP LTM for global IPv6 with DNS64 and NAT64 ................................. 7 Configuring the BIG-IP LTM for DNS64 ............................................................................. 8 Configuring the BIG-IP LTM for NAT64 ........................................................................... 12 Creating the IPv6 network virtual server ......................................................................... 14 Supporting NAT with active FTP mode
    [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]