DOCSLIB.ORG

Hitchhiker's Guide to Troubleshooting Ipv6

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Hitchhiker's Guide to Troubleshooting Ipv6 BRKRST-3304 Hitchhiker’s Guide To Troubleshooting IPv6 - Advanced Nicole Wajer, @vlinder_nl Nicole Nicole Wajer Technical Solutions Architect @vlinder_nl BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 3 Cisco Spark Questions? Use Cisco Spark to communicate with the speaker after the session How 1. Find this session in the Cisco Live Mobile App 2. Click “Join the Discussion” 3. Install Spark or go directly to the space 4. Enter messages/questions in the space cs.co/ciscolivebot#BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public This Session…. BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 5 This Session…. BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 6 Don’t Panic Agenda • Neighbor And Router Discovery • Addressing • IPv4 Coexistence And Transition • IPv6-centric Deployments © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public Neighbor Discovery: Solicited Node Multicatscast Solicited node multicast groups: FF02::1:FF00:0000 /104 FF02::1:FF FF02::1:FF 00:0001 00:0002 FF02::1:FFAA:AAAA FF02::1:FFBB:BBBB FF02::1:FFCC:CCCC 2001:db8::0000:0002 2001:db8::0000:0001 BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 9 Nexus7000 not passing IPv6 traffic http://tinyurl.com/mld-on-nexus-7000 • On M1, M2 and M3 modules, you must disable IGMP optimized multicast flooding (OMF) on all VLANs that require IPv6 multicast packet forwarding. • On F2 modules, you must disable IGMP optimized multicast flooding (OMF) on all VLANs that require IPv6 packet forwarding (unicast or multicast). IPv6 neighbor discovery only functions in a VLAN with the OMF feature disabled. no ip igmp snooping optimise-multicast-flood http://www.cisco.com/en/US/docs/switches/datacenter/sw/nx-os/multicast/configuration/guide/b_multicast_chapter_0100.html#concept_4401AA5D7477469E9208FCE766906395 BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 10 Beware the ACL “tightening” ipv6 access-list ingress permit tcp host 2001:db8::1 eq 80 any deny ipv6 any any log permit icmp any any nd-ns implicit permit icmp any any nd-na deny ipv6 any any implicit BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 11 IPv6 ACL Implicit Rules • IPv6 ACLs configure like “extended named” • Matching, SRC, DST, next header • Applying the ACL uses ipv6 traffic-filter command • IPv6 ACLs have multiple implicit rules • Similar to deny ip any any ipv6 access-list IOS • IOS has 3 implicit IPv6 ACL rules permit icmp any any nd-na permit icmp any any nd-ns • NXOS has 5 implicit IPv6 ACL rules deny ipv6 any any • IOS-XE has no implicit IPv6 ACL rules ipv6 access-list NXOS permit icmp any any nd-na permit icmp any any nd-ns interface GigabitEthernet 0/2 permit icmp any any router-advertise ipv6 address 2001:db8:50:31::1/64 permit icmp any any router-solicitation ipv6 traffic-filter BLOCK-BAD in deny ipv6 any any BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 12 NIST guidelines for secure IPv6 deployment; RFC4890 http://csrc.nist.gov/publications/nistpubs/800-119/sp800-119.pdf http://www.ietf.org/rfc/rfc4890.txt See BRKSEC-2003 BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 13 Ducks in a Row • Code paths of requests/replies may differ • Multicast and Unicast processing can differ • Neighbor Solicitation contains Link-Layer address • May populate the cache without explicit request • Beware of defaults BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 14 Neighbor Cache State Machine • Incomplete – Pending address resolution, NS message outstanding • Reachable – Recently used mapping, Can be refreshed by ULP • Stale – Not currently communicating, waiting for next queued packet • Delay –Using stale binding, awaiting (ULP) return traffic • Probe – Sending Unicast NS to node (after Delay timer, 3x1 sec) NS No Entry Incomplete NA time expired Reachable NA ULP send packet Stale Delay Probe BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 15 ReachableTime: How Long Is It ? • BASE_REACHABLE_TIME • Sent in RA or taken from default • Value in milliseconds • Random(0.5 .. 1.5) * BASE_REACHABLE_TIME BASE_REACHABLE_TIME default: 30000 msec • Chosen every few hours or when BASE… changes BASE_REACHABLE_TIME BASE_REACHABLE_TIME RANDOM (0.5x .. 1.5x) 0.5x 1.5x milliseconds ReachableTime BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 16 Neighbor Table Maintenance Active Standby BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 17 Neighbor Table Maintenance Can Burden The CPU Standby Newly active Active BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 18 DC ND Tuning TEST ! BASE_REAC • If FHRP is present or single gateway: increase reachable time HABLE_TIME ipv6 nd reachable-time 600000 ! 10 minutes • Pre-populate and maintain the neighbor table Expiry ipv6 nd cache expire 14400 refresh ipv6 nd na glean • Rate-limit the address resolution traffic Burst size mls rate-limit unicast cef glean 1000 10 • Start with this configuration and adjust depending on the site PPS • Wrong values can impact the neighbor resolution times! BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 19 IOS XR ND implementation details • New neighbor resolution: timeout 10 sec, not 3 sec. Total 3 retries • REACHABLE_TIME = 180000 ms (25% jitter), not 30000 ms (50% jitter) • DELAY is only 5 sec wait, no integration with TCP • Steady state probing (“PROBE”): • MAX_UNICAST_SOLICIT = 5, not 3 • timeout: 60 sec • Configuration to revert behavior to RFC values: RP/0/0/CPU0:ios(config)#int gigabitEthernet 0/1/0/0 RP/0/0/CPU0:ios(config-if)#ipv6 nd nud-conform RP/0/0/CPU0:ios(config-if)#commit BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 20 Ducks in a Row • ND has more states than ARP • Having “STALE” Neighbor Entry is ok! • Even in a connected Nespresso machine • Reachable interval is in milliseconds • Remember when adjusting • Adjust the Reachable timer up BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 21 Anatomy Of A Router Advertisement BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 22 Router Solicitations • Valid Options: Source link-layer address • The link-layer address of the sender, if known. MUST NOT be included if the Source Address is the unspecified address. Otherwise, it SHOULD be included on link layers that have addresses. BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 23 Router Solicitations and Neighbor Cache • If no Source Link Layer Address present • No effect • If Source Link Layer Address present • Installs/updates the entry and puts into “STALE” state • Consider for different ways of propagation of NS vs. RS • Host may get initial connectivity but not after clearing neighbor cache BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 24 Default ACLs and Router Solicitations • None of the platform contain “default permit” for Router Solicitations • Delay with obtaining addresses • Mostly an issue with dynamic clients • Servers are less volatile BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 25 Router Advertisements and Battery Life The model of measurements • Three levels: • Device – level behavior • Network-wide behavior • Traffic on the network • Power consumption ~ F(number of hosts on segment, network volatility) • Two main sources of multicast traffic • IPv6 Neighbor Discovery protocol • Service Advertisements • More information on the power consumption model from the author directly: • http://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-01 • Disclaimer: use this model as a guidance/basis only, verify your network telemetry! BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 27 Power Consumption On A Smartphone sleeping 10 mA awake 40 mA CPU awake 150 mA sleeping t I(t) BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 28 Experimental Measurements: Per Device When joining the network • At least 4 multicast packets issued (RS + 3DAD) • Possibly more than 20 (MLD, mDNS) joins Once connected • ~0.021 packets/device/second BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 29 Data Analysis From A Real Network (~600 nodes) • Arrival rates: exponential(λ) • Connection durations: ? • Here 600 hosts: 1/λ = 6 s (small)! • Average connection time = 55 min • Model: power multiplier is K = 1 + (0.03 + 28/Tc)*N • 27 nodes, 1 hour average connection time K = 2 (!) BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 30 Why Multicast Solicited RAs ? RFC4861, 6.2.6. Processing Router Solicitations In addition to sending periodic, unsolicited advertisements, a router sends advertisements in response to valid solicitations received on an advertising interface. A router MAY choose to unicast the response directly to the soliciting host's address (if the solicitation's source address is not the unspecified address), but the usual case is to multicast the response to the all-nodes group. BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 31 Tcpdump On A Host In A Large WiFi Network BRKRST-3304 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 32 WLC Sends RAs Reliably: Can Reduce Frequency! APc47a.fe34.1cc9#show capwap mcast mgid all | begin RA MGID RA MGID Information MGID = 8341 IPv6 mc2uc Clients = 1 MGID = 8343 IPv6 mc2uc Clients = 1 APc47a.fe34.1cc9#show capwap mcast mgid id 8343 Normal Mcast Clients: Reliable Mcast Clients: Client: 14cf.929d.740c --- Qos User Priority: 3 State: ADMITTED History – Retry Pct: 0 0 0 0 Rate )500Kbps): 0 65535 65535 APc47a.fe34.1cc9# BRKRST-3304 © 2018 Cisco and/or its affiliates.
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]
  • 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.
    [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]
  • 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.
    [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]
  • 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.
    [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]
  • 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
    [Show full text]