IPv6-Session-Market and Technology

IPv6
- Market and Technology -
Ciprian Popoviciu
Technical Leader
Cisco Systems – NSITE
© 2009 Cisco Systems, Inc. All rights reserved. 1

Legal Notice
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS DOCUMENT ARE SUBJECT TO CHANGE WITHOUT
NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE
PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR
APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION
PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO
LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB)
as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of
California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE
PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR
IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL,
CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA
ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco Stackpower,
Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We
Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You,
Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco
Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch,
Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the
IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network
Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to
Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in
the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not
imply a partnership relationship between Cisco and any other company.
Copyright © 2009 Cisco Systems, Inc. All rights reserved.

Agenda
Part I Part II
IPv6 – Technology & Myths Types of Threats
Adoption Drivers Shared Issues by IPv4 and IPv6
IPv6 over MPLS Specific Issues for IPv6
Deployment Considerations Tunnels and Mobile IPv6
Adoption Challenges IPv6 Security Best Practices
Conclusions Enforcing a Security Policy in IPv6

ACLs and Firewalls
6PE/6VPE Security Considerations
Conclusions

Part I
IPv6 Overview

IPv6 - Technology
& Myths

The one thing to remember
IPv6 is not a Revolution, it is an Evolution!
but
IPv6 does not interoperate with IPv4

IPv6 Technology Scope
Protocol Aspect IPv4 IPv6
32-bit, Network 128-bit, Multiple

Address Range
Address Translation Scopes
ICMPv6, “ARP”,
ICMP ICMP
SLAAC, PMTU
Serverless,
Autoconfiguration DHCP
Reconfiguration,
DHCP-PD, DHCP
RIPv2, EIGRP, RIPng, EIGRPv6,

Routing
OSPFv2, ISIS, OSPFv3, ISIS-ST/MT,
MP-BGP MP -BGP
MP-BGP

IPv6 Technology Scope (cont.)
Protocol Aspect IPv4 IPv6
IP Multicast IGMP/PIM/Multicast MLD/PIM/Multicast

BGP BGP, Scope Identifier
Differentiated Service, Differentiated Service,

Quality-of-Service
Integrated Service Integrated Service
Security IPSec IPSec Mandated,

targets End-to-End
Mobile IP Mobile IP with Direct

Mobility Routing

IPv6 Related Myths and Realities
Claim Myth or Reality
IPv6 protocol has problems Not true, the protocol itself has no problems,
the allocation policy creates difficulties
with multihoming
IPv6 has improved Quality-of- Not true, the flow label could provide
Service added capabilities but it is not used
IPv6 Multicast services are True, primarily due to large address space
easier to deploy and scopping
IPv6 is more Secure than Not true, the claim is based on IPsec
IPv4 requirement
IPv6 mobility services are True, primarily due to cleaner

easier to deploy implementation
Lack of NAT in IPv6 is a Not true, all perceived benefits of NAT
security challenge can be implemented in IPv6 (RFC4864)
Cisco and IPv6 – Technology Experience
Commercial Products More IETF specs
IESG IPng IETF IPv6 WG & Infrastructures (MIPv6, DHCPv6
WG creation Core Specs (6NET, GEANT,…) PD), Applications
1994 199 5-1998

1995-1998 2001 -2004
2001-2004 200 4-2008
2004-2008
1996
IPv6 Prototype 2002
IPv6 in HW
1998
IPv6 code available May 2003
12.3 Mainline
June 2000
Announced the 3 phase IPv6 Roadmap 2001-2005
Leader of 6NET Today
May 2001 Phase I Complete
DOCSIS3.0
IPv6 across the widest breath of platforms in industry

Adoption Drivers

Why IPv6?
A Parallel Between
Argument and Practice

Why IPv6? – Lesson 1
Depletion of the Global IPv4 Address Pool
Argument* and Practice**

RIPE NCC
IANA Allocations to RIR's 15.31
Sliding- windo w 2 4 mo nt h a vera ge 33%
APNIC AfriNIC
3
15.13 0.51523
32% 1%
2.75 ARIN
2.5 14.24
2.25 30%
LACNIC
2
1.75
1.75
4%
1.5
1.25
AfriNIC
1
RIPE NCC 24
0.75 599 2%
0.5 50%
0.25
APNIC
0 277
5 6 7 8 9 0 1 2 3 4 5 6 7 08 09 24%
n-9 n-9 an-9 a n-9 an-9 a n-0 an-0 an-0 an-0 an-0 a n-0 an-0 a n-0 an- a n-
Ja Ja J J J J J J J J J J J J J ARIN
209
LACNIC 18%
66
6%
Source: *Sept. 2005 issue of the Internet Protocol Journal
** NRO, “Internet Number Status Report”
IP Address Allocation History
IANA Allocations to RIR's
IP Address Allocation History S liding- windo w 2 4 mo nt h a v e ra ge
Full discussion at: www.cisco.com/ipj

3
The Internet Protocol Journal 2.75
Volume 8, Number 3, September 2005 2.5
2.25
Consumption is accelerating despite

2
1.75
increasingly intense conservation 1.5

1.25
efforts. 1
0.75
PPP / DHCP (temporal address sharing) 0.5
0.25
CIDR (classless inter-domain routing) 0
NAT (network address translation) 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09

n- n- an- n- n- an- n- n- an- n- n- an- n- n- an-
Ja Ja J Ja Ja J Ja Ja J Ja Ja J Ja Ja J
plus some address reclamation
Projection based on IANA* data from 2000
Growth is occurring in all regions

While growth as seen in the routing system is
strongest in Asia, the allocation growth is strongest
in Europe.

Insufficient private address space (RFC1918)
Not enough private IPv4 MSOs are aggressively

addresses to manage pursuing IPv6:
many devices.
Currently testing IPv6
Proven true by: in the core with low
traffic
Mobile providers
(Fixed/Wireless Conv.) Manage CM, MTAs,
setop boxes over IPv6
MSOs
followed by IPv6
Large Enterprises services
Re-design old service or deploy new ones.

Re-design services Use of IPv6 multicast to
that don’t seem to deliver content to schools
scale as expected
Revenue generating, IPv6
Deploy the next multicast based content
generation services delivery service.

IPv6 Drivers – Global Transparency
• “Always-on” technologies enable new application environments
• IPv6 restores global transparency by getting rid of NAT
• NAT traversal is not an issue anymore for applications
Home A Home B
Internet
N N
Private A Public
Global A Private
IPv4 T IPv4
IPv6 T IPv4

IP Networks are Strategic Assets
At both business and national level
Governments recognize the economic value of IP
infrastructures as productivity tools (Intra and Inter Nets)
Governments recognize the strategic value of the
Internet in providing access to the Global market
Governments recognize the importance and benefit of
being an innovator in Information Technologies
IPv6 offers another shot at leadership in IT

National Strategies on IPv6
Various approaches
1. Government encouragement + financial and legal

incentives
2. Government encouragement + support for research
projects
3. Lead by example
4. Adjust government acceptance policies
http://www.cisco.com/en/US/products/ps6553/products_w
hite_paper0900aecd8032b2ad.shtml

Adoption Activities – DoD
Acquired IPv6 Address space:

- Department of Defense (DOD) - Defense Research and
Engineering Network (DREN) 2001:480::/32 2001/06/14
- Department of Defense (DOD) - DISA Center for Engineering
2001:1918::/32 2004/01/21
- Department of Defense (DOD) - DISA Center for Engineering
2001:430::/32 2000/09/13
Interoperability testing – Moonv6

Conformance testing – JITC
Scalability and Performance testing – DISA
DoD IPv6 Standard Profiles – IPv6 Standards
Technical Working Group

Adoption Activities – Civilian
Acquired IPv6 Address space:

- Department of Commerce (DOC) 2610:20::/32 2006/02/08
- Department of Education (ED) 2610:e8::/32 2006/09/27
- Department of Energy (DOE) 2001:400::/32 1999/08/03
- Department of Homeland Security (DHS) 2610:c8::/32 2006/08/10
- Department of State (DOS) 2610:158::/32 2007/02/01
- Department of the Interior (DOI) 2001:49c8::/32 2005/11/10
- Department of the Treasury 2610:108::/32 2006/10/27
- Department of Transportation (DOT) 2001:19e8::/32 2004/10/25
- Department of Veterans Affairs (VA) 2610:d8::/32 2006/08/24
Some agencies designed addressing scheme, requested

native IPv6 connectivity from SPs and developed
deployment plans (DE, SSA, USPS)
“A Profile for IPv6 in the US Government”
http://www.antd.nist.gov/usgv6-v1-draft.pdf
Key Aspects Reminder
IPv6 is NOT a feature. It is about the fundamental IP
network layer model developed for end-to-end services
and network transparency
Deployments of production IPv6 infrastructures are
under way, the time has come to move our focus to
edge, access and usage
6Bone is phasing out, 6NET is closed,…
Today’s IPv6 deployment drivers do not rely on
uncovering the “future killer application” anymore, they
focus instead on:
Performing the same as on IPv4 but on a larger scale
Operational cost savings or simpler network models
when deploying applications
Leading the innovation

IPv6 over MPLS

IPv6 Provider Edge Router (6PE) over
MPLS
MP-iBGP sessions
2001:0620:: v6 v6 2001:0420::
145.95.0.0 v4 v6 2001:0421::
6PE P P 6PE
Dual Stack IPv4-IPv6 routers Dual Stack IPv4-IPv6 routers
2001:0621:: v6
CE P P
6PE IPv4 6PE
192.76.10.0 v4 MPLS v4 192.254.10.0
CE CE
• IPv4 or MPLS Core Infrastructure is IPv6 unaware

• Provider Edges are updated to support Dual Stack/6PE
• iBGP (Multi-Protocol Border Gateway Protocol (MP-BGP))
exchanges IPv6 reachability with 6PEs
• 6PE transports IPv6 packets to 6PE inside MPLS

6PE Routing
MP-BGP advertises 2001:0421::
and binds a second level label
IPv6 Next Hop is an IPv4 compatible IPv6 address
built from 192.254.10.17
2001:0420::
IGPv4 advertises
reachability of 2001:0421::
192.254.10.17
192.72.170.13
6PE-1
LDPv4 binds label
to 192.254.10.17 192.254.10.17
6PE-2
P1 P2
• Translation of v6 BGP
Next_Hop into v4 address
• Recursion of this address
via IGPv4

6PE Forwarding
IPv6 Forwarding and Label Imposition:
• 6PE-1 receives an IPv6 packet
2001:0420:: • Lookup is done on IPv6 prefix
• Results :
Label is binded by MP-BGP to
2001:0421:: 2001:0421::
IPv6 packet 192.72.170.13
to 2001:0421:: Label1 is binded by LDP/IGPv4 to
6PE-1 the IPv4 address of BGP Next Hop
(6PE-2)
6PE-2
LDP/IGPv4 MP-BGP label IPv6 packet
label1 to 6PE-2 to 2001:421:: to 2001:421::
192.254.10.17
P1 P2

6PE Configuration Example
Interface Ethernet 1/0
ip address 40.1.1.2 255.255.255.0
MPLS label BGP IPv6
ip router isis (LDP) label packet
mpls is
IPv6 network
PE1 PE2 IPv6 network
2001:100:1000::/48 CE2 2001:100:1100::/48
200.10.10.1 200.11.11.1
CE1
LSP setup: iGP + LDP
MP-iBGP peering
IPv6+label
router bgp 100

bgp log-neighbor-changes
router bgp 100 neighbor 200.10.10.1 remote-as 100
bgp log-neighbor-changes !
neighbor 200.11.11.1 remote-as 100 address-family ipv6
! neighbor 200.10.10.1 activate
address-family ipv6 neighbor 200.10.10.1 send-label
neighbor 200.11.11.1 activate
neighbor 200.11.11.1 send-label

IPv6 VPN over MPLS – 6VPE
VPN A V4 and v6 VPN V4 and v6 VPN
MP-iBGP sessions
VPN A
VPN B V6 only
P P
MPLS
Backbone
VPN A V4 and v6 VPN
P P
V6 only VPN B
VPN B V6 only
MPLS
• 6VPE ~ IPv6 + BGP-MPLS IPv4 VPN + 6PE

• Customer connectivity is deployed on a shared infrastructure
with the same policies as a private network
• IPv6 VPN can co-exist with IPv4 VPN – same coverage
• 6VPE is added only when and where the service is required
http://www.cisco.com/application/pdf/en/us/guest/products/ps6553/c1161/cdccont_0900aecd80311df4.pdf

* Based on rfc2547bis and draft-ietf-l3vpn-bgp-ipv6
6VPE Technologies
Reuse existing VPNv4 components:
RD, RT, VRF, MPLS
New components for VPNv6

MP-BGP VPNv6 address-family
RD [64 bits] + IPv6 prefix [128 bits]
Support IPv6 addressing – Global/Unique Local/Link Local
Distributing VPNv6 addresses among PEs via MP-iBGP over IPv4
RFC 2283 – Multiprotocol extension for BGP4
VPN IPv6 NLRI encoding
AFI=2 (IPv6); SAFI=128 (MPLS labeled VPNv6)
BGP nexthop - IPv4-compatible IPv6 address
PE advertises to its peer a Next Hop Network Address field containing a
VPN-IPv6 address:
RD=0
IPv6 address is encoded as an IPv4-mapped IPv6 address
(::ffff:IPv4 address)

Multi-Protocol VRF
vrf red tables RIBv4, FIBv4
I/F list IF1, IF2
Specific Route-map
Protocols IPv4 Policies Route-targets
IPv6
CE tables RIBv6, FIBv6
Common Route-targets
policies Specific Route-map
Site-A
Policies Route-targets
CE
IF1 PE
Site-B
IF2
IF3
CE
IF4
Site-C
CE
Site-D
tables RIBv6, FIBv6
I/F list IF3, IF4
Policies Route-map
Protocols IPv6
Route-targets
vrf yellow

Multi-Protocol VRF Deployment
Dual-stack vrf
ipv4 addresses: 10.100/16 Address-family IPv4
ipv6 addresses: 2001:100::/64 Address-family IPv6
Dual-stack network
P1 P2
Site-1 Dual-stack network
CE1 CE2
2001:101::/64 PE1 PE2 Site-2
10.101/16 VRF red
iGP-v4 (OSPF, ISIS) 2001:201::/64

VRF red 10.201/16 Dual stack
LDP-v4
MP-eBGP session server
Address-family IPv4
Address-family IPv6 MP-iBGP session MP-eBGP session
Address-family VPNv4 Address-family IPv4
Address-family VPNv6 Address-family IPv6
vrf definition site1

rd 100:1
route-target import 100:1
route-target export 100:1
address-family ipv4
address-family ipv6
!
interface ethernet0/0
vrf forwarding site1
ip address 10.100.1.2 255.255.0.0
ipv6 address 2001:100::72b/64

6VPE Configuration Example
vrf definition site1
rd 1000:1 router bgp 100
neighbor 200.10.10.1 remote-as 100
route-target export 1000:1
neighbor 200.10.10.1 update-source Loopback0
address-family ipv4 interface Ethernet0/0
!
address-family ipv6 vrf forwarding site1
address-family ipv4 vrf site1
ipv6 address 2001:100::72b/64
neighbor 10.100.1.1 remote-as 200
ip address 10.100.1.2 255.255.255.0
!
Interface Configuration address-family ipv6 vrf site1

VRF Configuration
neighbor 2001:100::72a remote-as 200
neighbor 2001:100::72a activate
!
address-family vpnv4
BGP Configuration neighbor 200.10.10.1 send-community extended
!
address-family vpnv6
neighbor 200.10.10.1 send-community extended

Scaling IPv4 and IPv6 VPN routes
VPNv4 routes well passed 1 million for some SPs
Experiences with VPNv4
MPLS L3 VPN Internet
Routes per port Ave. 2-3 Ave. <3
Routes per Ave. ~300 Ave. ~7
customer
Growth rate >> 2000/month ~ 2000/month
Note: the recent IPv4 route growth is accelerated, observed 25K – 50K/year growth rate.
VPNv6 route consumes more memory than VPNv4 route
Prefix limit should be used as in VPNv4 to encourage aggregation
Large VPN customers can have thousands of sites
10K sites will result in 20K + VPN routes
PE shared with Internet and VPN suppose are facing more pressure from the Internet
as well as VPN route growth
More scalable control plane implementation and well planed deployment are needed

Deployment
Considerations

Deployment Considerations
Addressing
Deployment Options
Planning

Deployment
Considerations
- Addressing -

IPv6 Address Allocation Policies Review
Goals of allocation policies:

Encourage prefix aggregation
Encourage new perspectives on addressing
Control address space distribution from day one

Original Allocation Boundaries Scheme
Challenges:
IANA Multihoming and renumbering
concerns could slow adoption
in large enterprises:
Registries
- Lack of simple multihoming
mechanisms
- Lack of agreed upon
ISP
multihoming strategy (SHIM6
rejected by NANOG)
Enterprise Large enterprises like to own
their address space
ARIN adopted PI space

Allocation Boundaries
IANA
Provider Provider
Registries
Dependent Independent
ISP Org
Level Four
Enterprise

Provider Dependent Policy
2000::/3
IANA
/12 (23) Provider

Registries Independent
/32 (35)
ISP Org
Recommend Enterprise
Level Four
/48
http://www.icann.org/announcements/announcement-12oct06.htm
Provider Independent Policy (ARIN)
IANA 2000::/3
Provider /12 (23)

Registries
Dependent
ISP Org /48
Level Four
Enterprise
http://www.arin.net/policy/archive/2005_1_orig.html
http://www.afrinic.net/docs/policies/afpol-v6200701.htm
Allocation Recommendations
Beyond the ISP boundary there are allocation

recommendations and not policies
It is recommended that ISP assign /48 to their
customers:
http://www.ripe.net/ripe/docs/ipv6policy.html
http://www.icann.org/announcements/ipv6-report-06sep05.htm
In practice, it is most likely that the allocations below

ISP will be between /48 and /64
ARIN policy for micro-allocation for infrastructure
http://www.arin.net/policy/proposals/2006_2.html

To ULA or not to ULA
ULA (FC00::/48) are defined in RFC 4193

Similar to RFC 1918 but statistically unique
Replaces Site-Local Addresses (SLA) due to the
reasons listed in RFC 3879
Pro Con
• Familiarity with private space • SA/DA selection consistency

• Independence from policies • Problems with global multicast
• Securing infrastructure • Limited to /48 so large networks
might end up being federated
• Easy user access control
draft-baker-v6ops-b2b-private-routing
Deployment
Considerations
- Deployment Options -

IPv6 Deployment Strategies for ISP
Cisco
Environment Scenario IOS
support
Few customers, no native IPv6
service form the PoP or Data link is
Access Tunnels Yes
not (yet) native IPv6 capable, ie:
Cable Docsis
Native IPv4-IPv6 services between
Dual Stack Yes
aggregation and end-users
Dedicated circuits – IPv4 – IPv6 Dual Stack Yes
Core Native IP – Core is IPv6 aware Dual Stack Yes
MPLS – Core is IPv6 unaware 6PE/6VPE Yes

Provisioning Considerations
Different provisioning mechanisms and tools can be

leveraged such as:
Stateless Address Autoconfiguration (SLAAC)
Stateless/Statefull DHCP
General Prefix
DHCP-PD (with gateway as server),
DHCP-PD (centralized server)
RADIUS (CISCO VSA, RFC3162)
Manual/Static Configuration

Provisioning Observations
Service Providers prefer Statefull over Stateless:

Want the control offered by Statefull
Stateless still used for the uplink
Prefer centralized provisioning over highly distributed
Enterprises like Stateless but if combined with NMS
tools. Government agencies usually like the control of
statefull.

Routing Protocols Considerations
The IPv6 and IPv4 IGPs will most likely use separate
resources (use of ISIS-ST, the only option available
today for using a single IGP, is too restrictive)
So if you have been contemplating trying a different

IGP, this is a good opportunity.
BGP remains BGP

IPv6 IGP Selection – in theory
The similarity between the IPv6 and IPv4 routing protocols

leads to similar behaviour and expectations
To select the IPv6 IGP, start by using the IPv4 IGP
selection rules of thumb for:
Topology
Convergence
Scale

IPv6 IGP Selection – in practice
There are differences between the IPv4 and IPv6 IGPs that
could lead to new design perspectives
The IPv6 IGP implementations might not be fully optimized
Not all knobs for Fast Convergence might be available
Lack of large scale operational experience with IPv6
0.5 0.7
0.45
0.6
0.4
0.35 0.5 IPv4 OSPF
IPv4 OSPF
0.3 0.4
Tim e
Tim e
0.25
IPv4 OSPF 0.3 IPv4 OSPF
0.2
IPv6 OSPF IPv6 OSPF
0.15 0.2
0.1
0.1
0.05
0 0
0 500 1000 1500 2000 2500 3000 0 500 1000 1500 2000 2500 3000
Number of Perfixes Number of Perfixes

BGP Considerations
Suggestions that try to minimize possible co-existence

challenges:
Establish peers for each protocol = do not carry all BGP
information over an IPv4 or an IPv6 peering session
Use separate RR structures for IPv4 and IPv6
Limit the number of prefixes accepted from peers
Maximize prefix aggregation

Multicast Considerations
Very similar to IPv4
Same two deployment approaches:
ASM – challenges due to lack of MSDP
SSM – very well suited for content delivery
Things to consider:
Subscribers will likely own global multicast groups – will
they be allowed to source?
Multicast is critical to the control plane – avoid too tight
control that would break the control plane but make it
strong enough that would prevent attacks on it
Billing models are still being developed

QoS Considerations
Very similar to IPv4
Diffserv only at this time even though IntServ is
standardized
Two deployment approaches:
Protocol version independent policies <- Recommended
Protocol version dependent policies
Things to consider about classification options:
IPv6 addresses will most likely carry more location or
service significant information
Additional IPv6 fields such as Flow Label or extension
headers can be used for classification in the context of
new, innovative service models
Network Management Considerations
In dual-stack deployments, IPv6 will add network

management complexity
How should a dual-stack network be managed?
IPv6 will enhance scalability in specific situations (large,
IPv6-only networks)
Service provider networks - CPE, STB management
Data center - millions of virtual hosts

IPv6 Network Management requirements…
IP version-agnostic network management applications
Integration of IPv4/IPv6 in element management
Add support for IPv6 capabilities in tools platform
Tools for:
Deployment
Configuration
Monitoring
Fault detection, diagnosis and correction
Renumbering
Neighbor Discovery data aggregation

IPv6 Security Architecture—End to End
Internet
Encrypted
Private 1 Private 2
The proposed end-to-end (E2E) IPsec model required by
RFC2460 is not practical for several reasons:
Inconsistent stack implementations
It is not feasible to implement IPsec support on all devices (phones, simple
sensors, etc)
Large Scale key distribution infrastructure needed
Network Administrators are not willing to drop the ability to “see” what is carried
in a packet entering or exiting their network

IPv6 Security Architecture—
Perimeter, Hybrid
Internet
Encrypted
Private 1 Private 2
Hybrid
Internet
Private 1 Private 2
Perimeter
A perimeter-E2E hybrid might become an acceptable compromise
but for now, the IPv6 Security Architecture is similar to IPv4’s =
perimeter!
IPv6 Security Considerations
Threat Analysis based mainly on the experience of

operating IPv4 networks and on the theoretical aspects
of IPv6
Large scale IPv6 deployments have gone into
production only recently and they are typically relatively
isolated
The “IPv6 Internet” is a relatively small playing field
End-to-End IPsec changes the security paradigm but
does not necessarily mean more secure

Deployment Planning
Initiate the Education and Training process –you need

knowledgeable staff for the other steps
Design your future IPv6 network – understand where
you want to go, identify the feature needs and define
purchasing policies
Network assessment – evaluate costs in the light of the
IPv6 design
Update policies – purchasing, acceptance, etc
Plan the deployment – grow as the network becomes
ready, re-use equipment
t

Some Adoption
Challenges

Some Adoption Challenges
Multihoming
Conformance
IPv4-IPv6 Parity
Security

Some Adoption
Challenges
- Multihoming -

The Multihoming Questions
Goals of multihoming:
Transport-Layer Survivability
Internet
Packet Filtering traversal connectivity
Scalability
Simplicity ISP-A ISP-B
–Operations and Management
–Cooperation between Transit Site exit router A Site exit router B
Providers Local site

connectivity Multi-homed site
Multi-homed host

Why IPv6 is different from IPv4 ?
At first glance, it is not. But …
– More addresses make the scalability concerns higher
– Address allocation strategy more “controlled” leaves less
room for “hole poking”
Could IPv6 do better than IPv4 ?
– Multiple addresses per interface suggest better (than IPv4)
solution could be envisioned
– IPv6 community (IETF) thinks it’s time for re-engineering
multihoming

The multi-homed Domain
Remote host
Internet
connectivity
ISP-A ISP-B
Site exit router A Site exit router B

Local site
connectivity
Multi-homed site
Application:http, ftp, etc.
Transport:tcp, udp, etc.
Multi-homed host forwarding

Long term solution: shim6?
Host Based solution, not network based
Separate the locator and the identifier of a node
May suit well consumer networks
May be problematic for commercial networks
– Large number of hosts
– Complex routed network
– End users do not own network or traffic engineering
preferences
Transition may be problematic as well

Conclusion
IPv6 Multihoming “technically” not different from IPv4
However, deployment-wise, IPv6 carries more
opportunities and risks (Wrt to multihoming)
All solutions available in IPv4 are applicable to IPv6,
including now PI addresses
SHIM6 less popular these days, however, this is not the
end of the story …

Some Adoption
Challenges
- Conformance -

Conformance Concerns
IPv6 stack implementation inconsistencies, particularly as

vendors rush to support IPv6
Some IPv6 features are only now being tested in
production and at scale so tweaks in the protocol
definitions will continue. This could lead to out of sync
stacks
TAHI suites for testing (http://www.tahi.org/)
Interoperability testing is important
Deployments and preparation for deployment have been
flushing these problems out
Performance has specific aspects in IPv6:
http://tools.ietf.org/html/draft-ietf-bmwg-ipv6-meth-02

Some Adoption
Challenges
- IPv4-IPv6 Feature Parity -

IPv4-IPv6 Parity Concerns
Feature parity between IPv4 and IPv6 is improved as

market requirements and demand increases with
deployment. This is an evolutionary process but the
impact is likely small
Performance (both forwarding and scalability) of
platforms varies. Not everyone designed hardware with
IPv6 in mind and that becomes apparent in performance
tests
Deployments have been flushing these problems out
Simple parity should not always be a primary criteria

Some Adoption
Challenges
- Security -

Security Concerns
Lack of feature parity between IPv4 and IPv6 would limit

the ability to protect against similar threats
Transition mechanisms can provide backdoors for
attackers
IPv6 protocol characteristics have been theoretically
analyzed for possible attack vectors however, practice
will tell the full story
Stack implementations might be less security minded
Concern over loss of perceived benefits of NAT
Many production deployments are self-contained for now
so the security risks are reduced

Market perceived benefits of IPv4 NAT
RFC 4864
Function IPv4 IPv6

Simple Gateway DHCP – single address DHCP-PD – arbitrary length customer
upstream prefix upstream
DHCP – limited number of SLAAC via RA downstream
individual devices
downstream
Simple Security Filtering side effect due to Explicit Context Based Access Control
lack of translation state (Reflexive ACL)
Local usage tracking NAT state table Address uniqueness
End system privacy NAT transforms device ID Temporary use privacy addresses
bits in the address
Topology hiding NAT transforms subnet bits Untraceable addresses using IGP host
in the address routes /or MIPv6 tunnels for stationary
Addressing Autonomy RFC 1918 RFC 3177 & 4193 (ULA)

Global Address Pool RFC 1918 340,282,366,920,938,463,463,374,607,431,768,211,456
Conservation (3.4*10^38) addresses
Renumbering and Multi- Address translation at Preferred lifetime per prefix & Multiple
homing border addresses per interface
Adoption Challenges Conclusion
All the above being said, the most difficult

part in the IPv6 adoption is NOT the
infrastructure!

Conclusion

IPv6 is not a matter of “if” but a matter of “when”. The latest
predictions are that exhaustion will occur in 2009-2010. A
policy is in discussion to set the date for termination of IPv4
allocations (http://www.arin.net/policy/proposals/2007_12.html).
Consider this:
Is it better to “have to MIGRATE to IPv6 over night” or to
“INTEGRATE IPv6 on your own terms”?
How many refresh cycles do you have until IPv4 is out in
order to save money on preparing the network for IPv6?
How much expertise does your organization have with
IPv6?
The conclusions are yours to draw!

Q and A

Cisco Press Books

Part II
IPv6 Security

Types of Threats
A quick taxonomy of threats

Types of Threats
Reconnaissance—Provide the adversary with

information
Unauthorized access—Exploit
Header manipulation and fragmentation—Evade or
overwhelm
Layer 3–Layer 4 spoofing— Mask the intent or origin of
the traffic
ARP and DHCP attacks—Subvert the host initialization
process
Broadcast amplification attacks (smurf)—Amplify the
effect of a flood
Routing attacks—Disrupt or redirect traffic flows
Types of Threats (Cont.)
Viruses and worms— Propagation of the

malicious payload
Sniffing—Capturing data
Application layer attacks— Attacks executed
at Layer 7
Rogue devices—Unauthorized devices connected to a
network
Man-in-the-middle attacks— Attacks which involve
interposing an adversary between two communicating
parties
Flooding—Consume enough resources to delay
processing of valid traffic
Shared Issues
Security issues shared by IPv4 and IPv6

Reconnaissance in IPv4
In IPv4, Reconnaissance Is Relatively Easy
1. DNS/IANA crawling (whois) to determine ranges
2. Ping sweeps and port scans
3. Application vulnerability scans
[tick:/var] scott# nmap -sP 10.1.1.0/24

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Host (10.1.1.0) seems to be a subnet broadcast …
Host (10.1.1.1) appears to be up.
Host (10.1.1.255) seems to be a subnet broadcast …
Nmap run completed -- 256 IP addresses (7 hosts up)
scanned in 4 seconds

Subnet Size Difference
Default subnets in IPv6 have 2^64 addresses

=> scanning every address: centuries vs. seconds
NMAP doesn’t even support ping sweeps on IPv6
networks (you’ll have retired by the time it finishes,
even at one million packets per second)

Scanning Methods Are Likely to Change
Public servers will still need to be DNS reachable

Dynamic DNS adoption causing DNS servers to be rich
sources for address to scans
Administrators may adopt easy to remember addresses
(::10,::20,::F00D, ::C5C0 or simply IPv4
last octet)
By compromising hosts in a network, an attacker can
learn new addresses to scan

New Multicast Addresses
For example, all routers (FF05::2) and all DHCP
servers (FF05::1:3)
These addresses must be filtered at the border in order
to make them unreachable from the outside
Source Destination Payload

2001:0410::50
Attacker FF05::2 DoS
2001:0410::60
2001:0410::70

Reconnaissance IPv6 Best Practices
Implement privacy extensions carefully—

(next slide)
Filter internal-use IPv6 addresses at organization
border routers—prevent addresses like the all nodes
multicast address from becoming conduits for attack
Filter unneeded services at the firewall—just
like in IPv4
Selectively filter ICMP—more on this later

IPv6 Privacy Extensions (RFC 3041)
/23 /32 /48 /64
2001 Interface ID
Temporary addresses for IPv6 host client application,
e.g. web browser
Inhibit device/user tracking but many organizations want
to do the tracking
Random 64 bit interface ID, run DAD before using it
Rate of change based on local policy
Recommendation: Use Privacy Extensions for External

Communication but Not for Internal Networks
(Troubleshooting and Attack Trace Back)
Access Control in IPv6 Privacy
Extension
Good to protect the privacy of a host

But hard to define authorization policy when the Layer 3
information is always changing :-)
Management System New IPv6

Address—2001:DB8:F15:C15::2*
Internal Server
2001:DB8:F15:c16::1/64
Firewall
IPv6
Intranet X
Management System IPv6
Address—2001:DB8:F15:C15::1*
Action Src Dest Src Port Dst Port
2001:DB8:F15 2001:DB8:F1
*—Not Real Permit :C15::1 5:c16::1
Any 80
RFC3041 Derived
Addresses Deny Any Any

IPv6 Bogon Filtering
In IPv4, it is generally easier to block bogons than it is
to permit non-bogons
In IPv6, in the beginning when a small amount of top-
level aggregation identifiers (TLAs) have been allocated
it was easier to filter bogons. Now IPv6 is in a similar
situation as IPv4.
Same technique = uRPF
Inter-Networking Device with

uRPF enabled
IPv6 IPv6
Intranet X
Intranet/Internet
IPv6 Unallocated No Route to SrcAddr => Drop
Source Address

ICMPv4 vs. ICMPv6
Significant changes
More relied upon
ICMP Message Type ICMPv4 ICMPv6
Connectivity Checks X X
Informational/Error Messaging X X
Fragmentation Needed Notification X X
Address Assignment X
Address Resolution X
Multicast Group Management X
Mobile IPv6 Support X
=> ICMP policy on firewalls needs to change

Generic ICMPv4 Border Firewall Policy
Internal Server A
Internet
ICMPv4 ICMPv4
Action Src Dst Name
Type Code
Permit Any A 0 0 Echo Reply
Permit Any A 8 0 Echo Request
Dst. Unreachable—
Permit Any A 3 0
Net Unreachable
Dst. Unreachable—
Permit Any A 3 4
Frag. Needed
Time Exceeded—
Permit Any A 11 0
TTL Exceeded

Equivalent ICMPv6 Border Firewall
Policy
Internal Server A
Internet
ICMPv6 ICMPv6
Action Src Dst Name
Type Code
Permit Any A 128 0 Echo Reply
Permit Any A 129 0 Echo Request
Permit Any A 1 0 No Route to Dst.
Permit Any A 2 0 Packet too Big
Time Exceeded—
Permit Any A 3 0
TTL Exceeded

Potential Additional ICMPv6 Border
Firewall Policy*
Internal Server A
Firewall B
Internet
ICMPv6 ICMPv6
Action Src Dst Name
Type Code
Permit Any A 4 0 Parameter Problem
Permit Any B 2 0 Packet too Big
Permit Any B 130–132 0 Multicast Listener
Neighbor Solicitation
Permit Any B 133/134 0
and Advertisement
Permit Any B 4 0 Parameter Problem
*RFC 4890
IPv6 Header Manipulation
Unlimited size of header chain (spec wise) can make filtering
difficult
DoS a possibility with poor IPv6 stack implementations
More boundary conditions to exploit
Can I overrun buffers with a lot of extension headers?
Perfectly Valid IPv6 Packet

According to the Sniffer
Header Should Only Appear Once

Destination Header Which Should
Occur at Most Twice
Destination Options Header Should
Be the Last

Fragmentation Used in IPv4 by Attackers
Great evasion techniques

Tools like whisker, fragrout, etc.
Makes firewall and network intrusion
detection harder
Used mostly in DoSing hosts, but can be used for
attacks that compromise the host

Fragment Header: IPv6
Next Header = 44
Ipv6 Basic Header
Fragment
Header Fragment Header
Fragment Header
Next Header Reserved Fragment Offset
Identification
Fragment Data
In IPv6 fragmentation is done only by the

end system
Reassembly done by end system like in IPv4
Attackers can still fragment in intermediate system on
purpose
==> a great obfuscation tool
IPv6 Fragmentation: Still Need
Reassembly in the Firewall and NIDS
Imagine an Attacker Sends:
1. HDR HDR US Seq. #
2. HDR ER
Time
3a. HDR HDR ro
3b. HDR HDR fo
4. HDR ot
Should we consider 3a part of the data stream “USER
root”?
Or is 3b part of the data stream? “USER foot”
If the OS makes a different decision than the monitor: bad
Even worse: different OSs have different protocol interpretations,
If they are overlapping fragments BSD IPv6 drops packet; Linux IPv6
reassembly mimics IPv4 behavior
IPv6 Fragmentation
Issues for Non-Stateful Filtering Devices
Traverse the next headers before reaching the

fragment header to extract the flags and offset
Then, further NHs before reaching the ULP
Then check if enough of the upper Layer protocol
header is within the first fragment
This makes matching against the first fragment non-
deterministic: tcp/udp/icmp might not be there

IPv6 Fragmentation:
Fragment Keyword in IPv6 ACL
fragment keyword matches
Non-initial fragments (same as IPv4)
And the first fragment if the protocol cannot be determined
Note: Cisco IOS® also supports a new keyword

"undetermined-transport"
matches any IPv6 packet where the Layer 4 cannot be
determined

Header Manipulation and Fragmentation
Best Practices
Deny IPv6 fragments destined to an internetworking

device (DOS vector)
Infrastructure ACL
Ensure adequate IPv6 fragmentation filtering

capabilities; for example, drop all packets with the
routing header 2 if you don’t have MIPv6
If really paranoid: drop all fragments with less than
1280 octets (except the last fragment)
Alas, no way to implement this yet

L3-L4 Spoofing in IPv4
L4 spoofing can be done in concert with L3 spoofing to

attack systems (most commonly running UDP, i.e.
SNMP, Syslog, etc.)
Nearly 50% of the current IPv4 space has not been
allocated or is reserved for special use (RFC3330)
making it easy to block at network ingress through
bogons filtering

L3 Spoofing in IPv6
uRPF remains the primary tool for protecting
against L3 spoofing
uRPF loose mode Inter-Networking Device with
uRPF enabled
Access IPv6
Layer X
Intranet/Internet
Spoofed IPv6 No Route to Src Addr prefix
Source Address => Drop
uRPF strict mode Inter-Networking Device with

uRPF enabled
Access IPv6
Layer X
Intranet/Internet
Spoofed IPv6 No Route to Src Addr prefix out the
Source Address packet inbound interface => Drop

IPv6 Routing Header
Routing Header IPv6 Ù
Routing Header Is: Source Routing in IPv4
An extension header
Can Be Turned Off:
Processed by the listed ’no ipv6 source-route’
intermediate routers IPv6 ACL Could Also
Be Used
Next Header = 43
IPv6 Basic Header
Routing Header
Routing Header
Routing Header
Next Header Ext Hdr Length Routing Type Segments Left
Routing Header Data

Issues with Routing Header
Could be used as a rebound/relay to the victim

Because destination address is replaced at every
routing header processing point, it's difficult to perform
traffic filtering based on destination addresses
http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-
ha-security-03.txt

Routing Header: Traffic Reflector
Rule on the Firewall:

Allow proto tcp from any to webserver port 80
Deny proto tcp from any to any
Web
Host1 src=host1,dst=web,
payload proto=tcp, dport=80
rtheader=host2, segments
left=1 src=host1,
dst=host2
rtheader=web,
segments left=0
payload proto=tcp,
IPv6 dport=80
Network Host2
Firewall

ARP and DHCP Attacks in IPv4
With ARP misuse host W can claim to be the default

gateway and hosts X and Y will route traffic through
him; => man in the middle attack
1.2.3.0/24
.1
Host Y Host X Host W

.2 .3 .4
• With DHCP it is similar except the attacker just needs

to put a DHCP server on the wire delivering false
information (gateways, DNS servers, etc.)
Stateless Autoconfiguration
Router Solicitation Are Sent By Booting Nodes to
Request Router Advertisements for Configuring
the Interfaces
1. RS 2. RA 2. RA
1. RS: 2. RA:
ICMP Type = 133 ICMP Type = 134
Src = :: Src = Router Link-local Address
Dst = All-Routers multicast Address Dst = All-nodes multicast address
query= please send RA Data= options, prefix, lifetime, autoconfig
flag

Stateless Autoconfiguration
Router Solicitation Are Sent By Booting Nodes to
Request Router Advertisements for Configuring
the Interfaces
ICMP w/o any
authentication
Gives Exactly Same
Level of Security as
1. RS 2. RA ARP For IPv4 (None)
2. RA
Bootstrap Security
Problem Just
Like IPv4
1. RS: 2. RA:
ICMP Type = 133 ICMP Type = 134
Src = :: Src = Router Link-local Address
Dst = All-Routers multicast Address Dst = All-nodes multicast address
query= please send RA Data= options, prefix, lifetime, autoconfig
flag

Neighbor Discovery: Neighbor
Solicitation
Security Mechanisms
A B Built into Discovery
Protocol = None
Another Bootstrap
Security Problem
ICMP type = 135
Src = A
Dst = Solicited-node multicast of B
Data = link-layer address of A
Query = what is your link address?
ICMP type = 136

Src = B
Dst = A
Data = link-layer address of B
A and B Can Now Exchange
Packets on This Link

DAD (Duplicate Address Detection)
Duplicate Address Detection (DAD) Uses Neighbor
Solicitation to Verify the Existence of an Address
to be Configured
A B
From RFC 2462:
« If a Duplicate @ Is
Discovered… the
ICMP type = 135 Address Cannot Be
Src = 0 (::) Assigned to the
Dst = Solicited-node multicast of A Interface»
Data = link-layer address of A Ù What If: Use MAC@
Query = what is your link address? of the Node You Want
to DoS and Fabricate
Its IPv6 @

Neighbor Discovery: Spoofed Redirect
Redirect is Used by a Router to Signal the
Re-Route of a Packet to a Better Router
In IPv4: « no ip icmp redirect »

In IPv6: « no ipv6 redirect »
A B R2
Src = A
R1 Dst IP = 2001:DB8:C18:2::1
Dst Ethernet = R2 (default router)
Redirect:
Src = R2
Dst = A
2001:DB8:C18:2::/64 Data = good router = R1

Neighbor Discovery Attacks in IPv6
RFC 3756
Redirect attacks
A malicious node redirects packets away from a legitimate
receiver to another node on the link
Denial-of-service attacks
A malicious node prevents communication between the node
under attack and other nodes
Flooding denial-of-service attacks

A malicious node redirects other hosts’ traffic to a victim node
creating a flood of bogus traffic at the victim host

Secure Neighbor Discovery (SEND)
RFC 3971
Certification paths
Anchored on trusted parties, expected to certify the authority of
the routers on some prefixes
Cryptographically Generated Addresses (CGA)

IPv6 addresses whose the interface identifier is
cryptographically generated
RSA signature option

Protect all messages relating to neighbor and router discovery
Timestamp and nonce ND options

Prevent replay attacks

Secure Neighbor Discovery and CGA
Caveats
Private/public key pair on all devices for CGA

Overhead introduced
Routers have to do many public/private key calculation (some
may be done in advance of use)
Available: Linux
Coming in Microsoft Vista SP1
Future implementation: Cisco IOS

DHCPv6 Threats
Note: use of DHCP is announced in Router

Advertisements
Rogue devices on the network giving misleading
information or consuming resources (DoS)
Rogue DHCPv6 client and servers on the network (same threat
as IPv4)
Rogue DHCPv6 servers on the site local multicast address
(FF05::1:3) (new threat in IPv6)
Tampering of communication between DHCPv6 relays

and servers

DHCPv6 Threat Mitigation
Rogue clients and servers can be mitigated by using

the authentication option in DHCPv6
There are not many DHCPv6 client or server implementations
using this today
For paranoid: protect the relay to server

communications with IPsec (similar to IPv4)

IPv4 Broadcast Amplification: Smurf
160.154.5.0
ICMP REPLY D=172.18.1.2 S=160.154.5.14

Attempt to
Overwhelm WAN
ICMP REPLY D=172.18.1.2 S=160.154.5.15
Link to
Destination
ICMP REPLY D=172.18.1.2 S=160.154.5.16
ICMP REPLY D=172.18.1.2 S=160.154.5.17

172.18.1.2
ICMP REPLY D=172.18.1.2 S=160.154.5.18
ICMP REPLY D=172.18.1.2 S=160.154.5.19
Belgian
ICMP REQ D=160.154.5.255 S= 172.18.1.2 Schtroumpf

IPv6 and Broadcasts
There are no broadcast addresses in IPv6

Broadcast address functionality is replaced with the
appropriate link local multicast address
Link Local All Nodes Multicast—FF02::1
Link Local All Routers Multicast—FF02::2

IPv6 and Other Amplification Vectors
Specific mention is made in ICMPv6 RFC that no ICMP

error message should be generated in response to a
packet with a multicast destination address
The exceptions are the packet too big message and the
parameter problem ICMP messages
RFC 2463 Section 2.4 (e.2)
Implement Ingress Filtering of Packets With

IPv6 Multicast Source Addresses
Throttle Above ICMP Packet Types

Preventing IPv6 Routing Attacks
Protocol Authentication
BGP, ISIS, EIGRP no change:

An MD5 authentication of the routing update
OSPFv3 has changed and pulled MD5 authentication

from the protocol and instead is supposed to rely on
transport mode IPsec
RIPng also relies on IPsec
IPv6 routing attack best practices
Use traditional authentication mechanisms on BGP
and IS-IS
Use IPsec to secure protocols such as OSPFv3 and RIPng

Viruses and Worms in IPv6
Pure viruses don’t change in IPv6 but hybrid and pure

worms do
Hybrid and pure worms today rely on Internet scanning to infect
other hosts, this isn’t feasible as shown earlier in this
presentation
At one million packets per second on a IPv6 subnet with 10,000
hosts it would take over 28 years to find the first host to infect
Worm developers will adapt to IPv6 but pure random

scanning worms will be much more problematic for the
attacker; IPv4 best practices around worm detection and
mitigation remain valid

IPv6 Attacks with Strong IPv4
Similarities
Sniffing
Without IPsec, IPv6 is no more or less likely to fall victim to a sniffing
attack than IPv4
Application layer attacks
Even with IPsec, the majority of vulnerabilities on the Internet today are
at the application layer, something that IPsec will do nothing to prevent
Rogue devices
Rogue devices will be as easy to insert into an IPv6 network as in IPv4
Man-in-the-Middle Attacks (MITM)
Without IPsec, any attacks utilizing MITM will have the same likelihood
in IPv6 as in IPv4
Flooding
Flooding attacks are identical between IPv4 and IPv6

By the Way: It Is Real /
IPv6 Hacking Tools
Let the Games Begin
Sniffers/packet capture Scanners
Snort IPv6 security scanner
TCPdump Halfscan6
Sun Solaris snoop Nmap
COLD Strobe
Ethereal Netcat
Analyzer
DoS Tools
Windump
6tunneldos
WinPcap
4to6ddos
NetPeek
Imps6-tools
Sniffer Pro
Packet forgers
Worms SendIP
Slapper
Packit
Advisories/field notices Spak6
http://www.cisco.com/warp/public/707/ci
sco-sa-20050126-ipv6.shtml Complete tool
http://www.kb.cert.org/vuls/id/658859 http://www.thc.org/thc-ipv6/

By the Way: It Is Real /
IPv6 Hacking Tools
Let the Games Begin
Sniffers/packet capture Scanners
Snort IPv6 security scanner
TCPdump Halfscan6
Sun Solaris snoop Nmap
COLD Strobe
Ethereal Netcat
Analyzer
DoS Tools
Windump
6tunneldos
WinPcap
4to6ddos
NetPeek
Imps6-tools
Sniffer Pro
Packet forgers
Worms SendIP
Slapper
Packit
Advisories/field notices Spak6
http://www.cisco.com/warp/public/707/ci
sco-sa-20050126-ipv6.shtml Complete tool
http://www.kb.cert.org/vuls/id/658859 http://www.thc.org/thc-ipv6/

Specific IPv6
Issues
Issues applicable only to IPv6

IPv6 Transition Mechanism Challenges
Dual stack
Consider security for both protocols
Cross v4/v6 abuse
Resiliency (shared resources)
Tunnels
Bypass firewalls (protocol 41)

IPv6 Dual Stack Host Considerations
Host security on a dual-stack device

Applications can be subject to attack on both IPv6 and IPv4
Host security controls should block and inspect traffic

from both IP versions
Host intrusion prevention, personal firewalls, VPN
clients, etc.
IPv4 IPsecVPN with

No Split Tunneling
Dual Stack Client

IPv6 HDR IPv6 Exploit
Does the IPsec Client Stop an
Inbound IPv6 Exploit?

IPv6 Tunneling Summary
RFC 1933/2893 configured and • Only allow authorized endpoints to

automatic tunnels establish tunnels
RFC 2401 IPsec tunnel • Static tunnels are deemed as “more
secure,” but less scalable
RFC 2473 IPv6 generic
packet tunnel • Automatic tunneling mechanisms
are susceptible to packet forgery
RFC 2529 6over4 tunnel
and DoS attacks
RFC 3056 6to4 tunnel
• These tools have the same risk as
ISATAP tunnel IPv4, just new avenues of exploitation
MobileIPv6 (uses RFC2473) • Automatic IPv6 over IPv4 tunnels
could be secured by IPv4 IPsec
Teredo tunnels

When Using IPv6 over IPv4 Tunnels
Most IPv4/IPv6 transition mechanisms have no authentication built in
=> an IPv4 attacker can inject traffic if spoofing IPv4 and IPv6 addresses
Spoofed Packet Response

IPv6 ACLs Are Ineffective
(TCP SYN-ACK, ICMPv6
Since IPv4 & IPv6 are Spoofed
Echo, etc.) is Returned to
Tunnel Termination Forwards the Spoofed IPv6 dst.
Inner IPv6 Packet
IPv4
IPv6
Public IPv4
Internet
IPv6 Network IPv6 Network
IPv6 in IPv4
tunnel
Tunnel Tunnel
termination termination
Server A Server B
Dos Via Tunnels
Harm is limited
1:1 ratio of packets—no amplification attack
There is a chokepoint against DoS
Return traffic is not received by attacker
Public IPv4
Internet
IPv6 Network IPv6 Network
IPv6 in IPv4
tunnel
Server A Server B
IP Mobility
2001:db8:c18::1
Correspondent Node
Home Agent
Mobile Node
Optimized Routing
Not Possible in IPv4
Mobile Node
2001:2:a010::5
Mobility Means:
Mobile devices are fully supported while moving
Built-in on IPv6
Any node can use it
Optimized routing means performance for end-users
Filtering challenges
Mobile IPv6 Security Features Overview
Protection of binding updates both to home agents and

correspondent nodes
IPsec (specially for HA),
Or binding authorization data option through the return
routability procedure
Protection of mobile prefix discovery

Through the use of IPsec extension headers
Protection of data packets transport

Home address destination option and type two routing header
specified in a manner which restricts their use
in attacks

IPv6 Security
Best Practices

Wrap Up: Candidate Best Practices
Implement privacy extensions carefully
Filter internal-use IPv6 addresses at the enterprise
border routers
Filter unneeded services at the firewall
Selectively filter ICMP
Maintain host and application security
Determine what extension headers will be allowed through
the access control device
Determine which ICMPv6 messages are required
Deny IPv6 fragments destined to an internetworking device
when possible
Ensure adequate IPv6 fragmentation filtering capabilities
Drop all fragments with less than 1280 octets (except the
last one)

Wrap Up: Candidate Best Practices
(Cont.)
Implement RFC 2827-like filtering
Document procedures for last-hop traceback
Use cryptographic protections where critical
Use static neighbor entries for critical systems
Implement ingress filtering of packets with IPv6
multicast source addresses
Use authentication mechanisms on BGP and IS-IS
Use IPsec to secure protocols such as OSPFv3 and
RIPng
Use static tunneling rather than dynamic tunneling
Implement outbound filtering on firewall devices to
allow only authorized tunneling endpoints
Enforcing a
Security Policy

Cisco IOS IPv6 Access Control Lists
Can filter traffic based on source and

destination address
Can filter traffic inbound or outbound to a specific
interface
Implicit "deny all" at the end of access list
Very much like in IPv4

Cisco IOS IPv6 Access Control Lists
Filtering Outgoing Traffic from One
Specific Source Address
2001:db8:2c80:1000::1
2001:db8:2c80:1000::/64
ipv6 access-list BLOCK
deny 2001:db8:2c80:1000::1/128 any IPv6 Internet
permit 2001:db8:2c80:1000::/64 any
interface Ethernet0
ipv6 traffic-filter BLOCK out Ethernet0
Global Prefix: 2001:db8:2c80:1000::/64

Filtering Extension Headers
IPv6 headers and optional extensions need to be

scanned to access the upper layer protocols (UPL)
May require searching through several
extensions headers
Important: a router must be able to filter both option
header and L4 at the same time

IPv6 Extended Access Control Lists
Upper layers : ICMP, TCP, UDP, SCTP, any value

ICMPv6 code and type
TCP SYN, ACK, FIN, PUSH, URG, RST
L4 port numbers
Traffic class (only six bits/8) = DSCP
Flow label (0-0xFFFFF)
IPv6 header options
Fragments
Routing header type
Destination header type
IPv6 ACL Implicit Rules
Implicit Permit for Enable Neighbor Discovery
The following implicit rules exist at the end of each IPv6

ACL to allow ICMPv6 neighbor discovery:
permit icmp any any nd-na

permit icmp any any nd-ns
deny ipv6 any any
Be careful when adding « deny ipv6 any any

log » at the end

IPv6 ACL to Protect VTY
ipv6 access-list VTY

permit ipv6 2001:db8:0:1::/64 any
line vty 0 4
ipv6 access-class VTY in

Control Plane Policing for IPv6
Protecting the Router CPU
Against DoS with Neighbor Discovery,

Can also throttle IPv6 traffic when processed in SW
while IPv4 is in HW (legacy platform)
In doubts: show proc cpu | include IPv6
class-map match-all ipv6
match protocol ipv6
policy-map CoPP
class ipv6
police rate 100 pps
conform-action transmit
exceed-action drop
control-plane
service-policy input CoPP

Cisco IOS Firewall IPv6 Support
Stateful protocol inspection (anomaly detection) of IPv6 fragmented
packets, TCP, UDP, ICMP and FTP traffic
Stateful inspection and translation services of IPv4/IPv6 packets
IPv6 DoS attack mitigation
IPv4/v6 coexistence, no need for new hardware, just software
Recognizes IPv6 extension header information such as routing header,
hop-by-hop options header, fragment header, etc
IPv6 Router with

IPv4 IPv6 Router with
Cisco IOS Firewall IPv6
Site 3 Cisco IOS Firewall
IPv6 Router with Dual Stack Site 1
Cisco IOS Firewall Router
IPv6 Internet (IPv4)
Site 2 IPv6 IPv6
IPv6 Router with

Cisco IOS Firewall

ASA and PIX Firewall IPv6 Support
Recognition of IPv6 traffic

Dual-stack, IPv6 only, IPv4 only
Extended IP ACL with stateful inspection

Application awareness
HTTP, FTP, telnet, SMTP, TCP, SSH, UDP
uRPF
v6 Frag guard
IPv6 header security checks
Management access via IPv6
Telnet, SSH, HTTPS

6PE/6VPE Security
Considerations

Threats
Attack P or PE routers.
Attack CE routers.
Similar threats as for RFC2547bis.

Attack Vector – Target SP’s Router
Target
Target the
the SP’s
SP’s PE
PE or
or P
P router.
router.
PEER Network
Need
Need IP
IP address
address to
to target.
target.
6PE-3
Border Router
CE1 MPLS Backbone CE3
6PE-1
6PE-2
CE4
CE2

1.
1. Do
Do Not
Not advertise
advertise PP or
or PE
PE router’s
router’s
Loopback
Loopback
PEER Network 2.
2. Do
Do Not
Not advertise
advertise PE-CE
PE-CE block
block to
to
the
the IGP
IGP (Aggregated
(Aggregated Null
Null 00 on
on the
the
Border will drop the attack.)
Border will drop the attack.)
Infrastructure IPv6 3. iACLs
iACLs with
with Engine
Engine 3,
3, 55 on
on the
6PE-3 3. Border
Border Router
Router as
as aa backup.
backup.
the
ACL as Backup Border Router
Infrastructure IPv6
PE-CE Aggregate to Do no advertise
CE1 MPLS Backbone
IPv6 PE-CE to IGP CE3
Null 0
6PE-1
6PE-2
CE4
CE2
Do no advertise
IPv6 Loopbacks
Failsafe:
Failsafe: rACL/CoPP
rACL/CoPP –– Point
Point
protection
protection on
on the
the router
router in
in case
case the
the
primary
primary defenses
defenses fail.
fail.
PEER Network
6PE-3
Border Router
IPv6 rACL or CoPP
Point Protection
6PE-1
6PE-2
CE4
CE2

Attack Vector – Target CE Routers
Target
Target the
the Customer’s
Customer’s CE
CE Router.
Router.
PEER Network
Need
Need IP
IP address
address to
to target.
target.
6PE-3
Border Router
6PE-1
6PE-2
CE4
CE2

Attack Vector – Target CE Routers (Net
Flap)
Target
Target the
the Customer’s
Customer’s Network
Network
Saturated
Saturated Link
Link Drops
Drops connection.
connection.
PEER Network
DOS
DOS Flaps
Flaps between
between Customer
Customer and
and
Aggregate.
Aggregate.
Attack Goes to
Aggregate 6PE-3
Border Router
6PE-1
6PE-2
CE4
CE2 Link Drops – Interface
Drops, Customer’s IPv6
Block loses access path
Link Back Up
Attack Vector – Target CE Routers (Local Flap)
Target
Target the
the Customer’s
Customer’s Network
Network
Saturated
Saturated Link
Link Drops
Drops connection.
connection.
PEER Network
DOS
DOS Flaps
Flaps between
between Customer
Customer and
and
Aggregate.
Aggregate.
6PE-3
Border Router Attack Goes to
Aggregate
6PE-1
6PE-2
CE4
CE2 Link Drops – Interface
Drops, Customer’s IPv6
Block loses access path
Link Back Up
6PE/6VPE Security Considerations
Revealing the addresses of the IPv4 infrastructure
through IPv6 traceroutes:
CE#traceroute 2001:6FC::1
Type escape sequence to abort.
Tracing the route to 2001:6FC::1
1 ::FFFF:172.20.25.1 [MPLS: Labels 38/73 Exp 0] 40 msec 32 msec 32 msec
2 ::FFFF:172.20.10.1 [MPLS: Labels 30/73 Exp 0] 60 msec 32 msec 32 msec
3 2001:6FC::1 [MPLS: Label 73 Exp 0] 32 msec 32 msec 16 msec
no mpls ip propagate-ttl forwarded

CE#traceroute 2001:6FC::1
Type escape sequence to abort.
Tracing the route to 2001:6FC::1
1 2001:6FC::26 [AS 33751] 32 msec 32 msec 20 msec
2 2001:6FC::1 [AS 33751] [MPLS: Label 73 Exp 0] 20 msec 20 msec 20 msec
3 2001:6FC::1 [AS 33751] 28 msec 20 msec 20 msec

6VPE Security Considerations
Revealing the addresses of the IPv6 infrastructure within

the VPN:
An IPv6 address must be assigned on the PE for each
VPN (CE-PE link). It is necessary for operational
purposes.
With 6VPE the prefixes must be blocked specifically
because there is no NAT.

Q and A

Cisco Press Books


IPv6-Session-Market and Technology

Uploaded by

Copyright:

Available Formats

IPv6-Session-Market and Technology

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IPv6-Session-Market and Technology

Uploaded by

Copyright:

Available Formats

IPv6

- Market and Technology -

© 2009 Cisco Systems, Inc. All rights reserved. 1

© 2009 Cisco Systems, Inc. All rights reserved. 2

 Adoption Challenges  IPv6 Security Best Practices

 Conclusions  Enforcing a Security Policy in IPv6

© 2009 Cisco Systems, Inc. All rights reserved. 3

© 2009 Cisco Systems, Inc. All rights reserved. 4

© 2009 Cisco Systems, Inc. All rights reserved. 5

IPv6 is not a Revolution, it is an Evolution!

IPv6 does not interoperate with IPv4

© 2009 Cisco Systems, Inc. All rights reserved. 6

32-bit, Network 128-bit, Multiple

RIPv2, EIGRP, RIPng, EIGRPv6,

© 2009 Cisco Systems, Inc. All rights reserved. 7

IP Multicast IGMP/PIM/Multicast MLD/PIM/Multicast

Differentiated Service, Differentiated Service,

Security IPSec IPSec Mandated,

Mobile IP Mobile IP with Direct

© 2009 Cisco Systems, Inc. All rights reserved. 8

IPv6 mobility services are True, primarily due to cleaner

1994 199 5-1998

© 2009 Cisco Systems, Inc. All rights reserved. 10

© 2009 Cisco Systems, Inc. All rights reserved. 11

Argument and Practice

© 2009 Cisco Systems, Inc. All rights reserved. 12

Argument* and Practice**

Full discussion at: www.cisco.com/ipj

 Consumption is accelerating despite

increasingly intense conservation 1.5

NAT (network address translation) 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09

 Growth is occurring in all regions

© 2009 Cisco Systems, Inc. All rights reserved. 14

Argument and Practice

Not enough private IPv4 MSOs are aggressively

Argument and Practice

© 2009 Cisco Systems, Inc. All rights reserved. 16

© 2009 Cisco Systems, Inc. All rights reserved. 17

IPv6 offers another shot at leadership in IT

© 2009 Cisco Systems, Inc. All rights reserved. 18

1. Government encouragement + financial and legal

© 2009 Cisco Systems, Inc. All rights reserved. 19

 Acquired IPv6 Address space:

 Interoperability testing – Moonv6

© 2009 Cisco Systems, Inc. All rights reserved. 20

 Acquired IPv6 Address space:

 Some agencies designed addressing scheme, requested

© 2009 Cisco Systems, Inc. All rights reserved. 22

© 2009 Cisco Systems, Inc. All rights reserved. 23

• IPv4 or MPLS Core Infrastructure is IPv6 unaware

© 2009 Cisco Systems, Inc. All rights reserved. 24

© 2009 Cisco Systems, Inc. All rights reserved. 25

© 2009 Cisco Systems, Inc. All rights reserved. 26

LSP setup: iGP + LDP

router bgp 100

© 2009 Cisco Systems, Inc. All rights reserved. 27

• 6VPE ~ IPv6 + BGP-MPLS IPv4 VPN + 6PE

© 2009 Cisco Systems, Inc. All rights reserved. 28

 New components for VPNv6

© 2009 Cisco Systems, Inc. All rights reserved. 29

Adoption Challenges IPv6 Security Best Practices

Conclusions Enforcing a Security Policy in IPv6

Consumption is accelerating despite

Growth is occurring in all regions

Acquired IPv6 Address space:

Interoperability testing – Moonv6

Acquired IPv6 Address space:

Some agencies designed addressing scheme, requested

New components for VPNv6

Beyond the ISP boundary there are allocation

In practice, it is most likely that the allocations below

Service Providers prefer Statefull over Stateless:

The similarity between the IPv6 and IPv4 routing protocols

In dual-stack deployments, IPv6 will add network

Threat Analysis based mainly on the experience of

Initiate the Education and Training process –you need

IPv6 stack implementation inconsistencies, particularly as

Feature parity between IPv4 and IPv6 is improved as

Lack of feature parity between IPv4 and IPv6 would limit