DOCSLIB.ORG

Ipv6 Intranet Intranet/Internet

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Ipv6 Intranet Intranet/Internet How to Securely Operate an IPv6 Network BRKSPG-2603 Eric Vyncke, [email protected] @evyncke Abstract • This intermediate session describes how an IPv6 network can be securely operated. • The session explains how the management, control and data planes can be secured. • It also covers topics such as forensic, telemetry and lawful intercept. • The content is mainly geared to Service Providers but enterprises may also find it useful. • It is targeted to security and network architects with operational background. • There is also enterprise versions of this session BRKSEC-2003 (on-line only) / BRKSEC- 3200 which is more protocol oriented than operational. Beware that there is 30% overlap between BRKSEC-3200 and BRKSPG-2603. 3 Roadmap For IPv6 Security Sessions On www.ciscolive.com BRKSEC-2003 IPv6 Security Threats and Mitigations BRKSPG-2603 How to Securely Operate an IPv6 Network BRKSEC-3003 BRKSEC-3200 Operation Advanced IPv6 Security in Advanced IPv6 Security in the LAN the Core Architecture and design BRKSEC-3036 Advanced IPsec LTRSEC-3001 Advanced - IOS Dual-stack designs with FlexVPN FlexVPN Lab Products 4 IETF OPSEC Working Group 5 For Your Reference For Reference Slides • There are more slides in the hand-outs than presented during the class • Those slides are mainly for reference and are indicated by the book icon on the top right corner (as on this slide) • Some slides have also a call-out to another session (see below) BRKSEC- 3200 6 7 Agenda • Management Plane • Control Plane • Routing Information • Neighbor Discovery • Control Plane Protection • Data Plane • Anti-spoofing • Access Control List • Tunnel loops • Telemetry • Forensic • Lawful Intercept • Summary 8 Management Plane 9 9 Management over IPv6 • SSH, syslog, SNMP, NetFlow all work over IPv6 • Dual-stack management plane • More resilient: works even if one IP version is down • More exposed: can be attacked over IPv4 and IPv6 • RADIUS over IPv6 is recent (IOS 15.2(1)T, IOS-XE rls 3.2S) • But, IPv6 RADIUS attributes can be transported over IPv4 • As usual, infrastructure ACL is your friend (more to come) as well as out-of- band management 10 For Your Reference IPv6 ACL to Protect VTY ipv6 access-list VTY permit ipv6 2001:db8:0:1::/64 any line vty 0 4 ipv6 access-class VTY in • Must be done before enabling IPv6 on any interface • Beware there is no equivalent for HTTP => use ACL • The ‘management-interface’ command of ‘control-plane host’ is IPv4 only => use ACL • In IOS-XR, the command is ‘access-class VTY ingress’, the IPv4 and IPv6 ACL must have the same name 11 Control Plane: Routing Protocols 12 Preventing IPv6 Routing Attacks Protocol Authentication • BGP, ISIS, EIGRP no change: • An MD5 authentication of the routing update • OSPFv3 has changed and pulled MD5 authentication from the protocol and instead rely on transport mode IPsec (for authentication and confidentiality) • But see RFC 6506 7166 (not yet widely implemented) • IPv6 routing attack best practices • Use traditional authentication mechanisms on BGP and IS-IS • Use IPsec to secure protocols such as OSPFv3 13 For Your Reference OSPF or EIGRP Authentication interface Ethernet0/0 ipv6 ospf 1 area 0 ipv6 ospf authentication ipsec spi 500 md5 1234567890ABCDEF1234567890ABCDEF interface Ethernet0/0 ipv6 authentication mode eigrp 100 md5 ipv6 authentication key-chain eigrp 100 MYCHAIN key chain MYCHAIN key 1 key-string 1234567890ABCDEF1234567890ABCDEF accept-lifetime local 12:00:00 Dec 31 2006 12:00:00 Jan 1 2008 send-lifetime local 00:00:00 Jan 1 2007 23:59:59 Dec 31 2007 No crypto maps, no ISAKMP: transport mode with static session keys 14 For Your Reference BGP Route Filters • Pretty obvious for customer links • For peering, a relaxed one ipv6 prefix-list RELAX deny 3ffe::/16 le 128 ipv6 prefix-list RELAX deny 2001:db8::/32 le 128 ipv6 prefix-list RELAX permit 2001::/32 ipv6 prefix-list RELAX deny 2001::/32 le 128 ipv6 prefix-list RELAX permit 2002::/16 ipv6 prefix-list RELAX deny 2002::/16 le 128 ipv6 prefix-list RELAX deny 0000::/8 le 128 ipv6 prefix-list RELAX deny fe00::/9 le 128 ipv6 prefix-list RELAX deny ff00::/8 le 128 ipv6 prefix-list RELAX permit 2000::/3 le 48 ipv6 prefix-list RELAX deny 0::/0 le 128 Source: http://www.space.net/~gert/RIPE/ipv6-filters.html 15 Link-Local Addresses vs. Global Addresses • Link-Local addresses, fe80::/10, (LLA) are isolated • Cannot reach outside of the link • Cannot be reached from outside of the link • Could be used on the infrastructure interfaces • Routing protocols (inc BGP) work with LLA • Benefit: no remote attack against your infrastructure: implicit infrastructure ACL • Note: need to provision loopback for ICMP generation (traceroute and PMTUD) • See also: RFC 7404 • LLA can be configured statically (not the EUI-64 default) to avoid changing neighbor statements when changing MAC interface FastEthernet 0/0 ipv6 address fe80::1/64 link-local neighbor fe80::2%FastEthernet0/0 16 Control Plane: Neighbor Discovery 17 Scanning Made Bad for CPU Remote Neighbor Cache Exhaustion RFC 6583 • Potential router CPU/memory attacks if aggressive scanning • Router will do Neighbor Discovery... And waste CPU and memory • Local router DoS with NS/RS/… NS: 2001:db8::3 NS: 2001:db8::2 NS: 2001:db8::1 NS: 2001:db8::3 NS: 2001:db8::2 NS: 2001:db8::1 NS: 2001:db8::3 NS: 2001:db8::2 NS: 2001:db8::1 2001:db8::/64 18 Mitigating Remote Neighbor Cache Exhaustion • Built-in rate limiter with options to tune it BRKSEC- • Since 15.1(3)T: ipv6 nd cache interface-limit 3003 • Or IOS-XE 2.6: ipv6 nd resolution data limit • Destination-guard is part of First Hop Security phase 3 • Priority given to refresh existing entries vs. discovering new ones (RFC 6583) • Using a /64 on point-to-point links => a lot of addresses to scan! • Using /127 could help (RFC 6164) • Internet edge/presence: a target of choice • Ingress ACL permitting traffic to specific statically configured (virtual) IPv6 addresses only (see next slide) • Using infrastructure ACL prevents this scanning • iACL: edge ACL denying packets addressed to your routers http://www.insinuator.net/2013/03/ipv6-neighbor-cache-exhaustion-attacks-risk-assessment-mitigation-strategies-part-1 19 Simple Fix for Remote Neighbor Cache Exhaustion • Ingress ACL allowing only valid destination and dropping the rest • NDP cache & process are safe • Requires DHCP or static configuration of hosts NS: 2001:db8::1 NA: 2001:db8::1 2001:db8::/64 20 ARP Spoofing is now NDP Spoofing: Threats • ARP is replaced by Neighbor Discovery Protocol • Nothing authenticated • Static entries overwritten by dynamic ones • Stateless Address Autoconfiguration • rogue RA (malicious or not) • All nodes badly configured • DoS • Traffic interception (Man In the Middle Attack) • Attack tools exist (from THC – The Hacker Choice) • Parasit6 • Fakerouter6 • ... 21 ARP Spoofing is now NDP Spoofing: BRKSEC- Mitigation 3003 • GOOD NEWS: dynamic ARP inspection for IPv6 is available • First phase (Port ACL & RA Guard) available since Summer 2010 • Second phase (NDP & DHCP snooping) starting to be available since Summer 2011 • http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-first_hop_security.html • (Kind of ) GOOD NEWS: Secure Neighbor Discovery • SeND = NDP + crypto • IOS 12.4(24)T • But not in Windows Vista, 2008 and 7, Mac OS/X, iOS, Android • Crypto means slower... • Other GOOD NEWS: • Private VLAN works with IPv6 • Port security works with IPv6 • IEEE 801.X works with IPv6 (except downloadable ACL but it is coming) 22 Mitigating Rogue RA: Host Isolation • Prevent Node-Node Layer-2 RA communication by using: Promiscuous Port • Private VLANs (PVLAN) where nodes (isolated port) can only contact the official router (promiscuous port) RA • WLAN in ‘AP Isolation Mode’ • 1 VLAN per host (SP access network with Broadband Network Gateway) Isolated Port • Link-local multicast (RA, DHCP request, RA etc) sent only to the local official router: no R harm A • Can break DAD RA • Advertise the SLAAC prefix without the on- link bit to force router to do ‘proxy-ND’ 23 First Hop Security: RAguard since 2010 RFC 6105 RA • Port ACL blocks all ICMPv6 RA from hosts interface FastEthernet0/2 ROUTER ipv6 traffic-filter ACCESS_PORT in Device-role access-group mode prefer port RA • RA-guard lite (12.2(33)SXI4 & 12.2(54)SG ): also HOST dropping all RA received on this port Device-role interface FastEthernet0/2 Can also enforce ipv6 nd raguard MTU, prefix, ... In access-group mode prefer port RA RA RA • RA-guard (12.2(50)SY, 15.0(2)SE) ipv6 nd raguard policy HOST device-role host ipv6 nd raguard policy ROUTER device-role router RA ipv6 nd raguard attach-policy HOST vlan 100 interface FastEthernet0/0 ipv6 nd raguard attach-policy ROUTER 24 For Your IPv6 First Hop Security Platform Support Reference Wireless LAN Nexus Catalyst 6500 Catalyst Catalyst ASR1000 Catalyst Controller 7600 Router 3k/5k/6k/7k/ Feature/Platform Series 4500 Series 2K/3K Series Router 3850 (Flex 7500, 5508, 2500, 9k WISM-2) RA Guard 15.0(1)SY 15.1(2)SG 15.0.(2)SE 15.2(4)S 15.0(1)EX 7.2 NX-OS 7.4 NX-OS 7.4 IPv6 Snooping 15.0(1)SY1 15.1(2)SG 15.0.(2)SE XE 3.9.0S 15.2(4)S 15.0(1)EX 7.2 NX-OS 7.4 DHCPv6 Guard 15.2(1)SY 15.1(2)SG 15.0.(2)SE 15.2(4)S 15.0(1)EX 7.2 Source/Prefix NX-OS 7.4 15.2(1)SY 15.2(1)E 15.0.(2)SE2 XE 3.9.0S 15.3(1)S 7.2 Guard NX-OS 7.4 Destination Guard 15.2(1)SY 15.1(2)SG 15.2(1)E XE 3.9.0S 15.2(4)S RA Throttler 15.2(1)SY 15.2(1)E 15.2(1)E 15.0(1)EX 7.2 ND Multicast 15.2(1)SY 15.1(2)SG 15.2(1)E XE 3.9.0S 15.0(1)EX 7.2 Suppress Note 1: IPv6 Snooping support in 15.0(1)SY does not extend to DHCP or data packets; only ND packets are snooped Note 2: Only IPv6 Source Guard is supported in 15.0(2)SE; no support for Prefix Guard in that release Available Now Not Available Roadmap 25 CPE to CPE Communication IPv4 vs.
Load more

Recommended publications
  • A Review and Qualitative Analysis of Ipv6 and Ipv4 Interoperability Technologies
    A Review and Qualitative Analysis of IPv6 and IPv4 Interoperability Technologies Antti Maula Helsinki University of Technology [email protected] Abstract structured as follows: section 2 contains descriptions of ex- isting solutions and their main technical features. Section 3 Deployment of IPv6 has been delayed even though the stan- presents some discussion about the state of the technologies dard has existed for over ten years and the number of free and section 4 presents the required future work and the final IPv4 addresses is decreasing fast. Some obstacles in deploy- conclusions are drawn in section 5. ment are economic but also technical issues remain. The Internet cannot be converted to IPv6 overnight, thus a transi- tion period is required during which both protocols co-exist 2 Related technologies and work together seamlessly. There is a vast amount of in- teroperability technologies available and this paper presents This section presents the existing IPv6 and IPv4 interop- proposed solutions to operate IPv6-only network segments erability technologies and their technical details. Interop- in cooperation with IPv4-only network segments. erability technologies include techniques which allow use of isolated IPv6 subnets in mostly IPv4 based Internet and KEYWORDS: IPv6, IPv4, interoperability, technology re- all of these technologies are intended to be used only dur- view, qualitative analysis ing the transition period and they should automatically stop working when underlying network infrastructure has imple- mented full IPv6 support. Some of the methods presented 1 Introduction here are implemented only by software while others re- quire additional hardware to function. These two models IP protocol version 4 (IPv4), which is currently used in most are namely “End-host” and “Middlebox” architectures, in parts of the internet, is becoming outdated.
    [Show full text]
  • Routing Loop Attacks Using Ipv6 Tunnels
    Routing Loop Attacks using IPv6 Tunnels Gabi Nakibly Michael Arov National EW Research & Simulation Center Rafael – Advanced Defense Systems Haifa, Israel {gabin,marov}@rafael.co.il Abstract—IPv6 is the future network layer protocol for A tunnel in which the end points’ routing tables need the Internet. Since it is not compatible with its prede- to be explicitly configured is called a configured tunnel. cessor, some interoperability mechanisms were designed. Tunnels of this type do not scale well, since every end An important category of these mechanisms is automatic tunnels, which enable IPv6 communication over an IPv4 point must be reconfigured as peers join or leave the tun- network without prior configuration. This category includes nel. To alleviate this scalability problem, another type of ISATAP, 6to4 and Teredo. We present a novel class of tunnels was introduced – automatic tunnels. In automatic attacks that exploit vulnerabilities in these tunnels. These tunnels the egress entity’s IPv4 address is computationally attacks take advantage of inconsistencies between a tunnel’s derived from the destination IPv6 address. This feature overlay IPv6 routing state and the native IPv6 routing state. The attacks form routing loops which can be abused as a eliminates the need to keep an explicit routing table at vehicle for traffic amplification to facilitate DoS attacks. the tunnel’s end points. In particular, the end points do We exhibit five attacks of this class. One of the presented not have to be updated as peers join and leave the tunnel. attacks can DoS a Teredo server using a single packet. The In fact, the end points of an automatic tunnel do not exploited vulnerabilities are embedded in the design of the know which other end points are currently part of the tunnels; hence any implementation of these tunnels may be vulnerable.
    [Show full text]
  • Allied Telesis Solutions Tested Solution:Ipv6 Transition Technologies
    Allied Telesis Solutions IPv6 Transition Technologies Tested Solution: IPv6 Transition Technologies Moving a network from IPv4 addressing to IPv6 addressing cannot be performed in a single step. The transition necessarily proceeds in stages, with islands of IPv6 developing within the IPv4 network, and gradually growing until they cover the whole network. During this transition process, the islands of IPv6 need to be able to communicate with each other across the IPv4 network. Additionally, it is desirable to be able to transition some network functions across to IPv6 while the majority of the network is still using IPv4. Allied Telesis provides robust solutions for IPv4-to-IPv6 network transitioning, using IPv6 tunneling and dual IPv4/IPv6 network management. The Allied Telesis IPv6 transition technologies integrate seamlessly with the complementary facilities provided within Microsoft server and workstation operating systems. The Allied Telesis IPv6 transition solution will be presented here by a detailed description of an example IPv4/IPv6 hybrid network, consisting of Allied Telesis switches and servers and workstations running various versions of Microsoft Windows Network topology The example network used in this example consists of two sections of IPv4 network, and a section of pure IPv6 network. IPv4 133.27.65.34 v4 router 139.72.129.56/24 Vista 136.34.23.11/24 133.27.65.2 6to4 host/router x600 6to4 relay XP 2002:8B48:8139::10/64 136.34.23.10/24 139.72.129.57/24 2002:8B48:8139:1001::12/64 6to4 host/router IPv6 router Server 2008 2002:8b48:8139:1003::12/642002:8b48:8139:1002::12/64 ISATAP router 2002:8b48:8139:1003::10/64 192.168.2.254 192.168.2.54 IPv6 v4 router Server 2008 192.168.3.254 2002:8b48:8139:1002::10/64 192.168.3.11 IPv4 8000S ISATAP The workstations in the upper IPv4 network are able to communicate using both IPv4 and IPv6.
    [Show full text]
  • Nist Sp 800-77 Rev. 1 Guide to Ipsec Vpns
    NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel Karen Scarfone Paul Wouters This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 C O M P U T E R S E C U R I T Y NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel* Computer Security Division Information Technology Laboratory Karen Scarfone Scarfone Cybersecurity Clifton, VA Paul Wouters Red Hat Toronto, ON, Canada *Former employee; all work for this publication was done while at NIST This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 June 2020 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority.
    [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]
  • S5800 Series Ipv6 Service CLI | FS.COM
    FiberstoreOS IPv6 Service Command Line Reference Contents 1 Tunnel Commands...........................................................................................................................4 1.1 interface..............................................................................................................................................................4 1.2 tunnel mode ipv6ip............................................................................................................................................ 5 1.3 tunnel source...................................................................................................................................................... 6 1.4 tunnel destination...............................................................................................................................................7 1.5 tunnel ttl............................................................................................................................................................. 7 1.6 tunnel dscp......................................................................................................................................................... 8 1.7 ipv6 mtu............................................................................................................................................................. 9 1.8 show interface tunnel....................................................................................................................................... 10 1.9 show
    [Show full text]
  • Security Vulnerabilities of Ipv6 Tunnels
    Security Vulnerabilities of IPv6 Tunnels This article talks about novel security vulnerabilities of IPv6 tunnels – an important type of migration mechanisms from IPv4 to IPv6 implemented by all major operating systems and routers. The vulnerabilities allow an attacker to form routing loops which can easily produce DoS attacks. I will describe the principles of the attack and then show how to actually implement it. The vulnerabilities were first presented at Usenix W00T ’09 in a paper I co-authored with Michael Arov. IPv6 background IPv6 is the next generation version of the omnipresent Internet Protocol. It was designed to answer the future exhaustion of the IPv4 address pool. IPv4 address space is 32 bits which translates to just above 4 billion addresses. IPv6 address space is 128 bits. This roughly translates to the entire address space of the IPv4 for every square nanometer on planet earth (a square nanometer is about the size of a molecule!). The IPv6 specification has been released almost 13 years ago, however it has seen little adoption so far since the IPv4 address space hasn’t depleted yet. But this is about to change very soon. ISPs in Asia-Pacific are already unable to request new IPv4 addresses for their customers. In other regions of the world IPv4 address pools are expected to drain within a year or so. So IPv6 is definitely here to stay. Migration to IPv6 using tunnels As one might imagine the migration to IPv6 will be very gradual. Some estimate that IPv4 and IPv6 will co-exist on the Internet for decades.
    [Show full text]
  • Ipv6 Transition and Coexistence Ipv6-Only and Ipv4 As-A-Service
    IPv6 Transition and Coexistence IPv6-only and IPv4 as-a-Service APNIC46 September, 2018 Noumea, New Caledonia Jordi Palet ([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
    [Show full text]
  • Ipv4 to Ipv6 Transition Mechanism in a Fixed Environment
    الجمهورية اليمنية Republic of Yemen جامعة صنعاء Sanaꞌa University كلية الهندسة Faculty of Engineering قسم الهندسة الكهربائية Electrical Engineering Department IPv4 to IPv6 transition mechanism in a fixed environment: The case of Yemen Abdulsalam Alkholidi, Sanaꞌa University, Faculty of Engineering [email protected] MENOG16 Istanbul Turkey 1 23-24 March 2016 Agenda: Introduction IPv6 in Yemen: a short history Necessity of transition to IPv6 IPv6 Transition Mechanism (TM): Proposed scenarios - Scenario 1: Dual stack mechanism - Scenario 2: Tunneling mechanism - Scenario 3: Static NAT-PT Mechanism Simulation results and discussion - Delay - Throughput - Jitter and latency Challenges and obstacles Conclusions Introduction -1 IPv6 transition mechanisms have become an important issue for most Internet Service Providers (ISPs) to: - Expand IP address space - Increase Internet usage -> increasing demand for IP addresses - Introduce new services for customers - Use the Smart Home Platform. Action plan for the deployment of IPv6 in Yemen is slowly Transition mechanism in Yemen from IPv4 toward IPv6 needs more time to startup seriously Internet density in this country is considered as among the lowest in the Middle East Introduction 2 - Motivation Explore the present status of internet in Yemen Propose scientific solutions based on series of simulations results Describe step by step of proposed transition scenarios Concentrate on analyzing performance proposed scenarios Discuss and share the transition scenarios with MENOG 16 experts Benefit IPv6 as a bigger address space Transition to IPv6 is not possible that quickly as the installed general network infrastructure is IPv4 based Demand co-existence of them and integration between them for a period of time until the process of migration is complete.
    [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]
  • Arqueología … Y Futurología De Ipv6 1995 - 2018
    Arqueología … y Futurología de IPv6 1995 - 2018 LACNIC 30 Rosario, Argentina Septiembre 2018 Jordi Palet ([email protected]) - 1 Especificación de IPv6 • Internet Protocol, Version 6 (IPv6) Specification - RFC1883 (1995) -> RFC2460 (1998) -> STD86 (RFC8200, 2017) • Cambios relacionados con seguridad: – Deprecation of Type 0 Routing Headers in IPv6 – RFC5095 (2007) – Handling of Overlapping IPv6 Fragments – RFC5722 (2009) – Processing of IPv6 "Atomic" Fragments – RFC6946 (2013) – Implications of Oversized IPv6 Header Chains – RFC7112 (2014) – Generation of IPv6 Atomic Fragments Considered Harmful – RFC8021 (2017) • Privacidad de las direcciones IPv6: – Security and Privacy Considerations for IPv6 Address Generation Mechanisms – RFC7721 (2016) – Network Reconnaissance in IPv6 Networks – RFC7707 (2016) • Cabeceras de extensión: – A Uniform Format for IPv6 Extension Headers – RFC6564 (2012) • Etiqueta de flujo: – IPv6 Flow Label Specification – RFC6437 (2011) – Using the IPv6 Flow Label for Load balancing in Server Farms – RFC7098 (2014) - 2 ICMPv6 • Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification - RFC1885 (1995) -> RFC2463 (1998) -> RFC4443 (2006) • Sin cambios relevantes - 3 ND, SLAAC, DHCPv6 • Neighbor Discovery for IP version 6 (IPv6) - RFC1970 (1996) -> RFC2461 (1998) -> RFC4861 (2007) • Cambio relevante: – SEcure Neighbor Discovery (SEND) – RFC3971 (2005) • IPv6 Stateless Address Autoconfiguration – RFC1971 (1996) -> RFC2462 (1998) -> RFC4862 (2007) • Stateful – Dynamic
    [Show full text]
  • Ipv6-Only Deployment in Broadband and Cellular Networks Ipv4aas (As-A-Service)
    IPv6-only Deployment in Broadband and Cellular Networks IPv4aaS (as-a-Service) LACNIC 32 / LACNOG 2019 October, 2019 Panamá @JordiPalet ([email protected]) - 1 Transition / Co-Existence Techniques • IPv6 has been designed for easing the transition and coexistence with IPv4 • Several strategies have been designed and implemented for coexisting with IPv4 hosts, grouped in three categories: – Dual stack: Simultaneous support for both IPv4 and IPv6 stacks – Tunnels: IPv6 packets encapsulated in IPv4 ones • This has been the commonest choice • Today expect IPv4 packets in IPv6 ones! – Translation: Communication of IPv4-only and IPv6- only. Initially discouraged and only “last resort” (imperfect). Today no other choice! • Expect to use them in combination! - 2 Dual-Stack Approach • When adding IPv6 to a system, do not delete IPv4 – This multi-protocol approach is familiar and well-understood (e.g., for AppleTalk, IPX, etc.) – In the majority of the cases, IPv6 is be bundled with all the OS release, not an extra-cost add-on • Applications (or libraries) choose IP version to use – when initiating, based on DNS response: • if (dest has AAAA record) use IPv6, else use IPv4 – when responding, based on version of initiating packet • This allows indefinite co-existence of IPv4 and IPv6, and gradual app-by-app upgrades to IPv6 usage • A6 record is experimental - 3 Dual-Stack Approach IPv6 IPv6 IPv4 IPv4 Application Application Application Application TCP/UDP TCP/UDP TCP/UDP IPv6 IPv6 IPv4 IPv4 IPv6-only stack Dual-stack (IPv4 & IPv6) IPv4-only
    [Show full text]