DOCSLIB.ORG

Planning Guide/Roadmap Toward Ipv6 Adoption Within the U.S. Government

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Planning Guide/Roadmap Toward Ipv6 Adoption Within the U.S. Government Planning Guide/Roadmap Toward IPv6 Adoption within the U.S. Government Strategy and Planning Committee Federal Chief Information Officers Council Version 2.0 July 2012 The Federal CIO Council Strategy and Planning Committee Technology Infrastructure Subcommittee Federal IPv6 Working Group In collaboration with the The American Council for Technology/Industry Advisory Council’s Network and Telecommunications (N&T-SIG) Present: Planning Guide/Roadmap Toward IPv6 Adoption within the U.S. Government July 2012 Planning Guide/Roadmap Toward IPv6 Adoption within the U.S. Government Table of Contents Executive Summary .......................................................................................................................................... 1 1. Introduction .............................................................................................................................................. 1 1.1 Background ..................................................................................................................................... 2 1.2 Adoption Benefits ............................................................................................................................ 3 1.3 Guidance ......................................................................................................................................... 3 1.4 Our Business Situation ................................................................................................................... 4 2. Federal Transition Components .......................................................................................................... 7 2.1 OMB Guidance ............................................................................................................................... 7 2.1.1 OMB September 2010 Memorandum ................................................................................ 7 2.1.2 Agency Transition Plans ...................................................................................................... 8 2.1.3 OMB Memorandum M‐05‐22 .............................................................................................. 8 2.2 IPv6 Federal Acquisition Regulations (FAR) ................................................................................ 9 2.2.1 Current Applicable FAR Previsions..................................................................................... 9 2.2.2 Acquisition Guidance............................................................................................................ 9 2.3 Federal IPv6 Task Force .............................................................................................................. 12 2.4 Sample Agency Timelines ........................................................................................................... 12 2.4.1 Sample Federal Agency Execution Timeline ................................................................... 12 2.4.2 Implementation Recommendations .................................................................................. 15 2.5 Agency Progress Tracking ........................................................................................................... 16 2.6 Sub-Working Groups .................................................................................................................... 17 2.6.1 IT Management Sub-Working Group ................................................................................ 17 2.6.2 Outreach Sub-Working Group ........................................................................................... 17 2.6.3 Technical Sub-Working Group .......................................................................................... 18 2.7 NIST USGv6 Activities ................................................................................................................. 18 2.7.1 USGv6 Profile Process ...................................................................................................... 18 2.7.2 USGv6 Test Program ......................................................................................................... 18 2.8 DoD IPv6 Product Profile ............................................................................................................. 19 3. The Business Rationale for IPv6 ........................................................................................................ 20 4. Federal IPv6 Transition: The “To Be” State ..................................................................................... 22 4.1 The 2012 “To Be” State ................................................................................................................ 22 4.2 The 2014 “To Be” State ................................................................................................................ 22 July 2012 Page i Planning Guide/Roadmap Toward IPv6 Adoption within the U.S. Government 4.3 Beyond the 2014 State ................................................................................................................. 23 5. Leveraging The Common Approach to Federal Enterprise Architecture .................................. 26 5.1 Using the Sub-Architecture Domains .......................................................................................... 28 5.1.1 Developing a Shared Approach to Infrastructure Services ............................................. 30 5.2 EA-Driven IPv6 Planning .............................................................................................................. 31 5.2.1 Define Business Needs and Objectives ........................................................................... 31 5.2.2 Define the Applications Supporting Each Business Function and the Services Provided by Each Application (Enabling Each Business Function) and Identify Potential IPv6- Enabled Services ...................................................................................... 31 5.2.3 Identify Each Application’s Technology Components, Assessing Changes Required Support IPv6 Transition. .................................................................................................... 32 5.2.4 Using the USG IPv6 Standards Profile ............................................................................. 32 5.3 Developing an IPv6 Transition Strategy Plan ............................................................................. 33 5.4 Integration with Capital Planning ................................................................................................. 34 5.5 OMB IPv6 EA Assessment Criteria ............................................................................................. 31 6. Transition Steps .................................................................................................................................... 32 6.1 Accellerating IPv6 Deployment .................................................................................................... 32 6.1.1 Develop an IPv6 Test Lab Capability ................................................................................ 32 6.2 Standup Centralized Addressing Authority (CAA) ..................................................................... 33 6.2.1 Address Plan Management and Policies ......................................................................... 34 6.2.2 Address Acquisition ............................................................................................................ 35 6.2.3 Establish Address Block Allocation and Management Procedures ............................... 36 6.2.4 Interfaces for DHCP, DNS, Network Management and Provisioning Systems ............ 37 6.2.5 Address Space Plan Management and Address Assignment System .......................... 38 6.3 Domain Name Service ................................................................................................................. 40 6.4 Address Assignment Methods ..................................................................................................... 42 6.5 Network Management .................................................................................................................. 43 6.6 IPv6 Security ................................................................................................................................. 44 6.6.1 Threats ................................................................................................................................. 45 6.6.2 IPv6 Capable Network and Security Devices .................................................................. 46 6.6.3 Address and Configuration Management Systems ......................................................... 47 6.6.4 Defense in Depth ................................................................................................................ 48 6.6.5 Reconnaissance ................................................................................................................. 48 July 2012 Page ii Planning Guide/Roadmap Toward IPv6 Adoption within the U.S. Government 6.6.6 Layer Two Threats .............................................................................................................. 50 6.6.7 Layer Three Threats ........................................................................................................... 52 6.6.8 Above Layer Four Threats ................................................................................................. 54 7. IPv6 Impact on Federal Initiatives.....................................................................................................
Load more

Recommended publications
  • Accelerating Adoption of Ipv6
    Accelerating Adoption of IPv6 LUDVIG AHLINDER and ANDERS ERIKSSON KTH Information and Communication Technology Degree project in Communication Systems First level, 15.0 HEC Stockholm, Sweden Accelerating Adoption of IPv6 Ludvig Ahlinder and Anders Eriksson 2011.05.17 Mentor and Examiner: Prof. Gerald Q. Maguire Jr School of Information and Communications Technology Royal Institute of Technology (KTH) Stockholm, Sweden Abstract It has long been known that the number of unique IPv4-addresses would be exhausted because of the rapid expansion of the Internet and because countries such as China and India are becoming more and more connected to the rest of the world. IPv6 is a new version of the Internet Protocol which is supposed to succeed the old version, IPv4, in providing more addresses and new services. The biggest challenge of information and communication technology (ICT) today is to transition from IPv4 to IPv6. The purpose of this thesis is to accelerate the adoption of IPv6 by highlighting the benefits of it compared to IPv4. Although the need for more IP-addresses is the most urgent incentive for the transition to IPv6, other factors also exist. IPv6 offers many improvements to IPv4 which are necessary for the continued expansion of Internet-based applications and services. Some argue that we do not need to transition to IPv6 as the problems with IPv4, mainly the address- shortage, can be solved in other ways. One of the methods of doing this is by extending the use of Network Address Translators (NATs), but the majority of experts and specialists believe that NATs should not be seen as a long-term solution.
    [Show full text]
  • INTERNET ADDRESSING: MEASURING DEPLOYMENT of Ipv6
    INTERNET ADDRESSING: MEASURING DEPLOYMENT OF IPv6 APRIL 2010 2 FOREWORD FOREWORD This report provides an overview of several indicators and data sets for measuring IPv6 deployment. This report was prepared by Ms. Karine Perset of the OECD‟s Directorate for Science, Technology and Industry. The Working Party on Communication Infrastructures and Services Policy (CISP) recommended, at its meeting in December 2009, forwarding the document to the Committee for Information, Computer and Communications Policy (ICCP) for declassification. The ICCP Committee agreed to make the document publicly available in March 2010. Experts from the Internet Technical Advisory Committee to the ICCP Committee (ITAC) and the Business and Industry Advisory Committee to the OECD (BIAC) have provided comments, suggestions, and contributed significantly to the data in this report. Special thanks are to be given to Geoff Huston from APNIC and Leo Vegoda from ICANN on behalf of ITAC/the NRO, Patrick Grossetete from ArchRock, Martin Levy from Hurricane Electric, Google and the IPv6 Forum for providing data, analysis and comments for this report. This report was originally issued under the code DSTI/ICCP/CISP(2009)17/FINAL. Issued under the responsibility of the Secretary-General of the OECD. The opinions expressed and arguments employed herein do not necessarily reflect the official views of the OECD member countries. ORGANISATION FOR ECONOMIC CO-OPERATION AND DEVELOPMENT The OECD is a unique forum where the governments of 30 democracies work together to address the economic, social and environmental challenges of globalisation. The OECD is also at the forefront of efforts to understand and to help governments respond to new developments and concerns, such as corporate governance, the information economy and the challenges of an ageing population.
    [Show full text]
  • Configuring DNS
    Configuring DNS The Domain Name System (DNS) is a distributed database in which you can map hostnames to IP addresses through the DNS protocol from a DNS server. Each unique IP address can have an associated hostname. The Cisco IOS software maintains a cache of hostname-to-address mappings for use by the connect, telnet, and ping EXEC commands, and related Telnet support operations. This cache speeds the process of converting names to addresses. Note You can specify IPv4 and IPv6 addresses while performing various tasks in this feature. The resource record type AAAA is used to map a domain name to an IPv6 address. The IP6.ARPA domain is defined to look up a record given an IPv6 address. • Finding Feature Information, page 1 • Prerequisites for Configuring DNS, page 2 • Information About DNS, page 2 • How to Configure DNS, page 4 • Configuration Examples for DNS, page 13 • Additional References, page 14 • Feature Information for DNS, page 15 Finding Feature Information Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
    [Show full text]
  • Reverse DNS What Is 'Reverse DNS'?
    Reverse DNS Overview • Principles • Creating reverse zones • Setting up nameservers • Reverse delegation procedures What is ‘Reverse DNS’? • ‘Forward DNS’ maps names to numbers – svc00.apnic.net -> 202.12.28.131 • ‘Reverse DNS’ maps numbers to names – 202.12.28.131 -> svc00.apnic.net 1 Reverse DNS - why bother? • Service denial • That only allow access when fully reverse delegated eg. anonymous ftp • Diagnostics • Assisting in trace routes etc • SPAM identifications • Registration • Responsibility as a member and Local IR In-addr.arpa • Hierarchy of IP addresses – Uses ‘in-addr.arpa’ domain • INverse ADDRess • IP addresses: – Less specific to More specific • 210.56.14.1 • Domain names: – More specific to Less specific • delhi.vsnl.net.in – Reversed in in-addr.arpa hierarchy • 14.56.210.in-addr.arpa Principles • Delegate maintenance of the reverse DNS to the custodian of the address block • Address allocation is hierarchical – LIRs/ISPs -> Customers -> End users 2 Principles – DNS tree - Mapping numbers to names - ‘reverse DNS’ Root DNS net edu com arpa au apnic in-addr whoiswhois RIR 202202 203 210 211.. ISP 6464 22 .64.202 .in-addr.arpa Customer 2222 Creating reverse zones • Same as creating a forward zone file – SOA and initial NS records are the same as normal zone – Main difference • need to create additional PTR records • Can use BIND or other DNS software to create and manage reverse zones – Details can be different Creating reverse zones - contd • Files involved – Zone files • Forward zone file – e.g. db.domain.net • Reverse zone file – e.g. db.192.168.254 – Config files • <named.conf> – Other • Hints files etc.
    [Show full text]
  • The Internet in Transition: the State of the Transition to Ipv6 in Today's
    Please cite this paper as: OECD (2014-04-03), “The Internet in Transition: The State of the Transition to IPv6 in Today's Internet and Measures to Support the Continued Use of IPv4”, OECD Digital Economy Papers, No. 234, OECD Publishing, Paris. http://dx.doi.org/10.1787/5jz5sq5d7cq2-en OECD Digital Economy Papers No. 234 The Internet in Transition: The State of the Transition to IPv6 in Today's Internet and Measures to Support the Continued Use of IPv4 OECD FOREWORD This report was presented to the OECD Working Party on Communication, Infrastructures and Services Policy (CISP) in June 2013. The Committee for Information, Computer and Communications Policy (ICCP) approved this report in December 2013 and recommended that it be made available to the general public. It was prepared by Geoff Huston, Chief Scientist at the Asia Pacific Network Information Centre (APNIC). The report is published on the responsibility of the Secretary-General of the OECD. Note to Delegations: This document is also available on OLIS under reference code: DSTI/ICCP/CISP(2012)8/FINAL © OECD 2014 THE INTERNET IN TRANSITION: THE STATE OF THE TRANSITION TO IPV6 IN TODAY'S INTERNET AND MEASURES TO SUPPORT THE CONTINUED USE OF IPV4 TABLE OF CONTENTS FOREWORD ................................................................................................................................................... 2 THE INTERNET IN TRANSITION: THE STATE OF THE TRANSITION TO IPV6 IN TODAY'S INTERNET AND MEASURES TO SUPPORT THE CONTINUED USE OF IPV4 .......................... 4
    [Show full text]
  • Ipv6 in Mobile Networks APRICOT 2016 – February 2016
    IPv6 in Mobile Networks APRICOT 2016 – February 2016 Telstra Unrestricted Introduction Sunny Yeung - Senior Technology Specialist, Telstra Wireless Network Engineering Technical Lead for Wireless IPv6 deployment Wireless Mobile IP Edge/Core Architect Telstra Unrestricted | IPv6 in Mobile Networks | Sunny Yeung | 02/2016 | 2 Agenda 1. Why IPv6 in Mobile Networks? 2. IPv6 – it’s here. Really. 3. Wireless Network Architectures 4. 464XLAT – Saviour? Or the devil in disguise? 5. Solution Testing and Results 6. Conclusion 7. Q&A Telstra Unrestricted | IPv6 in Mobile Networks | Sunny Yeung | 02/2016 | 3 Why IPv6 in Mobile Networks? Why IPv6 in Mobile Networks? • Exponential Growth in mobile data traffic and user equipment • Network readiness for Internet-of-Things • IPv4 public address depletion • IPv4 private address depletion • Offload the NAT44 architecture • VoLTE/IMS Remember – IPv6 should be invisible to the end-user Telstra Unrestricted | IPv6 in Mobile Networks | Sunny Yeung | 02/2016 | 5 IPv6 It’s Here. Really. IPv6 Global Traffic The world according to Google Source - https://www.google.com/intl/en/ipv6/statistics.html Telstra Unrestricted | IPv6 in Mobile Networks | Sunny Yeung | 02/2016 | 7 Carrier Examples SP1 SP2 / SP3 SP4 Dual-Stack SS+NAT64+DNS64+CLAT SS/DS+NAT64+DNS-HD +CLAT 1. Every carrier will have a unique set of circumstances that dictates which transition method they will use. There is no standard way of doing this. 2. You must determine which is the best method for your network. In any method, remember to ensure you have a long-term strategy for the eventual deployment of native Single Stack IPv6! Telstra Unrestricted | IPv6 in Mobile Networks | Sunny Yeung | 02/2016 | 8 IPv4 reality – from a business perspective 1.
    [Show full text]
  • Evolution of Mobile Networks and Ipv6
    Evolution of Mobile Networks and IPv6 Miwa Fujii <[email protected]> APNIC, Senior Advisor Internet Development 25th April 2014 APEC TEL49 Yangzhou, China Issue Date: [25/04/2014] Revision: [3] Overview • Growth path of the Internet – Asia Pacific region • Evolution of mobile networks • IPv6 deployment in mobile networks: Case study • IPv6 deployment status update • IPv6 in mobile networks: way forward 2 Growth path of the Internet The next wave of Internet growth • The Internet has experienced phenomenal growth in the last 20 years – 16 million users in 1995 and 2.8 billion users in 2013 • And the Internet is still growing: Research indicates that by 2017, there will be about 3.6 billion Internet users – Over 40% of the world’s projected population (7.6 billion) • The next wave of Internet growth will have a much larger impact on the fundamental nature of the Internet – It is coming from mobile networks http://www.allaboutmarketresearch.com/internet.htm 4 Internet development in AP region: Internet users 100.00 Internet Users (per 100 inhabitants) New Zealand, 89.51 90.00 Canada, 86.77 Korea, 84.10 Australia, 82.35 80.00 United States, 81.03 Japan, 79.05 Chinese Taipei, 75.99 Singapore, 74.18 70.00 Hong Kong, China, 72.80 Malaysia, 65.80 Chile, 61.42 60.00 Brunei Darussalam, 60.27 Russia, 53.27 50.00 China, 42.30 Viet Nam, 39.49 40.00 Mexico, 38.42 Peru, 38.20 The Philippines, 36.24 30.00 Thailand, 26.50 20.00 Indonesia, 15.36 10.00 Papua New Guinea, 2.30 0.00 2005 2006 2007 2008 2009 2010 2011 2012 http://statistics.apec.org/ 5 Internet
    [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]
  • Service (SRV) Records
    Service (SRV) Records You deploy multiple DNS SRV records in different locations on your enterprise DNS structure. Understand which records you should provision on which name servers. Review examples of SRV records to ensure a successful deployment. • Deploy SRV Records, page 1 • SRV Records, page 4 Deploy SRV Records The client queries name servers for records in the services domain. The services domain is determined as described in How the Client Discovers Available Services. You must deploy SRV records in each DNS zone for those service domains if your organization has multiple subsets of users who use different service domains. Deploy SRV Records in a Separate Domain Structure In a separate name design there are two domains, an internal domain and an external domain. The client queries for SRV records in the services domain. The internal name server must serve records for the services domain. However in a separate name design, a zone for the services domain might not exist on the internal name server. If the services domain is not currently served by the internal name server, you can: • Deploy records within an internal zone for the services domain. • Deploy records within a pinpoint subdomain zone on the internal name server. Use an Internal Zone for a Services Domain If you do not already have a zone for the services domain on the internal name server, you can create one. This method makes the internal name server authoritative for the services domain. Because it is authoritative, the internal name server does not forward queries to any other name server.
    [Show full text]
  • IGF 2016 Best Practice Forum on Ipv6 'Understanding the Commercial And
    Fall 08 IGF 2016 Best Practice Forum on IPv6 ‘Understanding the commercial and economic incentives behind a successful IPv6 deployment’ Editor Wim Degezelle January 2017 IGF 2016 Best Practice Forum on IPv6 ‘Understanding the commercial and economic incentives behind a successful IPv6 deployment’ Table of contents Table of contents ......................................................................................................................................... 2 Executive Summary ................................................................................................................................... 3 Glossary of Terms ....................................................................................................................................... 5 1. Introduction & Background ................................................................................................................ 7 1.1. About the IGF & BPFs ..................................................................................................................................... 7 1.2. Scope and Goal of the 2016 BPF ................................................................................................................. 7 2. Why deploy IPv6? ................................................................................................................................ 10 2.1. The Internet Protocol version 6 (IPv6) ..................................................................................................... 10 2.2. Why Adopt IPv6?
    [Show full text]
  • Ipv6 Deployment – Ipv4 Lifetime Exhaustion Sooner Than Expected?
    IPv6 Deployment – IPv4 lifetime Exhaustion sooner than expected? Tony Hain Cisco Systems - Technical Leader IPv6 Forum Fellow [email protected] Session Number Presentation_ID © 2003 Cisco Systems, Inc. All rights reserved. 1 Distribution of IPv4 addresses by /8 Central 93 ARIN 23 RIPE NCC 19 APNIC 16 LACNIC 4 AfriNIC 1 Defined 4 Multicast 16 Experimental 16 IANA - Pool 25% remaining 64 0 102030405060708090100 IANA allocated 22 /8’s between Jan. 1, 2004 and Jul. 1, 2005 Presentation_ID © 2003 Cisco Systems, Inc. All rights reserved. 222 Allocation of IPv4 /8 blocks per month by IANA 7 6 5 IANA Allocations to RIR's 4 Raw /8 allocations per month 3 2 1 Presentation_ID 0 Jan-95 Jan-96 Jan-97 © 2003 Cisco Systems, Inc. All rights reserved.Jan-98 Jan-99 Jan-00 Jan-01 Jan-02 Jan-03 Jan-04 Jan-05 Jan-06 Jan-07 Jan-08 Jan-09 333 Allocation of IPv4 /8 blocks per month by IANA IANA Allocations to RIR's Sliding-window 6 month geo-mean scale normalized to current 1 per month 2.50000 2.00000 1.50000 1.00000 0.50000 0.00000 Sep-95 Sep-96 Sep-97 Sep-98 Sep-99 Sep-00 Sep-01 Sep-02 Sep-03 Sep-04 Sep-05 Sep-06 Presentation_ID © 2003 Cisco Systems, Inc. All rights reserved. 444 Allocation of IPv4 /8 blocks per month by IANA 2.75 3 2.5 2.25 IANA Allocations to RIR's 1.75 2 Sliding-window 12 month average 1.5 1.25 0.75 1 0.5 0.25 0 Presentation_ID Jan-95 Jan-96 Jan-97 Jan-98 © 2003 Cisco Systems, Inc.
    [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]