Ipv4 Exhaustion: NAT and Transition to Ipv6 for Service Providers

Total Page:16

File Type:pdf, Size:1020Kb

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. All rights reserved. Cisco Public 8 IPv6 Adoption Continues to increase… Source: https://www.akamai.com/ Source: https://www.google.com/ BRKSPG-2602 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 9 Agenda • Goal of Transition Technologies • Overview of Transition Technologies • Single-Stack • 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 to the hosts * • Hosts: Windows, OSX, iOS, Android, Linux etc. • Routers: IOS, XR, NXOS etc. IPv4+IPv6 Network IPv4 and/or IPv6 Destinations * RFC7755 now suggests Single-stack IPv6 for DC BRKSPG-2602 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 12 Recommended Approach for IPv6 Dual-Stack Deployment (per IETF RFC 4213), since 2005 ~90% of Desktop hosts and ~99% of Mobile hosts • Dual-Stack to the hosts * support Dual-Stack • Hosts: Windows, OSX, iOS, Android, Linux etc. • Routers: IOS, XR, NXOS etc. Source – Mobile Operating System, Statistica, Jan 2017 Source – Desktop Operating System, Netmarketshare, Jan’14-Dec’16 BRKSPG-2602 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 13 Recommended Approach for IPv6 Dual-Stack Deployment (per IETF RFC 4213) IPv4+IPv6 Hosts (Dual Stack) • Dual-Stack to the hosts * • Hosts: Windows, OSX, iOS, Android, Linux etc. • Routers: IOS, XR, NXOS etc. IPv4+IPv6 Network • But note… • IPv4 exhaustion is underway • Every host can NOT be assigned a public IPv4 address • Two protocol stacks to be managed in network IPv4 and/or IPv6 Destinations * RFC7755 now suggests Single-stack IPv6 for DC BRKSPG-2602 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 14 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 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 15 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 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 17 Agenda • Goal of Transition Technologies • Overview of Transition Technologies • Single-Stack • 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 This is where where we are: we have to Mostly ? be: IPv4 & Address Mostly Run-out IPv6; 1. CGN = Carrier Grade NAT - Stateful 2. Modified to support DS-Lite BRKSPG-2602 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 19 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 StackStack 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 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 20 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 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 22 Agenda • Goal of Transition Technologies • Overview of Transition Technologies • Single-Stack IPv4 – Obtain more IPv4 • Dual Stack – Impact ( & Happy Eyeballs) • IPv4 Address Sharing - Impact • Single-Stack IPv4 – CGN 44, 6rd • Single-Stack IPv6 – DS-Lite, 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; BRKSPG-2602 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 24 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 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 25 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 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 27 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 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 29 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 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 30 1. Dual Stack Problem: IPv6 is Broken or slower to a certain website ! Unhappy user BRKSPG-2602 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 31 1. Dual Stack Solution – Happy Eyeballs (RFC6555) Note: Slight Preference is given to IPv6 connection BRKSPG-2602 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 32 1. Dual Stack Solution – Happy Eyeballs Optimization (RFC6555/ RFC8305) BRKSPG-2602 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 33 1. Dual Stack Solution – Happy Eyeballs Optimization (RFC6555/ RFC8305) BRKSPG-2602 © 2018 Cisco and/or its affiliates.
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]
  • Empirical Analysis of the Effects and the Mitigation of Ipv4 Address Exhaustion
    TECHNISCHE UNIVERSITÄT BERLIN FAKULTÄT FÜR ELEKTROTECHNIK UND INFORMATIK LEHRSTUHL FÜR INTELLIGENTE NETZE UND MANAGEMENT VERTEILTER SYSTEME Empirical Analysis of the Effects and the Mitigation of IPv4 Address Exhaustion vorgelegt von M.Sc. Philipp Richter geboren in Berlin von der Fakultät IV – Elektrotechnik und Informatik der Technischen Universität Berlin zur Erlangung des akademischen Grades DOKTOR DER NATURWISSENSCHAFTEN -DR. RER. NAT.- genehmigte Dissertation Promotionsausschuss: Vorsitzender: Prof. Dr.-Ing. Sebastian Möller, Technische Universität Berlin Gutachterin: Prof. Anja Feldmann, Ph.D., Technische Universität Berlin Gutachter: Prof. Vern Paxson, Ph.D., University of California, Berkeley Gutachter: Prof. Steve Uhlig, Ph.D., Queen Mary University of London Tag der wissenschaftlichen Aussprache: 2. August 2017 Berlin 2017 Abstract IP addresses are essential resources for communication over the Internet. In IP version 4, an address is represented by 32 bits in the IPv4 header; hence there is a finite pool of roughly 4B addresses available. The Internet now faces a fundamental resource scarcity problem: The exhaustion of the available IPv4 address space. In 2011, the Internet Assigned Numbers Authority (IANA) depleted its pool of available IPv4 addresses. IPv4 scarcity is now reality. In the subsequent years, IPv4 address scarcity has started to put substantial economic pressure on the networks that form the Internet. The pools of available IPv4 addresses are mostly depleted and today network operators have to find new ways to satisfy their ongoing demand for IPv4 addresses. Mitigating IPv4 scarcity is not optional, but mandatory: Networks facing address shortage have to take action in order to be able to accommodate additional subscribers and customers. Thus, if not confronted, IPv4 scarcity has the potential to hinder further growth of the Internet.
    [Show full text]
  • Ipv6 AAAA DNS Whitelisting a BROADBAND INTERNET TECHNICAL ADVISORY GROUP TECHNICAL WORKING GROUP REPORT
    IPv6 AAAA DNS Whitelisting A BROADBAND INTERNET TECHNICAL ADVISORY GROUP TECHNICAL WORKING GROUP REPORT A Near-Uniform Agreement Report (100% Consensus Achieved) Issued: September 2011 Copyright / Legal NotiCe Copyright © Broadband Internet Technical Advisory Group, Inc. 2011. 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 – What Is It, Why Is It Important, and Who Is in Charge? … Answers to Common Questions from Policy Makers, Executives and Other Non­Technical Readers
    IPv6 – What is it, why is it important, and who is in charge? … answers to common questions from policy makers, executives and other non­technical readers. A factual paper prepared for and endorsed by the Chief Executive Officers of ICANN and all the Regional Internet Registries, October 2009. 1. What is IPv6? “IP” is the Internet Protocol, the set of digital communication codes which underlies the Internet infrastructure. IP allows the flow of packets of data between any pair of points on the network, providing the basic service upon which the entire Internet is built. Without IP, the Internet as we know it would not exist. Currently the Internet makes use of IP version 4, or IPv4, which is now reaching the limits of its capacity to address additional devices. IPv6 is the “next generation” of IP, which provides a vastly expanded address space. Using IPv6, the Internet will be able to grow to millions of times its current size, in terms of the numbers of people, devices and objects connected to it1. 2. Just how big is IPv6? To answer this question, we must compare the IPv6 address architecture with that of IPv4. The IPv4 address has 32 bits, allowing today’s Internet to connect up to around four billion devices. By contrast, IPv6 has an address of 128 bits. Because each additional bit doubles the size of the address space, an extra 96 bits increases the theoretical size of the address space by many trillions of times. For comparison, if IPv4 were represented as a golf ball, then IPv6 would be approaching the size of the Sun.2 IPv6 is certainly not infinite, but it is not going to run out any time soon.
    [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]
  • Ipv4 and Ipv6 Subnetting Demo
    IPv4 and IPv6 Subnetting Demo Instructor: Networks rely on the use of IP addresses to allow devices to communicate with each other. These addresses are often obtained as a single large block and are given to the organizations that require them. However, a single block of addresses rarely meets the needs of a network and it needs to be segmented in order to better accommodate the network. An IP address is made up of two parts, the address itself and the subnet mask. The subnet mask helps us determine which part of the address defines the network and which part defines the specific host in the network. This is done by comparing the binary bits of the subnet mask to the address itself. Where there is a one in the subnet mask, we are looking at the network portion of the address; where there is a zero, we are looking at the host portion, or the identifier of the specific machine. The subnet can be represented in "CIDR" notation which includes a slash followed by the number of ones, or network bits, in the subnet. So the subnet mask 255.255.255.0 could be shortened to /24 because there are 24 binary ones. Subnets are an effective way to segment a single large network into a Page 1 of 4 group of smaller ones. In IPv4, this concept is fairly simple. A network will be assigned an address block, let's say 192.168.1.0/24. Then, we determine the amount of subnets we need and how many hosts we need in each subnet.
    [Show full text]
  • Ipv6 Cheat Sheet
    Internet Protocol Version 6 (IPv6) Basics Cheat Sheet IPv6 Addresses by Jens Roesen /64 – lan segment, 18,446,744,073,709,551,616 v6 IPs IPv6 quick facts /48 – subscriber site, 65536 /64 lan segments successor of IPv4 • 128-bit long addresses • that's 296 times the IPv4 address space • that's 2128 or 3.4x1038 or over 340 /32 – minimum allocation size, 65536 /48 subscriber sites, allocated to ISPs undecillion IPs overall • customer usually gets a /64 subnet, which yields 4 billion times the Ipv4 address space • no need for network address translation (NAT) any more • no broadcasts any more • no ARP • stateless address 2001:0db8:0f61:a1ff:0000:0000:0000:0080 configuration without DHCP • improved multicast • easy IP renumbering • minimum MTU size 1280 • mobile IPv6 • global routing prefix subnet ID interface ID mandatory IPsec support • fixed IPv6 header size of 40 bytes • extension headers • jumbograms up to 4 GiB subnet prefix /64 IPv6 & ICMPv6 Headers IPv6 addresses are written in hexadecimal and divided into eight pairs of two byte blocks, each containing four hex IPv6 header digits. Addresses can be shortened by skipping leading zeros in each block. This would shorten our example address to 0 8 16 24 32 2001:db8:f61:a1ff:0:0:0:80. Additionally, once per IPv6 IP, we can replace consecutive blocks of zeros with a version traffic class flow label double colon: 2001:db8:f61:a1ff::80. The 64-bit interface ID can/should be in modified EUI-64 format. A MAC 00 03 ba 24 a9 6c payload length next header hop limit 48-bit MAC can be transformed to an 64-bit interface ID by inverting the 7th (universal) bit and inserting a ff and fe byte after rd source IPv6 address the 3 byte.
    [Show full text]
  • Manage Domain Name System (DNS) Servers on Sx500 Series Stackable Switches
    Manage Domain Name System (DNS) Servers on Sx500 Series Stackable Switches Objective The Domain Name System (DNS) server translates a domain name into an IP address. This IP address for a particular domain name can be retrieved from the DNS cache if it is available locally, or it is queried among various top level domain servers to retrieve this information. This article explains how to add DNS servers on the Sx500 Series Stackable Switch. Applicable Devices • Sx500 Series Stackable Switches Software Version • v1.2.7.76 Configuration of DNS Server Step 1. Log in to the web configuration utility to choose IP Configuration > Domain Name System > DNS Servers. The DNS Server page opens: Enable DNS Server Step 1. In the DNS field, check Enable in order to enable the DNS feature of the switch. Step 2. In the Default Domain Name field in the Default Parameters area, enter the domain name that you want to configure as Fully Qualified Domain Name (FQDN). The switch appends this domain name to non-fully qualified domain names to make them FQDNs. Note: The switch identifies the default domain name server type in the Type field. • DHCP — Default name is given dynamically by the DHCP Server. • Static — Default name is user-defined. • N/A — No default domain name. Step 3. Click Apply to save the DNS settings. Add DNS Server Step 1. In the DNS Server Table, click Add at the bottom of the table to add DNS servers so that the switch can query the IP address of domain names. Step 2. In the IP Version field, click either the Version 4 radio button or the Version 6 radio button based upon the type of server IP address (IPv4 or IPv6).
    [Show full text]
  • Ipv6 and DNS Ipv6 – the Future of IP
    IPv6 and DNS Chapters 22,29 CSA 442 IPv6 – The Future of IP • Current version of IP - version 4 - is over 20 years old • IPv4 has shown remarkable ability to move to new technologies – IP has accommodated dramatic changes since original design – Basic principles still appropriate today – Many new types of hardware – Scaling - from a few tens to a few tens of millions of computers • But, as with any old technology, it has some problems • IETF has proposed entirely new version to address some specific problems 1 Motivation for Change • Address space – 32 bit address space allows for over a million networks – But…all that is left is Class C and too small for many organizations – Predictions we would have run out of IP addresses by now – Besides, how will we network all our toasters and cell phones to the Internet? • Type of service – Different applications have different requirements for delivery reliability and speed ; i.e. real time data, quality of service – Current IP has type of service that's not often implemented • Multicast Name and Version Number • Preliminary versions called IP - Next Generation (IPng) • Several proposals all called IPng • One was selected and uses next available version number (6) – Version 5 was already assigned to an experimental protocol, ST, Streams Protocol • Result is IP version 6 (IPv6) • In the works since 1990 2 New Features of IPv6 • Address size - IPv6 addresses are 128bits – ~3*1038 possible addresses in theory • Header format - entirely different • Extension headers - Additional information stored
    [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]
  • BRKRST-3304.Pdf
    #CLUS Hitchhikers Guide to Ipv6 Nicole Wajer – Chief Stroopwafel Officer BRKRST-3304 #CLUS Cisco Webex Teams Questions? Use Cisco Webex Teams (formerly Cisco Spark) to chat with the speaker after the session How 1 Find this session in the Cisco Events App 2 Click “Join the Discussion” 3 Install Webex Teams or go directly to the team space 4 Enter messages/questions in the team space Webex Teams will be moderated cs.co/ciscolivebot#BRKRST-3304 by the speaker until June 18, 2018. #CLUS © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 3 Nicole Nicole Wajer Technical Solutions Architect @vlinder_nl #CLUS BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 4 “Space,” it says, “is big. Really big. You just won’t believe how vastly hugely mindboggingly big it is. I mean you may think it’s a long way down the road to the chemist, but that’s just peanuts to space. Listen …” and so on. The Hitchhiker's Guide to the Galaxy #CLUS BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 5 This Session…. #CLUS BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 6 This Session…. #CLUS BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 7 Don’t Panic #CLUS BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 8 Encyclopaedia Galactica • Easy to miss – Warm up your brain • Neighbor And Router Discovery • Addressing • IPv4 Coexistence And Transition • IPv6-centric Deployments #CLUS BRKRST-3304 © 2018 Cisco and/or its affiliates.
    [Show full text]