DOCSLIB.ORG

Ipv6 Network

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Ipv6 Network Designing and Deploying a Secure IPv6 Network Timothy Martin - @bckcntryskr Robert Barton - @MrRobbarto Eric Vyncke - @evyncke TECIP6-2001 Cisco Webex Teams Questions? Use Cisco Webex Teams to chat with the speaker after the session How 1 Find this session in the Cisco Events Mobile App 2 Click “Join the Discussion” 3 Install Webex Teams or go directly to the team space 4 Enter messages/questions in the team space TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 3 Agenda • IPv6 Design Considerations • IPv6 Routing Protocols • IPv6 Translation Technologies • IPv6 in IoT, A case study • Securing the IPv6 Perimeter • Conclusion TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 4 IPv6 Design Considerations Tim Martin Solutions Specialist @bckcntryskr #2020 TECRST-2001 Hardening IPv6 Management Plane • SSH, SNMPv3, Syslog, NTP, NetFlow v9 • Disable HTTP/HTTPS access if not needed • RADIUS over IPv6 • IPv6 access-class for SSH VTY access • Important: Harden the router, before enabling routing ipv6 access-list V6ACCESS permit ipv6 2001:db8:10:10::1/128 any deny ipv6 any any log-input line vty 0 4 ipv6 access-class V6ACCESS in transport input ssh TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 6 Routing Protocol Considerations • Enable IPv6 routing • ipv6 unicast-routing (ios) • no switchport (ios-xe) • IPv6 Next Hop • Link local addresses • Global address on interface not required • Topology & alignment with existing RP’s Management Routing • Router ID • Unique 32-bit number identifier Switching Services TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 7 Routing Design Considerations ipv6 route ::/0 gigabitethernet0/1 • Do you need to accept the full table ipv6 router eigrp 123 • Memory, processing, capital.. eigrp stub • Single router, single circuit • Take a default route ipv6 router ospf 1 router-id 3.3.3.3 • Dual router, private circuit area 2 stub • Use stub command from IGP • Dual router, Internet circuit interface Fastethernet0/1 ipv6 address 2001:db8:46:67::a • Take default from provider bfd interval 222 min_rx 222 multiplier 3 • Bidirectional forwarding detection ! router bgp 65110 neighbor 2001:db8:46:67::b fail-over bfd TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 8 Point-to-Point Routed Links • Use a prefix length of /127 • Reserve the /64, configure the /127 • Nodes 1 & 2 are NOT in the same subnet • Suppress RAs for global assigned addressing • Disable ICMPv6 redirects interface FastEthernet0/1 • Don’t send ICMPv6 unreachable ipv6 address 2001:db8:46:67::a/127 • RFC 7404, Link local only ipv6 nd ra suppress no ipv6 redirects 2001:db8:46:67::/127 no ipv6 unreachables ::a ::b TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 9 Static Routing • Link Local Next Hop ipv6 unicast-routing • Redistribution needs GUA or ULA !direct ipv6 route 2001:db8:1::/48 ethernet1/0 • Direct (interface) !recursive • Recursive (next hop) ipv6 route 2001:db8:5::/48 2001:db8:4::1 • Fully qualified (interface) (next hop) !fully qualified ipv6 route 2001:46::/32 ethernet0/0 fe80::9 • Default route ::/0 !default ipv6 route ::/0 ethernet0/2 fe80::2 TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 10 IPv6 Routing Protocols OSPFv3 ipv6 unicast-routing ! • OSPFv3 – IP 89 interface loopback0 • fe80::/64 Source → ff02::5, ff02::6 (DR’s) ipv6 address 2001:db8:1000::1/128 • Link-LSA (8) – Local Scope, NH ipv6 ospf 46 area 0 • Intra-Area-LSA (9) – Routers’ Prefixes ! • LSA’s Disconnect topology from prefixes interface ethernet 0/0 • Can converge quickly to a point of scale ipv6 address 2001:db8:50:31::1/64 • Initial database build takes time ipv6 ospf 46 area 0 ! ipv6 router ospf 46 router-id 4.6.4.6 passive-interface loopback0 LSPs* full mesh TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 12 OSPFv3 AF Support router ospfv3 46 • router-id 4.6.4.6 Multiple AF’s (RFC5838) ! • Legacy IPv4 prefixes address-family ipv6 unicast • IPv6 prefixes passive-interface Loopback 0 • Transport over IPv6 exit-address-family ! • Common elements address-family ipv4 unicast • Neighbor table passive-interface Loopback 0 • Link State Data Base (LSDB) exit-address-family ! • Show command structure interface GigabitEthernet 0/2 ip address 192.168.4.1 255.255.255.0 • ip ospf (IPv4 over OSPFv2) ipv6 enable • ipv6 ospf (IPv6 over OSPFv3) ospfv3 46 ipv4 area 0 ospfv3 46 ipv6 area 0 sh ip route ospfv3 TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 13 OSPFv3 Authentication • AH for authentication (RFC4552) interface Ethernet0/0 ipv6 ospf 46 area 0 • Manual key process ipv6 ospf authentication ipsec spi 500 sha • ESP could be used for confidentiality 1234567890ABCDEF1234567890ABCDEF • Need a security license for IPsec • RFC7166 Authentication Trailers key chain AUTH • Anti-replay key 1 • HMAC-SHA-1, 256, 384, 512 key-string RFC cryptographic-algorithm hmac-sha-512 ! address-family ipv6 unicast authentication mode strict area 0 authentication key-chain AUTH TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 14 Classic EIGRP or EIGRPv6 ipv6 unicast-routing ! • EIGRP – IP 88 Interface ethernet 0/0 • fe80::/64 Source → ff02::a Destination ipv6 address 2001:db8:1000::1/128 • No shutdown for older versions ipv6 eigrp 46 ! • Apply the route process to interfaces interface ethernet 0/1 • Auto Summary disabled ipv6 address 2001:db8:50:31::1/64 ipv6 eigrp 46 • Transport & peering over IPv6 ! ipv6 router eigrp 46 no shutdown eigrp router-id 4.6.4.6 TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 15 EIGRP Named Mode router eigrp IPv6rocks ! • Name creates a virtual instance address-family ipv6 unicast autonomous-system 46 • Does not need to be common in domain ! af-interface Loopback0 • Address family configures protocol instance passive-interface • AS number must common within domain exit-af-interface ! • Auto Applied to all IPv6 enabled interfaces af-interface Ethernet0/0 exit-af-interface • No need to configure under the interfaces eigrp router-id 4.6.4.6 exit-address-family Large-scale hub and spoke environments TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 16 EIGRP Authentication • EIGRP supports HMAC-SHA-256 • To generate or validate messages, hash is constructed using: • Configured shared secret • Link Local address of sender • EIGRP packet prior to adding the IP header ! router eigrp IPv6rocks address-family ipv6 autonomous-system 46 af-interface ethernet 0/0 authentication mode hmac-sha-256 0 Cisco123 ! TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 17 IS-IS ipv6 unicast-routing ! interface ethernet 0/0 • Single topology mode ipv6 address 2001:db8:5000:31::1/64 • Single LSDB, single cost ipv6 router isis CISCO • Links must be congruent (dual stacked) isis circuit-type level-1 • Multi topology mode isis ipv6 metric 10000 isis authentication mode md5 • LSDB & cost per protocol • Flexible, transition mode available ! router isis CISCO • Authentication uses MD5 (TLV) net 49.0001.2222.2222.222.00 metric style wide ! A B C A B C A B C address-family ipv6 D E D E D E multi-topology Physical Topology IPv4 SPT IPv6 SPT SPs, Underlay’s TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 18 RIPng ipv6 unicast-routing • RIPng – UDP 521, 15 hops ! • fe80::/64 Source → ff02::9 Destination interface loopback 0 • Distance Vector, Hop Count (1-15) ipv6 address 2001:db8:1000::1/128 ipv6 rip CISCO enable • Split Horizon, Poison Reverse ! • Lightweight IPv6 only protocol interface ethernet 0/0 • Uses AH for authentication ipv6 address 2001:db8:5000:31::1/64 ipv6 rip CISCO enable ! ipv6 router rip CISCO Star topology, single path edge devices TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 19 IPv6 BGP & Multihome Network Prefix Translation IPv6 • RFC 6296 - NPTv6 • Translators attached to internal network Internet • Unique Local Addressing (ULA) inside • Provider allocated addressing outside • Swaps Left Most Bits of Address • Equal length Prefixes • Small-to-Medium Enterprise 2001:db8:46::/48 interface GigabitEthernet0/0/0 fd07:18:4c::/48 nat66 inside interface GigabitEthernet0/0/1 nat66 outside ! nat66 prefix inside fd07:18:4c::/48 outside 2001:db8:46::/48 TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 21 Multihomed, Multiprefix (BGP) • Solve for Ingress & Egress separately Internet ISP B • Peer over IPv6 for IPv6 prefixes ISP A • Controlling hop limit, accepting ~254 only • MD5, AH possible, next-hop-self (fe80::) • Prefix Size Filtering, /32 - /48 router bgp 200 bgp router-id 4.6.4.6 no bgp default ipv4-unicast neighbor 2001:db8:460:102::2 remote-as 2014 neighbor 2001:db8:460:102::2 ttl-security hops 1 neighbor 2001:db8:460:102::2 password cisco4646 TECRST-2001 © 2020 Cisco and/or its affiliates. All rights reserved. Cisco Public 22 Solving Ingress • Equal load distribution • Advertise more specific /45 & /44 Ingress Internet • Non equal load distribution ISP A ISP B • Use AS path prepend, if accepted AS 64499 AS 64497 2001:db8:a1::/32 2001:db8:b1::/32 ipv6 prefix-list ISPAout seq 5 2001:db8:460::/44 ipv6 prefix-list ISPAout seq 10 2001:db8:460::/45 ! ipv6 prefix-list ISPBout seq 5 2001:db8:460::/44 ipv6 prefix-list ISPBout seq 10 2001:db8:468::/45 2001:db8:460::/44 Enterprise Domain neighbor 2001:db8::b1 route-map ISPBout out ! route-map ISPBout permit 10 set as-path prepend 64498 64498 64498 64498 TECRST-2001 © 2020 Cisco and/or its affiliates.
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]
  • 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]
  • 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]
  • Ipv6 Security: Myths & Legends
    IPv6 security: myths & legends Paul Ebersman – [email protected] 21 Apr 2015 NANOG on the Road – Boston So many new security issues with IPv6! Or are there… IPv6 Security issues • Same problem, different name • A few myths & misconceptions • Actual new issues • FUD (Fear Uncertainty & Doubt) Round up the usual suspects! Remember these? • ARP cache poisoning • P2p ping pong attacks • Rogue DHCP ARP cache poisoning • Bad guy broadcasts fake ARP • Hosts on subnet put bad entry in ARP Cache • Result: MiM or DOS Ping pong attack • P2P link with subnet > /31 • Bad buy sends packet for addr in subnet but not one of two routers • Result: Link clogs with routers sending packet back and forth Rogue DHCP • Client broadcasts DHCP request • Bad guy sends DHCP offer w/his “bad” router as default GW • Client now sends all traffic to bad GW • Result: MiM or DOS Look similar? • Neighbor cache corruption • P2p ping pong attacks • Rogue DHCP + rogue RA Solutions? • Lock down local wire • /127s for p2p links (RFC 6164) • RA Guard (RFC 6105) And now for something completely different! So what is new? • Extension header chains • Packet/Header fragmentation • Predictable fragment headers • Atomic fragments The IPv4 Packet 14 The IPv6 Packet 15 Fragmentation • Minimum 1280 bytes • Only source host can fragment • Destination must get all fragments • What happens if someone plays with fragments? IPv6 Extension Header Chains • No limit on length • Deep packet inspection bogs down • Confuses stateless firewalls • Fragments a problem • draft-ietf-6man-oversized-header-chain-09
    [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]
  • Ipv6 AAAA DNS Whitelisting a BROADBAND INTERNET TECHNICAL ADVISORY GROUP TECHNICAL WORKING GROUP REPORT
    IPv6 AAAA DNS Whitelisting A BROADBAND INTERNET TECHNICAL ADVISORY GROUP TECHNICAL WORKING GROUP REPORT A Near-Uniform Agreement Report (100% Consensus Achieved) Issued: September 2011 Copyright / Legal NotiCe Copyright © Broadband Internet Technical Advisory Group, Inc. 2011. 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 – What Is It, Why Is It Important, and Who Is in Charge? … Answers to Common Questions from Policy Makers, Executives and Other Non­Technical Readers
    IPv6 – What is it, why is it important, and who is in charge? … answers to common questions from policy makers, executives and other non­technical readers. A factual paper prepared for and endorsed by the Chief Executive Officers of ICANN and all the Regional Internet Registries, October 2009. 1. What is IPv6? “IP” is the Internet Protocol, the set of digital communication codes which underlies the Internet infrastructure. IP allows the flow of packets of data between any pair of points on the network, providing the basic service upon which the entire Internet is built. Without IP, the Internet as we know it would not exist. Currently the Internet makes use of IP version 4, or IPv4, which is now reaching the limits of its capacity to address additional devices. IPv6 is the “next generation” of IP, which provides a vastly expanded address space. Using IPv6, the Internet will be able to grow to millions of times its current size, in terms of the numbers of people, devices and objects connected to it1. 2. Just how big is IPv6? To answer this question, we must compare the IPv6 address architecture with that of IPv4. The IPv4 address has 32 bits, allowing today’s Internet to connect up to around four billion devices. By contrast, IPv6 has an address of 128 bits. Because each additional bit doubles the size of the address space, an extra 96 bits increases the theoretical size of the address space by many trillions of times. For comparison, if IPv4 were represented as a golf ball, then IPv6 would be approaching the size of the Sun.2 IPv6 is certainly not infinite, but it is not going to run out any time soon.
    [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]
  • 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]
  • 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]
  • Ipv4 and Ipv6 Subnetting Demo
    IPv4 and IPv6 Subnetting Demo Instructor: Networks rely on the use of IP addresses to allow devices to communicate with each other. These addresses are often obtained as a single large block and are given to the organizations that require them. However, a single block of addresses rarely meets the needs of a network and it needs to be segmented in order to better accommodate the network. An IP address is made up of two parts, the address itself and the subnet mask. The subnet mask helps us determine which part of the address defines the network and which part defines the specific host in the network. This is done by comparing the binary bits of the subnet mask to the address itself. Where there is a one in the subnet mask, we are looking at the network portion of the address; where there is a zero, we are looking at the host portion, or the identifier of the specific machine. The subnet can be represented in "CIDR" notation which includes a slash followed by the number of ones, or network bits, in the subnet. So the subnet mask 255.255.255.0 could be shortened to /24 because there are 24 binary ones. Subnets are an effective way to segment a single large network into a Page 1 of 4 group of smaller ones. In IPv4, this concept is fairly simple. A network will be assigned an address block, let's say 192.168.1.0/24. Then, we determine the amount of subnets we need and how many hosts we need in each subnet.
    [Show full text]