DOCSLIB.ORG

Ipv6 in the Context of TR-101

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Ipv6 in the Context of TR-101 Technical Report TR-177 IPv6 in the context of TR-101 Issue: 1 Corrigendum 1 Issue Date: November 2017 © The Broadband Forum. All rights reserved. IPv6 in the context of TR-101 TR-177 1 Corrigendum 1 Notice The Broadband Forum is a non-profit corporation organized to create guidelines for broadband network system development and deployment. This Technical Report has been approved by members of the Forum. This Technical Report is subject to change. This Technical Report is copyrighted by the Broadband Forum, and all rights are reserved. Portions of this Technical Report may be copyrighted by Broadband Forum members. Intellectual Property Recipients of this Technical Report are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of this Technical Report, or use of any software code normatively referenced in this Technical Report, and to provide supporting documentation. Terms of Use 1. License Broadband Forum hereby grants you the right, without charge, on a perpetual, non-exclusive and worldwide basis, to utilize the Technical Report for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, products complying with the Technical Report, in all cases subject to the conditions set forth in this notice and any relevant patent and other intellectual property rights of third parties (which may include members of Broadband Forum). This license grant does not include the right to sublicense, modify or create derivative works based upon the Technical Report except to the extent this Technical Report includes text implementable in computer code, in which case your right under this License to create and modify derivative works is limited to modifying and creating derivative works of such code. For the avoidance of doubt, except as qualified by the preceding sentence, products implementing this Technical Report are not deemed to be derivative works of the Technical Report. 2. NO WARRANTIES THIS TECHNICAL REPORT IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT IS EXPRESSLY DISCLAIMED. ANY USE OF THIS TECHNICAL REPORT SHALL BE MADE ENTIRELY AT THE IMPLEMENTER'S OWN RISK, AND NEITHER THE BROADBAND FORUM, NOR ANY OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY OR INDIRECTLY, ARISING FROM THE USE OF THIS TECHNICAL REPORT. 3. THIRD PARTY RIGHTS Without limiting the generality of Section 2 above, BROADBAND FORUM ASSUMES NO RESPONSIBILITY TO COMPILE, CONFIRM, UPDATE OR MAKE PUBLIC ANY THIRD PARTY ASSERTIONS OF PATENT OR OTHER INTELLECTUAL PROPERTY RIGHTS THAT MIGHT NOW OR IN THE FUTURE BE INFRINGED BY AN IMPLEMENTATION OF THE TECHNICAL REPORT IN ITS CURRENT, OR IN ANY FUTURE FORM. IF ANY November 2017 © The Broadband Forum. All rights reserved 2 of 50 IPv6 in the context of TR-101 TR-177 1 Corrigendum 1 SUCH RIGHTS ARE DESCRIBED ON THE TECHNICAL REPORT, BROADBAND FORUM TAKES NO POSITION AS TO THE VALIDITY OR INVALIDITY OF SUCH ASSERTIONS, OR THAT ALL SUCH ASSERTIONS THAT HAVE OR MAY BE MADE ARE SO LISTED. November 2017 © The Broadband Forum. All rights reserved 3 of 50 IPv6 in the context of TR-101 TR-177 1 Corrigendum 1 Issue History Issue Approval Publishing Issue Editor Changes Number Date Date 1 November Sven Ooghe, Alcatel- Final Ballot Candidate; 2010 Lucent updated TR-156 Bala’zs Varga, Ericsson reference and removed Wojciech Dec, Cisco reference to WT-146 Systems 1 27 November 12 January Dave Allan, Ericsson Referencing error Corrigendum 2017 2018 corrected, I-D 1 references updated Comments or questions about this Broadband Forum Technical Report should be directed to [email protected]. Editor David Allan Ericsson Architecture and Migration David Allan Ericsson WA Directors David Thorne BT November 2017 © The Broadband Forum. All rights reserved 4 of 50 IPv6 in the context of TR-101 TR-177 1 Corrigendum 1 Table of Contents 1 PURPOSE AND SCOPE ...................................................................................................... 8 1.1 PURPOSE .......................................................................................................................... 8 1.2 SCOPE .............................................................................................................................. 8 2 REFERENCES AND TERMINOLOGY .......................................................................... 11 2.1 CONVENTIONS ............................................................................................................... 11 2.2 REFERENCES .................................................................................................................. 11 2.3 DEFINITIONS .................................................................................................................. 12 2.4 ABBREVIATIONS ............................................................................................................ 13 2.5 RELATION TO OTHER DOCUMENTS ................................................................................. 14 3 TECHNICAL REPORT IMPACT ................................................................................... 15 3.1 ENERGY EFFICIENCY ...................................................................................................... 15 3.2 IPV6 ............................................................................................................................... 15 3.3 SECURITY ....................................................................................................................... 15 4 FUNDAMENTAL ARCHITECTURAL AND TOPOLOGICAL ASPECTS............... 16 4.1 IPV6 DEPLOYMENT MODELS ........................................................................................... 16 4.2 IPV6 ADDRESSING RECOMMENDATIONS ......................................................................... 16 4.2.1 IPv6 Prefix Delegation (DHCPv6-PD) .................................................................... 17 4.2.2 DHCPv6 address assignment ................................................................................... 18 4.2.3 StateLess Address AutoConfiguration (SLAAC) ....................................................... 19 4.2.4 Mixed deployment of bridged and routed RGs ......................................................... 20 4.3 RESIDENTIAL GATEWAY REQUIREMENTS ...................................................................... 21 4.4 THE U REFERENCE POINT ............................................................................................... 21 4.5 ACCESS NODE ................................................................................................................ 23 4.6 BROADBAND NETWORK GATEWAY ............................................................................... 23 4.7 IPV6 MULTICAST SUPPORT ............................................................................................ 23 4.8 IPV6 SECURITY CONSIDERATIONS .................................................................................. 25 4.8.1 Link-local address handling ..................................................................................... 25 5 ACCESS NODE REQUIREMENTS ................................................................................ 26 5.1 VLANS .......................................................................................................................... 26 5.2 ACCESS NODE FORWARDING MECHANISMS .................................................................. 27 5.3 QOS ............................................................................................................................... 27 5.3.1 Traffic Classification and Class of Service Based Forwarding................................ 27 5.4 IPV6 INTERWORKING FUNCTIONS .................................................................................. 27 5.4.1 IPv6oE over ATM (U reference point) ...................................................................... 27 5.4.2 PPPoA ....................................................................................................................... 27 5.5 L2 SECURITY CONSIDERATIONS ..................................................................................... 27 5.6 ADDITIONAL IWF FOR IPV6 OVER ETHERNET-BASED ACCESS IN N:1 VLANS .............. 27 5.6.1 DHCPv6 Processing ................................................................................................. 27 5.6.2 Neighbor Discovery Processing ............................................................................... 29 5.6.3 IPv6 Spoofing Prevention ......................................................................................... 32 5.7 ACCESS LOOP IDENTIFICATION AND CHARACTERIZATION ............................................. 32 November 2017 © The Broadband Forum. All rights reserved 5 of 50 IPv6 in the context of TR-101 TR-177 1 Corrigendum 1 5.7.1 Access Loop Identification Configuration and Syntax.............................................. 32 5.7.2 Access Loop Characteristics ..................................................................................... 32 5.7.3 Signaling the Access Loop Encapsulation ................................................................ 33 5.7.4 BNG to RADIUS Signaling of
Load more

Recommended publications
  • SIP Software for Avaya 1200 Series IP Deskphones-Administration
    SIP Software for Avaya 1200 Series IP Deskphones-Administration Release 4.4 NN43170-601 Issue 06.05 Standard July 2015 © 2015 Avaya Inc. list of Heritage Nortel Products located at http://support.avaya.com/ All Rights Reserved. LicenseInfo under the link “Heritage Nortel Products” or such successor site as designated by Avaya. For Heritage Nortel Notice Software, Avaya grants You a license to use Heritage Nortel While reasonable efforts have been made to ensure that the Software provided hereunder solely to the extent of the authorized information in this document is complete and accurate at the time of activation or authorized usage level, solely for the purpose specified printing, Avaya assumes no liability for any errors. Avaya reserves in the Documentation, and solely as embedded in, for execution on, the right to make changes and corrections to the information in this or for communication with Avaya equipment. Charges for Heritage document without the obligation to notify any person or organization Nortel Software may be based on extent of activation or use of such changes. authorized as specified in an order or invoice. Documentation disclaimer Copyright “Documentation” means information published by Avaya in varying Except where expressly stated otherwise, no use should be made of mediums which may include product information, operating materials on this site, the Documentation, Software, Hosted Service, instructions and performance specifications that Avaya may generally or hardware provided by Avaya. All content on this site, the make available to users of its products and Hosted Services. documentation, Hosted Service, and the product provided by Avaya Documentation does not include marketing materials.
    [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]
  • 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]
  • Using PANA for Mobile Ipv6 Bootstrapping Julien Bournelle, Jean-Michel Combes, Maryline Laurent, Sondes Larafa
    Using PANA for mobile IPv6 bootstrapping Julien Bournelle, Jean-Michel Combes, Maryline Laurent, Sondes Larafa To cite this version: Julien Bournelle, Jean-Michel Combes, Maryline Laurent, Sondes Larafa. Using PANA for mobile IPv6 bootstrapping. NETWORKING 2007 : 6th international IFIP-TC6 networking conference on ad hoc and sensor networks, wireless networks, next generation Internet, May 2007, Atlanta, United States. pp.345 - 355, 10.1007/978-3-540-72606-7_30. hal-01328113 HAL Id: hal-01328113 https://hal.archives-ouvertes.fr/hal-01328113 Submitted on 7 Jun 2016 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Using PANA for Mobile IPv6 Bootstrapping Julien Bournelle1, Jean-Michel Combes2, Maryline Laurent-Maknavicius1, Sondes Larafa1 1 GET/INT, 9 rue Charles Fourier, 91011 Evry, France 2 France Telecom R&D, 38/40 rue du General Leclerc, 92784 Issy-Les-Moulineaux, France Abstract One of the current challenge of the Mo- 2 Mobile IPv6 Overview bile IPv6 Working Group at the IETF is to dynami- As it stands in [1], an IPv6 Mobile Node (MN) is cally assign to a Mobile Node its Home Agent, Home uniquely identi¯ed by its Home Address (HoA), and Address and to setup necessary security associations.
    [Show full text]
  • Spirent AION
    DATASHEET Spirent AION Spirent TestCenter Broadband Access Standard and Advanced Bundles, Carrier • Enhanced Realism—Spirent Ethernet Bundle TestCenter Access test solution Overview emulates real world broadband subscriber behaviors, Triple Play Spirent AION is a flexible delivery platform that enables users to achieve improved services, and failure scenarios deployment and provisioning for all their cloud and network testing needs. It is designed to deliver ultimate flexibility in how Spirent TestCenter platforms are • Improved Testing Capacity— purchased and utilized. accomplish more in less lab space The extended platform combines a wealth of industry-leading test solutions with a with the highest number of emulated flexible licensing architecture to support a wide range of next-generation solution- subscribers and user planes per port based domain applications. and port density AION offers a centralized management hub to help leverage software and hardware • Reduced Test Time—set up tests functionalities across all lab users and locations for a simplified management and quickly and easily to validate decision-making process: system performance in realistic, unstable environments rather than • Flexible purchasing options available via subscription, consumption-based, and perpetual plans, with the ability to license different bandwidth, scale, and protocol bundles. an environment optimized for pure performance • Flexible deployment options offered include cloud-delivery, on-prem, and laptop-hosted licensing services. • Detailed Analysis—Data
    [Show full text]
  • LANCOM Datasheet
    LANCOM Operating System (LCOS) 10.40 Top performance and efficiency for your SD-WAN A Next-generation SD-WAN – LANCOM High Scalability VPN (HSVPN) greatly improves efficiency as it requires fewer VPN tunnels A A fresh look & feel – WEBconfig has been completely redesigned for an intuitive and modern appearance A Multicast routing – new possibilities with multimedia applications in LANCOM infrastructures DATASHEET LANCOM Operating System General Feature Overview Firewall IPv4/IPv6 Stateful inspection, IP packet filter with port ranges, object-oriented rule definition. IPv4 Masking (NAT/PAT) of TCP, UDP, ICMP, FTP, PPTP, H.323, Net-Meeting, IRC and IPSec; DNS forwarding. Extended port forwarding and N:N mapping. Support for up to 256 contexts with individual IP networks, VLANs and interfaces, bandwidth management, QoS and VLAN prioritization for VoIP and VoWLAN Operating modes LAN protocols ARP, Proxy ARP, IPv4, ICMP, UDP, TCP, TFTP, RIP-1, RIP-2, DHCP, DNS, SNMP, HTTP, HTTPS, SSH, Telnet and SIP, BOOTP, NTP/SNTP, NetBIOS, RADIUS, TACAS+, LANCAPI, VRRP, STP/RSTP, IGMP, IPv6, DHCPv6, SLAAC, MLD, NDP, ICMPv6 WAN protocols (Ethernet) PPPoE, PPTP (PAC or PNS) and Plain Ethernet (with and without DHCP), RIP-1, RIP-2, IPv6CP, 6to4 Tunnel, 6in4 Tunnel, 6rd Tunnel, DHCPv6, SLAAC, L2TPv3 for Ethernet Pseudowires Multiprotocol router IPv4/IPv6 router, NAT/Reverse NAT (IP- masquerading), DHCPv4/DHCPv6 server, DHCPv4/DHCPv6 client, DHCPv4/DHCPv6 relay server, DNS server, PPPoE client / Multi-PPPoE, ML-PPP, PPTP (PAC and PNS), NetBIOS proxy, DynDNS client,
    [Show full text]
  • Technical Security Guideline on Deploying Ipv6
    Draft Recommendation ITU-T X.1037 (X.ipv6-secguide) Technical security guideline on deploying IPv6 Summary The Internet protocol version 6 (IPv6) is intended to provide many built-in benefits such as large address space, mobility, and quality of service (QoS), because it is a new protocol and operates in some different ways than Internet protocol version 4 (IPv4), both foreseeable and unforeseeable security issues will arise. Many new functions or requirements of IPv6, i.e., automatic configuration of interfaces, mandatory Internet protocol security (IPSec), mandatory multicast, multiple Internet protocol (IP) addresses and many new rules for routing, can be abused for compromising computer systems or networks. Considering the above circumstances, Recommendation ITU-T X.1037 provides a set of technical security guides for telecommunication organizations to implement and deploy IPv6 environment. The content of this Recommendation focuses on how to securely deploy network facilities for telecommunication organizations and how to ensure security operations for the IPv6 environment. Keywords ???? - 2 - CONTENTS 1 Scope ............................................................................................................................. 3 2 References ..................................................................................................................... 3 3 Definitions .................................................................................................................... 4 3.1 Terms defined elsewhere ...............................................................................
    [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]
  • 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]
  • Internet Address Space: Economic Considerations in the Management of Ipv4”, OECD Digital Economy Papers, No
    Please cite this paper as: OECD (2008-06-18), “Internet Address Space: Economic Considerations in the Management of IPv4”, OECD Digital Economy Papers, No. 145, OECD Publishing, Paris. http://dx.doi.org/10.1787/230461618475 OECD Digital Economy Papers No. 145 Internet Address Space ECONOMIC CONSIDERATIONS IN THE MANAGEMENT OF IPV4 OECD DSTI/ICCP(2007)20/FINAL FOREWORD The report provides an analysis of economic considerations associated with the transition from IPv4 to IPv6. It provides background analysis supporting the forthcoming ICCP-organised Ministerial-level meeting on ―The Future of the Internet Economy‖, to take place in Seoul, Korea on 17-18 June 2008. This report was prepared by Ms. Karine Perset of the OECD‘s Directorate for Science Technology and Industry. It was declassified by the ICCP Committee at its 54th Session on 5-7 March 2008. It is published under the responsibility of the Secretary-General of the OECD. This paper has greatly benefited from the expert input of Geoff Huston from APNIC, David Conrad from the IANA, Patrick Grossetête from CISCO Systems, Bill Woodcock from Packet Clearing House, Marcelo Bagnulo Braun from the University of Madrid, Alain Durand from Comcast, and Vincent Bataille from Mulot Déclic, although interpretations, unless otherwise stated, are those of the author. 2 DSTI/ICCP(2007)20/FINAL TABLE OF CONTENTS FOREWORD ................................................................................................................................................... 2 MAIN POINTS ..............................................................................................................................................
    [Show full text]
  • 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 - 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.
    [Show full text]