Advanced Ipv6
Total Page：16
File Type：pdf, Size：1020Kb
Load more
Recommended publications
-
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. -
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. -
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. -
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 -
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. -
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. -
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. -
Emulation of the IP Core Network for Testing of the Service GPRS Support Node (SGSN) Routing Application
Technical report, IDE0959, November 2009 Emulation of the IP Core Network for Testing of the Service GPRS Support Node (SGSN) Routing Application Master’s Thesis in Computer Network Engineering Hossein Torkaman School of Information Science, Computer and Electrical Engineering Halmstad University Emulation of the IP Core Network for Testing of the Service GPRS Support Node (SGSN) Routing Application Master’s thesis in Computer Network Engineering School of Information Science, Computer and Electrical Engineering Halmstad University Box 823, S-301 18 Halmstad, Sweden November 2009 Description of cover page picture: IP Core Network picture on GPRS Networks. Preface The following report is based on the data and information gathered through literature studies, Ericsson’s Intranet documents and other several GPRS standards published by 3rd Generation Partnership Project (3GPP), observations, emulating different IP core network scenarios, meetings and executed experiments during December 2008 - August 2009 at Ericsson AB Lindholmen. The input martial to this thesis formed primarily by Internet Protocols and Drivers section in Product Development Department Packet Core at Ericsson AB, Göteborg, Sweden with leadership of Gunilla Zachrisson, my supervisor, to whom I should give an immense thank you due to her kind guidance on each phase of project and for her valuable supports on the implementation of improvements. I am also thankful to my manager, Matthew Crockett, who also made me feel welcomed at Ericsson AB Lindholmen. A big thanks is also directed to my supervisor at Halmstad University, Tony Larsson, for pointing me in the right direction and for the feedback regarding the performance of the project. I would also like to use this opportunity to thank Colin Taylor and Daniel Nilsson and all other colleagues at Ericsson, for interrupting their busy schedules in order to provide me with their technical feedback and experience. -
NAT++: Address Sharing in Ipv4 - the Internet Protocol Journal, Volume 13, No.2 - Cisco 10/8/18, 08 03
NAT++: Address Sharing in IPv4 - The Internet Protocol Journal, Volume 13, No.2 - Cisco 10/8/18, 0803 NAT++: Address Sharing in IPv4 - The Internet Protocol Journal, Volume 13, No.2 HOME by Geoff Huston, APNIC ABOUT CISCO In this article I examine the topic that was discussed in a session at the 74th meeting of the PRESS Internet Engineering Task Force (IETF) in March 2009, about Address Sharing (the SHARA BOF) [0], and look at the evolution of Network Address Translation (NAT) architectures in the THE INTERNET PROTOCOL face of the forthcoming depletion of the unallocated IPv4 address pool. JOURNAL Within the next couple of years we will run out of the current supply of IPv4 addresses. As of the ISSUES time of writing this article, the projected date when the Internet Assigned Numbers Authority (IANA) pool will be depleted is August 3, 2011, and the first Regional Internet Registry (RIR) will VOLUME 13, NUMBER 2, JUNE deplete its address pool about March 20, 2012. 2010 Irrespective of the precise date of depletion, the current prediction is that the consumption rate of addresses at the time when the free pool of addresses is exhausted will probably be running at From the Editor some 220 million addresses per year, indicating a deployment rate of some 170–200 million new Address Sharing services per year using IPv4. The implication is that the Internet will exhaust its address pool while operating its growth engines at full speed. Implementing DNSSEC How quickly will IPv6 come to the rescue? Even the most optimistic forecast of IPv6 uptake for Book Review the global Internet is measured in years rather than months following exhaustion, and the more pessimistic forecasts extend into multiple decades. -
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 -
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 -
Internet Deep Dive Webinar Handout Copy
Introduction to IT Networking Featuring Robert Lastinger from Distech Controls Agenda • Internet • Static IP • DHCP • IP Routing • Gateway • Subnet • NAT • DNS and Hosting • External Access: Firewalls, VPNs Internet Internet Layer The Internet layer is responsible for placing data that needs to be transmitted into data packets known as IP datagrams. These will contain the source and destination addresses for the data within. This layer is also responsible for routing the IP datagrams. The main protocols included at Internet layer are IP (Internet Protocol), ICMP (Internet Control Message Protocol), ARP (Address Resolution Protocol), RARP (Reverse Address Resolution Protocol) and IGMP (Internet Group Management Protocol). Terms you will commonly hear that relate to this layer are IPV4 and IPV6. For the purposes of this training we will only be talking about IPV4. IP Addressing 192.168.99.11 192.168.12.1 192.168.12.101 192.168.12.100 192.168.12.2 Network mask: 255.255.255.0 (/24) Default gateway: 192.168.12.1 Notable IP Addresses • Loopback/localhost (127.0.0.0/8) • Private network (10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12) • Network source address (0.0.0.0/8) • Reserved (anything between 224.0.0.0 and 255.255.255.254) • Limited broadcast (255.255.255.255) • Last IP in a subnet ONS-S8 and ONS-NC600 ONS-C1601pi ONS-YX Network ONS-C401i Router/core switch ONS-C2410p ONS-YX Optical fiber ONS-C401i ONS-C401i Ethernet Static IP IPV4 DHCP (Dynamic Host Configuration Protocol) DHCP Lease (Dynamic vs Reserved) Static IP Subnet Gateway DNS ( Domain Name System) DHCP DHCP DHCP – is a client/server protocol that automatically provides an Internet Protocol (IP) host with its IP address and other related configuration information such as the subnet mask and default gateway.