DOCSLIB.ORG

Tunneling, CGN and 6RD

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Tunneling, CGN and 6RD Tunneling, CGN and 6RD Stefan Kollar Consulting Systems Engineer CCIE #10668 skollar@cisco.com © 2006 Cisco Systems, Inc. All rights reserved. 1 Agenda IPv6 tunnels IPv6 CGN 6RD introduction 6RD deployment Perform basic 6RD troubleshooting DEMO © 2006 Cisco Systems, Inc. All rights reserved. 2 Tunnels: IPv6-over-IPv4 6to4 6to4 IPv6 Internet . Stateless 6-over-4 encap IPv4 Internet using WK 2002::/16 prefix 6rd . Public IPv4 only LNS BR . Asymmetric routing problem 6rd . Stateless 6-over-4 encap Public/ Public Public/ Private using SP IPv6 prefix IPv4 Private IPv4 IPv4 . Works over public/private IPv4 . RFC5969 6to4 6rd LAC Softwires H/S . RFC5571; uses L2TPv2/IPv4 infra v4 v4/6 v4 v4/6 v4 v4/6 © 2006 Cisco Systems, Inc. All rights reserved. 3 Tunnels: IPv4-over-IPv6 IPv4 Internet Softwires H/S . RFC5571; leverages DS-Lite . L2TPv2/IPv6 infra AFTR CGN+ Dual-Stack Lite 4ov6 4rd LNS TC . 4over6 tunnels terminate in . CGN NAT44 on AFTR . Stateful IPv4 address sharing 4rd IPv6 IPv6 IPv6 . Stateless IPv4-over-IPv6 . tunnel encap/decap . Can do stateless IPv4 LAC B4 4rd . address sharing by allocating . per-CPE port ranges . CPE does NAT44+4rd encap/decap v4 V4/6 v4 V4/6 v4 V4/6 . draft-despres-intarea-4rd-xx © 2006 Cisco Systems, Inc. All rights reserved. 4 What about DS-Lite? CGN IPv4 4 Softwire 4over6 NAT44 Internet B4 AFTR IPv6 4 Access Network IPv6 6 Internet Not deployable due to lack of IPv6-only access network(s) and missing B4 elements Solves same problem(s) as CGN + 6rd which is deployable right now using existing IETF standards and multi-vendor equipment AFTR coverage limited to IPv6-only reachability to remote B4 elements © 2006 Cisco Systems, Inc. All rights reserved. 5 IPv6 Transition Solutions – deployable today Customer Network CPE 1. CGN IPv4 4 NAT44 Internet 6rd 6rd Tunnel 6rd 2. 2. IPv4 4 Access Network XLAT 6 1:1/ IPv6 N:1 Internet 6 IPv6 3. 1. CGN NAT44 to address IPv4 Run-Out same IPv4 access network 1. 2. 6rd for IPv6 access to IPv6 Internet same IPv4 access network 2. 3. Controlled deployment of native IPv6 hosts/apps plus NAT64 (XLAT) 3. © 2006 Cisco Systems, Inc. All rights reserved. 6 CGv6 – Carrier Grade NAT (1.) CGN NAT44 to address IPv4 Address Run-Out . Deployed and is foundation for future SP-class translation solutions (including NAT64) (2.) 6rd for IPv6 subscriber access to native IPv6 Internet (3.) for native IPv6 interworking with IPv4 . Stateless XLAT (1:1) for controlled deployments available now (supported already in ASR1k – IOS XE 3.2) . Stateful XLAT (N:1) NAT64/DNS64 available in 2H2011 Why Stateful XLAT (NAT64) ? Performs IPv4 address sharing Based on IETF BEHAVE WG standards Compliments and completes standards-based XLAT portfolio © 2006 Cisco Systems, Inc. All rights reserved. 7 CGv6 – Carrier Grade NAT - Logging NAT binding records 1) Preferably Netflow9 (or its standardized successor IPFIX) with format (11) 2) Syslog - consume more resources (e.g. CPU, bandwidth, memory) , less scalable and lower throughput © 2006 Cisco Systems, Inc. All rights reserved. 8 CGv6 – Carrier Grade NAT – PCP (Port Control Protocol) Why Stateful XLAT (NAT64) ? PCP protocol enables home network subscribers to create a port forwarding entry on the CGN https://datatracker.ietf.org/wg/pcp/ © 2006 Cisco Systems, Inc. All rights reserved. 9 6RD - Introduction IPv6 Rapid Deployment Defined in draft-ietf-softwire-ipv6-6rd-10.txt and was approved on May 20, 2010, by the IESG for publication as a standards track RFC (RFC5969) Mechanism for Service Providers to deliver IPv6 via their IPv4 network 6rd firstly deployed in Free Telecom and is fully supported by Google Why not 6to4 6to4 service is "over the top" - operating without the SP really controlling who uses the service and who doesn't. IPv6 community to try and kill/deprecate 6to4 © 2006 Cisco Systems, Inc. All rights reserved. 10 6RD – Variation of 6to4 Use SP’s own IPv6 address prefix instead of 2002::/16 Operational domain is limited to the SP’s network and is under its direct control Not all 32 bits from the IPv4 destination address be carried in the IPv6 payload header © 2006 Cisco Systems, Inc. All rights reserved. 11 6RD Deployment 6RD SP Prefix – The IPv6 prefix selected by the SP for the given 6RD deployment 6RD Delegated Prefix – The IPv6 prefix derived from the SP prefix and the IPv4 address bits . Used by the CE for hosts within its site. © 2006 Cisco Systems, Inc. All rights reserved. 12 6RD Prefix Delegation SP v6 Prefix: 2001:B000::/32 v4 common prefix 10.1.0.0/16 v4 common suffix 0.0.0.1/8 0-32 bits 0-32 bits 64 bits SP Prefix IPv4 Address Bits Subnet ID Interface ID 6RD delegate prefix Users Address Space IPv4 Destination Address 16 bits 8 bits 8 bits Ipv4 Common IPv4 Address Ipv4 common Prefix Bits Suffix © 2006 Cisco Systems, Inc. All rights reserved. 13 6RD Prefix Delegation SP v6 Prefix: 2001:B000::/32 IPv4 Common Prefix: 10.1.0.0/16 IPv4 Common Suffix: 0.0.0.1/8 SP IPv4 Network CE1 Site 1 10.1.1.1 BR IPv6 Internet CE2 Site 2 10.1.4.1 10.1.2.1 CE3 Site 3 6RD CE LAN 10.1.3.1 Multipoint Tunnel SP Prefix 2001:B000::/32 V4 Common Prefix 10.1.0.0/16 V4 Common Suffix 0.0.0.1/8 CE1: Delegated 6RD prefix 2001:B000:0100::/40 CE2: Delegated 6RD prefix 2001:B000:0200::/40 BR: Delegated 6RD prefix 2001:B000:0400::/40 CE1 (V4) tunnel transport source 10.1.1.1 CE2 (V4) tunnel transport source 10.1.2.1 BR (V4) tunnel transport source 10.1.4.1 © 2006 Cisco Systems, Inc. All rights reserved. 14 6RD Tunnel Security For packets received on 6RD tunnel interface • IPv4 tunnel source must match the configured IPv4 common prefix and suffix. • IPv4 source address must match the IPv4 address embedded in the IPv6 source address for packets received from CEs. Packets not matching this criteria are dropped © 2006 Cisco Systems, Inc. All rights reserved. 15 Configuration © 2006 Cisco Systems, Inc. All rights reserved. 16 6RD Configuration Steps 6RD Tunnel Mode Service Provider IPv6 Prefix Common IPv4 prefix and suffix interface Tunnel0 ipv6 address 2001:B000:200::1/124 tunnel source GigabitEthernet1/1/7 tunnel mode ipv6ip 6rd tunnel 6rd prefix 2001:B000::/32 tunnel 6rd ipv4 prefix-len 16 suffix-len 8 interface GigabitEthernet1/1/7 ip address 100.1.2.1 255.255.255.0 © 2006 Cisco Systems, Inc. All rights reserved. 17 CE-specific CLI router(config-if)# tunnel 6rd br <ipv4-address> . Optional CLI configured when router is used as CE . Skip security check for packets with the configured IPv4 address as their source IPv4 address. © 2006 Cisco Systems, Inc. All rights reserved. 18 IPv6 General-Prefix ipv6 general-prefix <name> 6rd tunnel <tunnel-interface-number> . Used to define an IPv6 general-prefix computed from a 6rd tunnel interface asr1k(config)#ipv6 general-prefix DELEGATED_PREFIX 6rd Tunnel0 *May 23 11:12:05.644: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state asr1k(config)# asr1k(config)#do sh run int tun 0 Building configuration... Current configuration : 40 bytes ! interface Tunnel0 no ip address end asr1k(config)# © 2006 Cisco Systems, Inc. All rights reserved. 19 Cisco IOS Configuration_related to 6RD only Loopbacks(/32) 6RD-BR Anycast Routing 6RD-BR 10.11.12.13 6RD-BR 10.11.12.13 6RD-CE IPv4 access network ! vlan 10 interface Tunnel0 FE0 no ip address 6RD-CE no ip redirects (CPE) ipv6 enable ! tunnel source FastEthernet0 interface Loopback0 tunnel mode ipv6ip 6rd tunnel 6rd ipv4 prefix-len 8 ip address 10.11.12.13 255.255.255.255 tunnel 6rd prefix 2001:1000::/32 ! tunnel 6rd br 10.11.12.13 interface Tunnel0 ! no ip address interface FastEthernet0 no ip redirects ip address dhcp ipv6 address DELEGATED_PREFIX duplex auto 2001:1000::/128 anycast speed auto tunnel source Loopback0 ! tunnel mode ipv6ip 6rd interface Vlan10 tunnel 6rd ipv4 prefix-len 8 no ip address tunnel 6rd prefix 2001:1000::/32 ipv6 address DELEGATED_PREFIX ! 2001:1000::/64 eui-64 ipv6 route 2001:1000::/32 Tunnel0 ! ! ipv6 route 2001:1000::/32 Tunnel0 ipv6 route ::/0 Tunnel0 2001:1000:B0C:D00:: © 2006 Cisco Systems, Inc. All rights reserved. 20 6RD Deployment tunnel 6rd ipv4 prefix-len 8 (32-8) tunnel 6rd prefix 2011:1000::/32 © 2006 Cisco Systems, Inc. All rights reserved. 21 Debugging © 2006 Cisco Systems, Inc. All rights reserved. 22 6RD IOS Show Commands show ipv6 interface tunnel <n> show tunnel 6rd tunnel <n> show tunnel 6rd destination <SP-v6prefix> tunnel <n> show tunnel 6rd prefix <v4-destination> tunnel <n> © 2006 Cisco Systems, Inc. All rights reserved. 23 Sample IOS Show Command output asr1k#sh ipv6 int tun 0 Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::A0B:C0D No Virtual link-local address(es): General-prefix in use for addressing Global unicast address(es): 2001:1000:B0C:D00::, subnet is 2001:1000:B0C:D00::/128 [ANY] Joined group address(es): FF02::1 FF02::2 FF02::1:FF00:0 FF02::1:FF0B:C0D MTU is 1480 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ICMP unreachables are sent Post_Encap features: Tunnel 6RD ND DAD is not supported ND reachable time is 30000 milliseconds (using 30000) ND RAs are suppressed (periodic) Hosts use stateless autoconfig for addresses. asr1k# © 2006 Cisco Systems, Inc. All rights reserved. 24 Sample IOS Show Command output 6RD Border Relay Router asr1k#sh tunnel 6rd tunnel 0 Interface Tunnel0: Tunnel Source: 10.11.12.13 6RD: Operational, V6 Prefix: 2001:1000::/32 V4 Prefix, Length: 8, Value: 10.0.0.0 V4 Suffix, Length: 0, Value: 0.0.0.0 General Prefix: 2001:1000:B0C:D00::/56 6RD Customer Edge - CPE isr1812#sh tunnel 6rd tunnel 0 Interface Tunnel0: Tunnel Source: 10.10.20.2 6RD: Operational, V6 Prefix: 2001:1000::/32 V4 Prefix, Length: 8, Value: 10.0.0.0 V4 Suffix, Length: 0, Value: 0.0.0.0 Border Relay address: 10.11.12.13 General Prefix: 2001:1000:A14:200::/56 © 2006 Cisco Systems, Inc.
Load more

Recommended publications
  • Ipv4 Address Sharing Mechanism Classification And
    This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination. IEEE/ACM TRANSACTIONS ON NETWORKING 1 IPv4 Address Sharing Mechanism Classification and Tradeoff Analysis Nejc Škoberne, Olaf Maennel, Iain Phillips, Randy Bush, Jan Zorz, and Mojca Ciglaric Abstract—The growth of the Internet has made IPv4 addresses andonlyone/22prefix (1024 IPv4 addresses). Such allocations a scarce resource. Due to slow IPv6 deployment, IANA-level IPv4 are too small to satisfy current growth rates. address exhaustion was reached before the world could transition The only long-term solution to the IPv4 address exhaustion to an IPv6-only Internet. The continuing need for IPv4 reacha- bility will only be supported by IPv4 address sharing. This paper problem is transition to the IPv6 protocol, which enables ad- reviews ISP-level address sharing mechanisms, which allow In- dressing large numbers of Internet devices [2]. However, today ternet service providers to connect multiple customers who share we observe little IPv6 deployment. IPv6 penetration at content a single IPv4 address. Some mechanisms come with severe and un- providers (top 500 Web sites) is about 24% globally [3] as of predicted consequences, and all of them come with tradeoffs. We March 15, 2013, while is somethingmorethan1%attheuser propose a novel classification, which we apply to existing mech- anisms such as NAT444 and DS-Lite and proposals such as 4rd, side [4] as of the same date. As IPv4 and IPv6 are incompatible, MAP, etc. Our tradeoff analysis reveals insights into many prob- IPv6 designers envisioned a dual-stack deployment [5], with the lems including: abuse attribution, performance degradation, ad- aim that by the time the IPv4 address space became depleted, dress and port usage efficiency, direct intercustomer communica- IPv6 would be universally deployed.
    [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]
  • 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]
  • VRF-Aware Ipv6 Rapid Deployment Tunnel
    VRF-Aware IPv6 Rapid Deployment Tunnel Virtual Routing and Forwarding - aware tunnels are used to connect customer networks separated by untrusted core networks or core networks with different infrastructures (IPv4 or IPv6). The VRF-Aware IPv6 Rapid Deployment Tunnel feature extends Virtual Routing and Forwarding (VRF) awareness to IPv6 rapid deployment tunnels. • Finding Feature Information, on page 1 • Restrictions for the VRF-Aware IPv6 Rapid Deployment Tunnel, on page 1 • Information About the VRF-Aware IPv6 Rapid Deployment Tunnel, on page 2 • How to Configure the VRF-Aware IPv6 Rapid Deployment Tunnel, on page 2 • Feature Information for the VRF-Aware IPv6 Rapid Deployment Tunnel , on page 10 Finding Feature Information Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required. Restrictions for the VRF-Aware IPv6 Rapid Deployment Tunnel The VRF- Aware IPv6 Rapid Deployment Tunnel feature has the following restrictions: • The incoming physical interface, and the tunnel interface should have the same VRF instance defined. • The tunnel transport VRF and the egress physical interface, through which the traffic leaves should have the same VRF instance defined.
    [Show full text]
  • Best Practices for Deploying Ipv6 Over Broadband Access
    WHITE PAPER Best Practices for Deploying IPv6 over Broadband Access www.ixiacom.com 915-0123-01 Rev. D, January 2016 2 Table of Contents Introduction ................................................................................................. 4 IPv6 Solutions for Broadband Access......................................................... 4 Translation ................................................................................................... 5 Tunneling ..................................................................................................... 5 Dual-Stack Lite (DS-Lite) ............................................................................ 5 IPv6 Rapid Deployment (6rd) ...................................................................... 6 Dual-Stack ................................................................................................... 8 How Dual-Stack PPP works ....................................................................... 8 Test Requirements ....................................................................................... 9 Testing Tunneling ......................................................................................... 9 Testing Dual-Stack PPP ............................................................................. 11 Conclusion ..................................................................................................12 3 Introduction Service Providers: The IPv6 Bell Tolls for Thee! After more than a decade of forewarning, the IPv4 to IPv6 transition has
    [Show full text]
  • Ipv6 – from Assessment to Pilot
    IPv6 – From Assessment to Pilot James Small CDW Advanced Technology Services Session Objectives State of Things Business Case Plan Design Implement Security & Operations Current Trends Depletion replaced by Growth Population penetration Geoff Huston’s IPv4 Address Report Multiple mobile device penetration The Internet of Things – M2M The Internet of Everything Current Trends Global growth: Penetration doubling every 9 months US penetration: IPv6 Deployment: 24.76% Prefixes: 40.78% Transit AS: 59.48% Content: 47.72% Google’s global IPv6 statistics graph Users: 3.92% Relative Index: 6.2 out of 10 Global IPv6 growth Graphs from Cisco Live Orlando 2013 – PSOSPG 1330 • US Growth/Penetration is Double the Global Rate • Critical mass in US next year (10% penetration) Opinions on Action Gartner – Enterprises must start upgrading their Internet presence to IPv6 now Deloitte – In short, we recommend starting (v6 deployment) now “Starting sooner can give organizations enough lead-time for a deliberate, phased roll-out, while waiting could lead to a costly, risky fire drill.” Roadmap State of things Business Case Plan Design Implement Security & Operations New Trends IPv6-Only Data Centers and Networks (especially mobile ones) on the rise Internet-of-Things – many key protocols are IPv6 only (IPv4 doesn’t have necessary scale) Many new trends are IPv6-Only (e.g. IoT) Smart Factories/Buildings/Cities/Grid Intelligent Transportation System General Business Case 65% of Cisco Enterprise Technology Advisory Board members will have IPv6 web sites by the end of this year (2013) Top drivers for IPv6 BYOD Globalization Internet Evolution/Internet Business Continuity (B2B/B2C) Legal Business Cases Mobile (Tablets/Smartphones) LTE/4G an IPv6 technology Multinational Firms – Europe far down the IPv6 path, where are you compared to your counterparts? Federal – Goal for full IPv6 deployment by 2014 with some trying to eliminate IPv4 by years end (VA) Legal Business Cases IPv6 Critical mass is coming next year (2014) – B2B, B2C, M2M, and other innovation will follow.
    [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 Multicast Layer 3 Features
    Chapter 13 IPv6 Multicast Support Prerequisites for IPv6 Multicast 13 IPv6 Multicast Support • Prerequisites for IPv6 Multicast, page 13-1 • Restrictions for IPv6 Multicast, page 13-1 • Information About IPv6 Multicast Support, page 13-2 • How to Configure IPv6 Multicast Support, page 13-4 • Verifying the IPv6 Multicast Layer 3 Configuration, page 13-4 Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page: http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html Participate in the Technical Documentation Ideas forum Prerequisites for IPv6 Multicast None. Restrictions for IPv6 Multicast • The PFC and DFCs provide hardware support for the following: – Completely switched IPv6 multicast flows – IPv6 PIM-Sparse Mode (PIM-SM) (S,G) and (*,G) forwarding – Multicast RPF check for IPv6 PIM-SM (S,G) traffic using the NetFlow table – Rate limiting of IPv6 PIM-SM (S,G) traffic that fails the multicast RPF check – Static IPv6 multicast routes – SSM Mapping for IPv6 (PIM-SSM) – IPv6 multicast forwarding information base (MFIB) using the NetFlow table – IPv6 distributed MFIB (dMFIB) using the NetFlow table – Link-local and link-global IPv6 multicast scopes – Egress multicast replication with the ipv6 mfib hardware-switching command – Ingress interface statistics for multicast routes (egress interface statistics not available) – RPR and RPR+ redundancy mode (see Chapter 9, “Route Processor Redundancy
    [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 (jordi.palet@theipv6company.com) - 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]
  • Ipv6 Automatic 6To4 Tunnels
    IPv6 Automatic 6to4 Tunnels This feature provides support for IPv6 automatic 6to4 tunnels. An automatic 6to4 tunnel allows isolated IPv6 domains to be connected over an IPv4 network to remote IPv6 networks. • Finding Feature Information, page 1 • Information About IPv6 Automatic 6to4 Tunnels, page 1 • How to Configure IPv6 Automatic 6to4 Tunnels, page 2 • Configuration Examples for IPv6 Automatic 6to4 Tunnels, page 4 • Additional References, page 5 • Feature Information for IPv6 Automatic 6to4 Tunnels, page 6 Finding Feature Information Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required. Information About IPv6 Automatic 6to4 Tunnels Automatic 6to4 Tunnels An automatic 6to4 tunnel allows isolated IPv6 domains to be connected over an IPv4 network to remote IPv6 networks. The key difference between automatic 6to4 tunnels and manually configured tunnels is that the tunnel is not point-to-point; it is point-to-multipoint. In automatic 6to4 tunnels, routers are not configured in pairs because they treat the IPv4 infrastructure as a virtual nonbroadcast multiaccess (NBMA) link. The IPv4 address embedded in the IPv6 address is used to find the other end of the automatic tunnel.
    [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]