Tecrst 2001

#CLUS
Designing and
Deploying a Secure
IPv6 Network
Timothy Martin - @bckcntryskr
Eric Vyncke - @evyncke
Christopher Werny - @bcp38_
TECRST-2001
#CLUS
Agenda
• IPv6 Design Considerations
• IPv6 Routing Protocols
• IPv6 Translation Technologies
• IPv6 Only, A case study
• Securing the IPv6 Perimeter
• Conclusion
#CLUS TECRST-2001 © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 3
Cisco Webex Teams
Questions?
Use Cisco Webex Teams to chat
with the speaker after the session
How
1 Find this session in the Cisco Live Mobile App
2 Click “Join the Discussion”
3 Install Webex Teams or go directly to the team space
4 Enter messages/questions in the team space
Webex Teams will be moderated cs.co/ciscolivebot# TECRST-2001

by the speaker until June 16, 2019.
#CLUS © 2019 Cisco and/or its affiliates. All rights reserved. Cisco Public 4
IPv6
Design Considerations
Tim Martin
Solutions Specialist
TECRST-2001
@bckcntryskr
#2020
#CLUS
Hardening IPv6 Management Plane
• SSH, SNMPv3, Syslog, NTP, NetFlow v9
• Disable HTTP/HTTPS access if not needed
• RADIUS over IPv6
• IPv6 access-class for SSH VTY access
• Important: Harden the router, before enabling routing
ipv6 access-list V6ACCESS
permit ipv6 2001:db8:10:10::1/128 any
deny ipv6 any any log-input
line vty 0 4
ipv6 access-class V6ACCESS in
transport input ssh
Routing Protocol Considerations
• Enable IPv6 routing
• ipv6 unicast-routing (ios)
• no switchport (ios-xe)
• IPv6 Next Hop
• Link local addresses
• Global address on interface not required
• Topology & alignment with existing RP’s Management Routing
• Router ID Switching Services

• Unique 32-bit number identifier 
Routing Design Considerations
ipv6 route ::/0 gigabitethernet0/1
• Do you need to accept the full table
ipv6 router eigrp 123
• Memory, processing, capital.. eigrp stub
• Single router, single circuit ipv6 router ospf 1

• Take a default route router-id 3.3.3.3
area 2 stub
• Dual router, private circuit
• Use stub command from IGP interface Fastethernet0/1
ipv6 address 2001:db8:46:67::a
• Dual router, Internet circuit bfd interval 222 min_rx 222 multiplier 3
!
• Take default from provider router bgp 65110
neighbor 2001:db8:46:67::b fail-over bfd
• Bidirectional forwarding detection
Point-to-Point Routed Links
• Use a prefix length of /127
• Reserve the /64, configure the /127
• Nodes 1 & 2 are NOT in the same subnet
• Suppress RAs for global assigned addressing

• Disable ICMPv6 redirects interface FastEthernet0/1
ipv6 address 2001:db8:46:67::a/127
• Don’t send ICMPv6 unreachable
ipv6 nd ra suppress
• RFC 7404, Link local only no ipv6 redirects
2001:db8:46:67::/127 no ipv6 unreachables
::a ::b
Static Routing
• Link Local Next Hop ipv6 unicast-routing
• Redistribution needs GUA or ULA !direct
ipv6 route 2001:db8:1::/48 ethernet1/0
• Direct (interface) !recursive
• Recursive (next hop) ipv6 route 2001:db8:5::/48 2001:db8:4::1

!fully qualified
• Fully qualified (interface) (next hop) ipv6 route 2001:46::/32 ethernet0/0 fe80::9
• Default route ::/0 !default

ipv6 route ::/0 ethernet0/2 fe80::2
IPv6 Routing
Protocols
OSPFv3
ipv6 unicast-routing
!
• OSPFv3 – IP 89 interface loopback0
• fe80::/64 Source  ff02::5, ff02::6 (DR’s) ipv6 address 2001:db8:1000::1/128
• Link-LSA (8) – Local Scope, NH ipv6 ospf 46 area 0
• Intra-Area-LSA (9) – Routers’ Prefixes !
interface ethernet 0/0
• LSA’s Disconnect topology from prefixes
ipv6 address 2001:db8:50:31::1/64
• Can converge quickly to a point of scale ipv6 ospf 46 area 0
• Initial database build takes time !
ipv6 router ospf 46
router-id 4.6.4.6
passive-interface loopback0
LSPs* full mesh

OSPFv3 AF Support
router ospfv3 46
• Multiple AF’s (RFC5838) router-id 4.6.4.6
!
• Legacy IPv4 prefixes address-family ipv6 unicast
• IPv6 prefixes passive-interface Loopback 0
exit-address-family
• Transport over IPv6 !
address-family ipv4 unicast
• Common elements passive-interface Loopback 0
• Neighbor table exit-address-family
!
• Link State Data Base (LSDB) interface GigabitEthernet 0/2
• Show command structure ip address 192.168.4.1 255.255.255.0
ipv6 enable
• ip ospf (IPv4 over OSPFv2) ospfv3 46 ipv4 area 0
ospfv3 46 ipv6 area 0
• ipv6 ospf (IPv6 over OSPFv3)
sh ip route ospfv3
OSPFv3 Authentication
• AH for authentication (RFC4552) interface Ethernet0/0
ipv6 ospf 46 area 0
• Manual key process ipv6 ospf authentication ipsec spi 500 sha
• ESP could be used for confidentiality 1234567890ABCDEF1234567890ABCDEF
• Need a security license for IPsec
key chain AUTH
• RFC7166 Authentication Trailers key 1
• Anti-replay key-string RFC
• HMAC-SHA-1, 256, 384, 512 cryptographic-algorithm hmac-sha-512
!
address-family ipv6 unicast
authentication mode strict
area 0 authentication key-chain AUTH
Classic EIGRP or EIGRPv6
• EIGRP – IP 88 !
Interface ethernet 0/0
• fe80::/64 Source  ff02::a Destination ipv6 address 2001:db8:1000::1/128
• No shutdown for older versions ipv6 eigrp 46
!
• Apply the route process to interfaces interface ethernet 0/1
• Auto Summary disabled ipv6 address 2001:db8:50:31::1/64
ipv6 eigrp 46
• Transport & peering over IPv6 !
ipv6 router eigrp 46
no shutdown
eigrp router-id 4.6.4.6
EIGRP Named Mode
router eigrp IPv6rocks
!
• Name creates a virtual instance address-family ipv6 unicast
• Does not need to be common in domain autonomous-system 46
!
• Address family configures protocol instance af-interface Loopback0
passive-interface
• AS number must common within domain exit-af-interface
!
• Auto Applied to all IPv6 enabled interfaces af-interface Ethernet0/0
exit-af-interface
• No need to configure under the interfaces
eigrp router-id 4.6.4.6
exit-address-family
Large-scale hub
and spoke
environments
EIGRP Authentication
• EIGRP supports HMAC-SHA-256
• To generate or validate messages, hash is constructed using:
• Configured shared secret
• Link Local address of sender
• EIGRP packet prior to adding the IP header
!
router eigrp IPv6rocks
address-family ipv6 autonomous-system 46
af-interface ethernet 0/0
authentication mode hmac-sha-256 0 Cisco123
!
IS-IS ipv6 unicast-routing
!
• Single topology mode ipv6 address 2001:db8:5000:31::1/64
• Single LSDB, single cost ipv6 router isis CISCO
isis circuit-type level-1
• Links must be congruent (dual stacked)
isis ipv6 metric 10000
• Multi topology mode isis authentication mode md5
• LSDB & cost per protocol !

router isis CISCO
• Flexible, transition mode available
net 49.0001.2222.2222.222.00
• Authentication uses MD5 (TLV) metric style wide
!
A B C A B C A B C address-family ipv6
D E D E D E multi-topology
Physical Topology IPv4 SPT IPv6 SPT
SPs, Underlay’s
RIPng
• RIPng – UDP 521, 15 hops !
• fe80::/64 Source  ff02::9 Destination interface loopback 0
ipv6 address 2001:db8:1000::1/128
• Distance Vector, Hop Count (1-15) ipv6 rip CISCO enable
• Split Horizon, Poison Reverse !
• Lightweight IPv6 only protocol ipv6 address 2001:db8:5000:31::1/64
• Uses AH for authentication ipv6 rip CISCO enable
!
ipv6 router rip CISCO
Star topology,
single path edge
devices
IPv6 BGP &
Multihome
Network Prefix Translation IPv6
• RFC 6296 - NPTv6
Translators attached to internal network
Internet
•
• Unique Local Addressing (ULA) inside
• Provider allocated addressing outside
• Swaps Left Most Bits of Address

• Equal length Prefixes 2001:db8:46::/48
• Small-to-Medium Enterprise
interface GigabitEthernet0/0/0 fd07:18:4c::/48
nat66 inside
interface GigabitEthernet0/0/1
nat66 outside
!
nat66 prefix inside fd07:18:4c::/48 outside 2001:db8:46::/48
Multihomed, Multiprefix (BGP)
• Solve for Ingress & Egress separately Internet
• Peer over IPv6 for IPv6 prefixes ISP A ISP B
• Controlling hop limit, accepting ~254 only

• MD5, AH possible, next-hop-self (fe80::)
• Prefix Size Filtering, /32 - /48
router bgp 200
bgp router-id 4.6.4.6
no bgp default ipv4-unicast
neighbor 2001:db8:460:102::2 remote-as 2014
neighbor 2001:db8:460:102::2 ttl-security hops 1
neighbor 2001:db8:460:102::2 password cisco4646
Solving Ingress
Ingress
• Equal load distribution
• Advertise more specific /45 & /44
Internet
• Non equal load distribution ISP A ISP B
AS 64499 AS 64497
• Use AS path prepend, if accepted 2001:db8:a1::/32 2001:db8:b1::/32
ipv6 prefix-list ISPAout seq 5 2001:db8:460::/44

ipv6 prefix-list ISPAout seq 10 2001:db8:460::/45
!
ipv6 prefix-list ISPBout seq 5 2001:db8:460::/44
ipv6 prefix-list ISPBout seq 10 2001:db8:468::/45
2001:db8:460::/44
Enterprise Domain
neighbor 2001:db8::b1 route-map ISPBout out
!
route-map ISPBout permit 10
set as-path prepend 64498 64498 64498 64498
Solving Egress
• Accept the full table from provider A
• Filter everything except the aggregate 2001::/18
Internet
• Accept the full table from provider B ISP A ISP B
AS 64499 AS 64497
• Use local-preference for ::/0 2001:db8:a1::/32 2001:db8:b1::/32
ipv6 prefix-list ISPAin seq 5 permit ::/0
ipv6 prefix-list ISPAin seq 10 permit 2001:0000::/18 le 32
Egress
neighbor 2001:db8::b1 prefix-list ISPBin seq 5 permit ::/0
neighbor 2001:db8::b1 route-map LOCAL in
! 2001:db8:460::/44
Enterprise Domain
ipv6 prefix-list ISPBin seq 5 permit ::/0
route-map LOCAL permit 10
set local-preference 200
Layer 2 Adjacent Firewall
• Firewalls are redundant and share state
Internet
• Common VLAN between the firewalls & routers ISP A ISP B
• Hot Standby Router Protocol (HSRP)

• Default routes on firewall to HSRP groups HSRP 1
! Send first aggregate block to HSRP Group 1 HSRP 2
ipv6 route outside 2001:0000::/18 2001:db8:46::1
! Send Second aggregate block to HSRP Group 2 VLAN 46
Layer 3 Adjacent Firewall
• IGP between edge routers & Layer 3 switch
Internet
• EIGRP, OSPF, iBGP, IS-IS
ISP A ISP B
• Edge routers redistribute ::/0 (or Prefixes) into IGP
• Layer 3 Switch has static route for PI address
::/0
• Set to next-hop of the firewall
• Firewall has a default route 2001:db8:46::/44
• Pointed at the Layer 3 switch

ip route outside ::/0 2001:db8:37::1
Multihomed, Multisite
Internet
• Internet connectivity is split across two data centers ISP A ISP B
• Each firewall is active; state is not shared
AS 64498
• Advertising the /44 out both could cause asymmetry
• NAT solves this problem for the legacy protocol
• More specific routes plus aggregate needed for IPv6
• IPv6 will require an iBGP peer link at Internet edge

• Protects against failure
• Provides better outbound load distribution
AS 65535 AS 65534
• Alternatives exist, use with caution
Subnets Subnets
• GRE thru the DCI link X,Y,Z EIGRP 46 A,B,C
• Layer 3 VPN service over ISP
Multisite Egress Traffic Engineering
Internet
• Create eBGP multihop link to the core routers ISP A ISP B
• Advertise default route over this link to core routers AS 64498
• Redistribute the default route into the IGP

• Increase the metric for the default route
router bgp 65535
neighbor 2001:db8:460:66::2 remote-as 64498 ::/0
neighbor 2001:db8:460:66::2 ebgp-multihop 255
::/0
!
router eigrp 46 AS 65535 AS 65534
redistribute bgp 65535 metric * * * * * route-map BGP-EIGRP ::/0
! >M
ipv6 prefix-list DEFAULT seq 5 permit ::/0 EIGRP 46
!
route-map BGP-to-EIGRP permit 10
match ip address prefix-list DEFAULT
Multisite Ingress Traffic Engineering
Internet
• Redistribute subnets from IGP into BGP ISP A ISP B
• Use a route map with set command X,Y,Z <MED A,B,C <MED
A,B,C >MED AS 64498 X,Y,Z >MED
• Internet edge routers install prefixes

• bgp always-compare-med
router bgp 65535
neighbor 2001:db8:460:66:2 remote-as 64498
neighbor 2001:db8:460:66:2 ebgp-multihop 255
redistribute eigrp 46 route-map MED
! AS 65535 AS 65534
route-map MED permit 10
match ipv6 prefix-list SUBS Subnets Subnets
set metric 200 X,Y,Z X,Y,Z EIGRP 46 A,B,C
A,B,C
!
ipv6 prefix-list SUBS seq 10 permit 2001:db8:460::/45
Enterprise IPv6 Guidance
• RFC 7381 enterprise IPv6 guidelines

• Updated white paper – Cisco.com
• Routed access, routed host, IPv6 only?
Access
Si Si Si Si Si Si
Distribution
Core Si Si
Distribution Si Si
Si Si
Si
Si
Access
WAN Data Center Internet
IPv6
Host OS Behavior
Christopher Werny
TECRST-2001
@bcp38_ Make the world a safer place
#CLUS
Introduction &
Motivation
Motivation of this Presentation
• We are involved in a project where $COMPANY plans to enable
IPv6 in up to 10K WiFi hotspots in supermarkets in Western Europe
• (with expected 50-100k concurrent users)
• One of the first questions discussed during the initial meeting(s)

• Shall we go Dual-stack or v6-only?
Motivation of this Presentation
• An increasing number of organizations
currently consider implementing IPv6 in
a specific mode often called “v6-only +
NAT64”.
• Some conferences already implement
this in their WiFi networks:
• Troopers ;-)
• FOSDEM
• Cisco Live Europe
https://insinuator.net/2019/02/some-notes-on-the-ipv6-properties-
of-the-wireless-network-cisco-live-europe/
Why an IPv6-only
Deployment might
make sense
Diffusion of Innovations
• Theory that seeks to explain how
new ideas and technology spread.
• The more consumers will adopt a

certain technology, the market
share will reach a saturation level.
• Where are we today in regards to

IPv6 adoption?
• Hint: Keep that 34% in mind ;-)
https://en.wikipedia.org/wiki/Diffusion_of_innovations
Operational Implications
• Dual Stack increases the overall complexity of the network significantly
• Everything (on the infrastructure level) needs to be maintained for both

protocols
• Routing Protocols
• Security Policy
• QoS
• Yadda...yadda....yadda
• Depending on the environment, more layers of NAT are necessary

• Mergers & Acquisition et. al.
IPv4 is getting Expensive
• Prices have gone up steadily in the last couple of years.
• Currently, a /16 equates to 1.245.165$

• 19$ per address
• Prices for smaller network are even higher

• 26$ per address for a /24
Translation Technologies in IPv6-only
Environments – NAT64 & 464xlat
IPv6 Translation Technologies
• Going IPv6-only without a translation mechanism is currently not a
feasible solution.
• 73% of all Websites are still IPv4-only 
• In order to ensure a smooth user experience, packets need to be

translated from IPv6 to IPv4 to provide connectivity to v4-only
resources
NAT64 / DNS64
• Stateful NAT64 is a mechanism to translate IPv6 packets to IPv4
and vice-versa.
• A specific (arbitrary) prefix (/96) from your address space will be used for
translation.
• NAT64 is in basically all deployments used in conjunction with

DNS64.
• DNS64 sythesis AAAA records from A records

• As the IPv6-only systems is only asking for AAAA records.
NAT64 & DNS64 in Action
DNS64
2.
IPv6-Only Client 1.
3.
4.
NAT64
6.
5.
IPv6-only internal network
User Experience Tests
Some Statistics from our ASR @Troopers
NAT64 & DNS64
• Works reliable for
• TCP
• UDP
• ICMP
• Does not work for protocols that embed IPv4 literals in the payload of
the packet
• FTP
• SIP
• Separate ALG necessary if translation of these packets shall succeed
464XLAT
Background
• Some Network Elements do not support dual stack.
• T-Mobile has successfully deployed IPv6-only networks.
• Full control on mobile devices and only allow IPv6-only compatible

devices.
Mobile Provider Using IPv6 Only
• Legacy applications using embedded literals in their code
• RFC6877 464xLAT, “fixes” broken code for now
Handset Carrier Network Internet

Legacy
Application
Edge
Services
IPv4
4 IPv6 4
CLAT only PLAT
6 6
Intelligent IPv6
Application
3 Use Cases in IPv6 only
• End-to-end IPv6: Facebook, Google, Wikipedia, Yahoo, Youtube …
IPv6IPv6
• Application supports IPv6 (web browser),

but the server is only IPv4, so DNS64/NAT64 translates IPv6IPv4
• Application does not support IPv6, the client must provide a

stateless NAT46 to the application and stateful NAT64 must be in
the network: IPv4IPv6IPv4
Coming back to
the Case Study….
Case Study
• $COMPANY plans to enable IPv6 in up to 3K Wi-Fi hotspots in
supermarkets in Western Europe
• Dual-stack or v6-only?
• Free offering → no SLAs
• But still they’d like to avoid “discussions which could affect their
brand”.
Strategy / Decisions
• Dual-Stack vs. v6-only (+NAT64)
• From “IPv6 perspective” the most important one
• Lots of misinformation floating, in different circles

• Which is why we built the lab -> covered in a second
• Thoroughly consider users, platforms, applications and

expectations.
• Timeline might play a role, too.
Strategy / Decisions
• Audience
• Expectations ( communication)
• Types of devices (platforms, OSs, versions!)
• Types of applications (e.g. gaming vs. VPN clients)
• Requires
• Definition
• Testing
• Communication & mgmt/sponsor approval
Stuff That Might Have Issues
• As of 06/2019 (→ issues might b gone 07/2019…)
• Gaming (namely multiplayer)
• VPN clients
• But a lot of things (progress) seem to happen in this space right now.
• Please note: it is crucial that you perform your own testing if

needed. This exact slide should *not* be used to spread FUD in
future discussions ;-)
Types of Connections / Initial Thoughts
Will most certainly work. +
Initial Thoughts Very likely to work, but individual apps might expose problems.
Unclear. Will heavily depend on specific circumstances.
++
?
Problems to be expected. –
Connection Endpoint
IPv6 IPv4
Type of Client Device All Web Fat VPN VPN Other
Client/ Client Client
App (SSL) (IPsec)
Smartphones iOS ++ ++ + ++ – +
Android ++ ++ ++ ++ – +
Other ++ ++ + ++ – +
Laptops Windows,
++ ++ + ++ – +
Pre–10
Windows 10 ++ ++ ++ ++ – +
Other ++ ++ ? ++ – +
Other IoT Devices ++ ++ ? ++ – +
From FOSDEM: IPsec VPN Clients & v6-only
• When we look into the legacy dual stack network,
we notice that for the IPv4 traffic distribution we
see outgoing
• ~214M TCP packets and
• ~6M ESP (VPN) packets while incoming was
• ~394M TCP packets with
• ~8M ESP packets
Src: https://blogs.cisco.com/getyourbuildon/fosdem-2019-a-new-view-from-the-noc
From FOSDEM: IPsec VPN Clients & v6-only
• This means that at least about 2-3% of all traffic was on an IPSEC VPN.
And this excludes the TCP VPN traffic on ports 443/TCP and 22/TCP. On
the IPv6 network we do not see a similar amount of ESP traffic.
• This strongly suggests that the people remaining on the dual stack
network do so because their VPN solution does not work with an IPv6
only network.
Src: https://blogs.cisco.com/getyourbuildon/fosdem-2019-a-new-view-from-the-noc
Connections / Expected Trends
Situation/numbers will get better/increase over time
Numbers/problems will get less/decrease over time
Connection Endpoint
IPv6 IPv4
Type of Client Device All Web Fat VPN VPN Other
Client/ Client Client
App (SSL) (IPsec)
Smartphones iOS ++ ++ + ++ – +
Android ++ ++ ++ ++ – +
Other ++ ++ + ++ – +
Laptops Windows,
++ ++ + ++ – +
Pre-10
Windows 10 ++ ++ ++ ++ – +
Other ++ ++ ? ++ – +
Other IoT Devices ++ ++ ? ++ – +
Rationale re: Trends
• IPv6-enabled connection endpoints
(e.g. websites/servers) increase over time.
• Client-side apps increasingly support IPv6, not least due to Apple's

respective requirements (2016).
• Overall IPv6 support of client OSs and "exotic applications"

continuously gets better.
The Lab – Testing Applications in an IPv6-
only Environment
The Lab Infrastructure – Overview
• Pretty small and basic setup:
• Cisco ISR 4321 as NAT64 GW

• Running Everest-16.6.5 MD
• Unbound 1.9.0 as DNS64 resolver
• WLC + AP for Wifi Connectivity

• Running 8.5.140.0 ED
Router
ISR4321 R1
NAT64
The Lab – Overview
WLC
Server
Access DNS64
point
Laptop iOS Android

Testbed
• Windows 10 – Build 1809 / Windows 7
• macOS 10.14 – Mojave
• Apple iOS – 12.1.4
• Arch Linux – Kernel 4.19
• Android 9 Pie (API 28)
The Lab – Methodology
• Group applications in categories.
• e.g. Social Media, Communication etc.
• Define first set of (potential) relevant applications to be tested.
• Define test cases for each app
• Perform the tests
• (Try) to evaluate root cause for failed test cases
Categories
• Social Media
• Streaming
• Communication
• Games
• Informational
• Other
Display of Sample Categories / Test cases
Results
Overview
• OS-wise iOS apps successfully completed all test cases
• Maybe not a surprise given Apple’s strategy
• Most categories worked quite nicely, e.g.

• Social Media
• Communication
• Issues were mostly identified in two areas

• Games
• Streaming
Applications with Issues / Overview
• In general, we could observe two failure scenarios:
• Either the app just doesn’t work at all without IPv4
• In general the app works but some functionality is limited.
Spotify – in 2015
“Enabling IPv6 for a client application

is not technically a big deal.....
....Unfortunately our client code had

its own IP-address type which didn’t
support IPv6, and it also assumed
that an IP-address would fit in 4
bytes in numerous places....”
Src: https://labs.spotify.com/2015/11/05/
oh-ipv6-where-art-thou/
Spotify – in 2019
https://community.spotify.com/t5/Live-
Ideas/Other-IPv6-Support/idi-p/4469460
Streaming - Spotify
• Unfortunately, the Spotify app on Windows 10/7/macOS does not
work.
• The web client and iOS/Android work as intended
• No network activity could be observed. We assume the client tries

to open a IPv4 socket, which of course fails.
Game(s) Client
Games - Steam
• Downloading and installing worked
without a problem.
• Unfortunately, the updater

(that is run on every start) fails with a
“connection problem”.
• As with Spotify, no network activity

could be observed -> potentially tries
to open IPv4 socket.
Games – Fortnite
• “Hottest“ Battle Royal game
for a year or two.
• Based on the Unreal engine

developed by Epic.
• To play Fortnite, one has to install

the Epic Games Launcher.
Epic Games Launcher – Looks good from IPv6 PoV
But.....
• XMPP doesn’t work.....
Turns out...XMPP client only asks for an A record

Joining the Game
• You can join the lobby, download content
and contact the matchmaking server.
• Unfortunately, during the loading screen you

get a network connectivity lost error and are
back in the lobby.
• Wasn’t able to verify what exactly causes

the game to fail until now -> further
research necessary.
Early Research
• https://answers.unrealengine.com/questions/583305/bug-dedicated-server-connection-issues-with-ipv6-n.html
For future reference
https://www.unrealengine.com/en-US/blog/unreal-engine-4-21-released Nov 2018
Interim Conclusion (i)
• We tested around 35 different applications with a total of 120 test
cases
• On (if available) six different operating systems.
• Only three applications didn’t work at all on non-mobile operating

systems.
• Two applications had some feature limitations

• E.g. not able to join a voice channel @Discord
Interim Conclusion (ii)
• While we still see some (minor) breakage (that was to be expected)
it is lower than we initially anticipated.
• Apps on mobile devices (Android/iOS) work just fine in an IPv6-only

environment.
• Still, there is some work to do primarily for applications

installed on your “typical” workstation.
Lab / Next Steps
• Validate / further investigate failure cases
• Vendor communication!
• Probably even easier when the vendor is the only failing one in a
group of similar apps ;-)
Technical
Considerations in
IPv6-only
Environments
IPv6 in Wi-Fi Networks
• WLANs are shared media
• Ftr: yes, even with 802.11ax ;-)
• IPv6 communication on the local link involves a lot of multicast. How

does that translate to/affect traffic
• On air See also:
• Between APs serving “[the same] IP subnets” https://www.troopers.de/medi
a/filer_public/5b/34/5b340a5
8-2c8e-46a0-9d96-
834e5edd9154/tr16_ipv6_se
c_summit_secure_reliable_gu
est_wlan_v15.pdf
• Some ongoing discussion, e.g.
• IETF I-D IPv6 Neighbor Discovery on Wireless Networks. draft-thubert-6man-
ipv6-over-wireless
In Practice
• Some tuning is needed
• (WLAN) Controller level
• Which (of the above) to proxy/throttle/block
• Inter-AP communication
• L3 infrastructure
• Properties of RAs
• Properties of ND
• Other (e.g. MLD[?])
Neighbor Binding Table on Cisco WLC
RA Throttling on Cisco WLCs / Sample
FHS on WLC Controller
FHS Feature Default Configurable?

RA Guard Enabled Yes (only on APs)
DHCPv6 Guard Enabled No
IPv6 Source Guard Enabled Yes
IPv6 ACLs Disabled Yes
Gateway Configuration
• To reduce the multicast traffic the following parameters adjusted in Troopers
network:
• Router lifetime to 9000 seconds
• Reachable lifetime to 900 seconds
• Unicast solicited RAs
• The above are some “best practice” values, initially inspired by Andrew
Yourtchenko from the Cisco Live Wi-Fi implementation.
Config Snippet (incl. NAT64)
interface GigabitEthernet0/0/0.30
<output omitted>
description ====TRP-NAT64===
encapsulation dot1Q 30
ipv6 address FE80::1 link-local
ipv6 address 2A02:8071:F00:64::1/64
ipv6 enable
ipv6 mtu 1280
ipv6 nd reachable-time 900000
ipv6 nd other-config-flag
ipv6 nd router-preference High
ipv6 nd ra solicited unicast
ipv6 nd ra lifetime 9000
ipv6 nd ra interval 4
ipv6 nd ra dns server 2A02:8071:F00:64::251
ipv6 dhcp server DHCP-TRP-NAT64-v6-POOL
nat64 enable
Supporting
Infrastructure
Supporting Infrastructure & Processes
• Infrastructure
• Captive Portal (usually 3rd party provider)  IPv6? ;-)
• Management & WLC/AP-communication  IPv6? ;-)
• Telemetry
• Processes
• Communication
• Users
• Feedback loop re: stuff not working
• Management / Sponsor
• Vendors (of apps that don’t work)
Monitoring / Case Study
• We wanted to get a feeling about the NAT64 translations that are
active on our gateway during Troopers at any given time.
• But how do we get these data?

• SNMP? Unfortunately there is no OID we can query to get the active
translations.
EEM to the Rescue
• One nice person on the c-nsp list send me a clever workaround
• Thank you Nikolay!
• While he had initially created the EEM template for IPv4 NAT
entries, we could adjust it easily to our needs
High Level Steps – EEM Template
1. Perform the relevant “show commands”
• Show nat64 translations in this case
2. Parse the output with some Regex magic
3. Store this value in a SNMP “Expression” MIB
4. Query OID over SNMP to retrieve the value.
5. Rinse and repeat every 30 seconds
Complete EEM Template
> snmp mib expression owner NAT64 name NAT64TRANSLATIONS
> description Total active translations
> value type integer32
> expression 0
>!
> event manager applet NAT64-Translations
> event timer watchdog time 300 maxrun 60
> action 010 cli command "enable"
> action 030 cli command "configure terminal"
> action 040 cli command "do-exec show nat64 translations"
> action 050 regexp "^.+\s([0-9]+)" "$_cli_result" match total_translations
> action 100 cli command "snmp mib expression owner NAT64 name
NAT64TRANSLATIONS"
> action 110 if $_regexp_result eq "1"
> action 120 cli command "expression $total_translations"
> action 130 else
> action 140 cli command "expression 0"
> action 150 cli command "exit"
> action 160 end
Telemetry for DNS Queries
• We also wanted to a get a feeling to which degree client systems use either the RA
or (stateless) DHCPv6 provided DNS resolvers.
• To achieve this, we installed two instances of unbound, provided those per RA and
DHCPv6 respectively, and counted the total amount of DNS queries each of them
received.
• In general you should be very cautious re: telemetry (not only DNS-related) in Wi-Fi
hotspot type of networks.
• Evidently some data points might be privacy-invasive.
• Regulations might kick in, even conflicting ones.
Communication et al.
• How to incentivize users to use the v6-only SSID if there’s a
“legacy” (usually: dual-stacked) in parallel?
• How to provide feedback loop for stuff

not working?
• “Go to vendor” [+ “here’s a template”] vs.
• Common generic customer support channels
Conclusion
Conclusions
• We see an increasing interest in deploying v6-only + NAT64
networks.
• For reasons…
• Testing creates #transparency ;-) & well-informed decision making
• Overall less issues than expected
• Apple’s strategy seems to work.
• Communication strategy will be crucial, with management, users &
vendors.
Summary / Conclusions
• Deploying IPv6-enabled Wi-Fi hotspots requires specific
considerations and tech. adjustments
• Define strategy re: v6-only
• Perform specific configuration on devices
• Monitoring & telemetry
• Communication with users, vendors, mgmt.
Just to Make this Clear
• Based on our testing we think that going with v6-only
(+ NAT64) is a reasonable approach now
• Only very few issues (stuff not working) to expect
• Namely on platforms or types of app which might not even be relevant for
your deployment scenario
• At the same time this can save a lot of operational effort.
• Telemetry data & lab results are always a good idea ;-)
• Proper supporting communication can be helpful.
• Note: for most scenarios distributing DNS resolvers via RAs/RDNNS

and stateless DHCPv6 to be strongly considered.
IPv6-only in the
Datacenter
Feasibility in the Datacenter
• While we have seen that IPv6-only might make sense in the Access
Layer, what about DCs?
• Where should I start? Or should I start at all?
• What works and what not?
• Questions, Questions, Questions....
From one of our IPv6 engagements
• How did the Datacenter look like?
• Backbone/Core Network
• Management Network
• Staging environment
• Internal/Intranet Applications
• Running on the production servers
IPv6 Deployment within a Datacenter
• After several discussion rounds, it was decided (wisely) to deploy
IPv6 within the staging environment first.
• First round of deployment was performed for the infrastructure

systems.
• Includes DNS, RADIUS, Syslog, SMTP, NTP etc.
How to proceed (High-Level)?
• The most sensible approach (that also a number of other players
do) is:
• Add v6 to the systems in scope, but do NOT publish AAAA records

for these services yet.
• Verify the correct behaviour of the system after v6 is active.
• Gradually add AAAA to “activate” the communication to these

service over IPv6
But how should I add IPv6 to these Systems in
general?
• In short: It depends ;-)
• As I laid out in the morning session, from our perspective you have the
following options:
• Fully static configuration -> includes deactivation of RA processing on the
host
• „Hybrid” -> static configuration with default route via RA.
• Stable “dynamic” addresses (RFC 7217) with dynamic DNS updates
• DHCPv6 with reservations
• Regardless of how the gateway will be provided: Choose ONE link-local

address (e.g. fe80::1) and use it everywhere. This simplifies the provisioning
significantly
Application Behaviour
• Some apps work just fine with IPv6 and some don’t work as
expected: Testing is key/crucial!
• What we have observed (and others have made the same
observation):
• DNS works just fine (as it is transport protocol independent)
• Kerberos (to our surprise) works just fine as well
• NTP somewhat works, but there are some intricacies
• Syslog just works (under the assumption the receiver listens on IPv6)
• SSH works just fine as well
• SNMP works just fine (same as DNS)
Applications where you will Encounter Problems
• Hadoop Cluster
• Getting better, but still not there yet ->
https://issues.apache.org/jira/browse/HADOOP-11890
• Jira/Confluence
• Somewhat limited supported ->
https://confluence.atlassian.com/jirakb/ipv6-in-jira-949755622.html
Monitor Progress!!
• I cannot stress this enough. It is very important that you track your
progress to have good visibility where you are currently at with the
deployment.
Source: https://www.ipv6.org.uk/wp-content/uploads/2018/11/IPv6-presentation-linkedin-The-Beginning-of-the-End.pdf
The Cost of Dual Stack
• As already laid out in the beginning. Dual stack significantly
increases the overall complexity and operational effort.
• While getting IPv6 on the street within your datacenter will not work
without a Dual stack implementation (exceptions are green field
deployments), treat it as an interim step.
• Your overall goal MUST be to remove IPv4 from systems where

feasible, otherwise you might run into trouble in later stages/phases
of your transition.
Conclusion during the Journey (i)
• It helps to have a plan ;-)
• Measure! your progress! Do it in a controlled manner
• IPv6 still (suprise ;-)) requires people to deal with it:
• Operators (system, network, help desk et. al.)
• Developers -> Get them on board ASAP
• Managers -> They need to understand what and why your are doing it
• Corporate Lawyers -> to deal with external suppliers / contractors etc.
Conclusion during the Journey (ii)
• If you happen to have the chance to do a „clean switch“ -> Do it!
• Core services (routing, infrastructure services) work well in an IPv6-

only environment.
• Applications you rely on might not fully support IPv6 yet.

• Be prepared -> Wave with your wallet.
Case Study – Insurance Company
RFC1918
RFC1918 10.0.0.0/8
10.0.0.0/8
Shared
Datacenter
RFC1918
10.0.0.0/8
RFC1918
10.0.0.0/8
RFC1918
10.0.0.0/8
Case Study – Issues for the Migration
• Microsoft Directory Services do not work well through NAT
boundaries
• Official Microsoft stance:

• Active Directory over NAT has not been tested by Microsoft.
• We do not recommend Active Directory over NAT.
• Support for issues related to Active Directory over NAT will be very
limited and will reach the bounds of commercially reasonable efforts very
quickly.
Source: https://support.microsoft.com/en-us/help/978772/description-of-support-boundaries-for-active-directory-over-nat
Case Study – Adressing the Issues
• Implement a centralized Authentication Service within the datacenter
• Do this in an IPv6-only fashion.
• Due to some constraints, AD of the affiliates has been implemented in

Dual-Stack fashion.
• Communication is IPv6-only between these systems

• No NAT issues for AD communication
• Overall this worked quite well without any (IPv6-related) issues.
IPv6
Security
Eric Vyncke
TECRST-2001
@evyncke
#CLUS
IPv6 Security
Myths…
IPv6 Myths: Better, Faster, More Secure
Sometimes, newer means better and more secure
Sometimes, experience IS better and safer!
Source: Microsoft clip-art gallery
The Absence of Reconnaissance Myth
• Default subnets in IPv6 have 264 addresses
• 10 Mpps = more than 50 000 years
Reconnaissance in IPv6
Scanning Methods Will Change
• If using EUI-64 addresses, just scan 248
• Or even 224 if vendor OUI is known...
• Public servers will still need to be DNS reachable

• More information collected by Google...
• Increased deployment/reliance on dynamic DNS

More information will be in DNS
•
• Using peer-to-peer clients gives IPv6 addresses of peers

• Harvest NTP client addresses by becoming a member of pool.ntp.org
• Administrators may adopt easy-to-remember addresses
• ::1,::80,::F00D, ::C5C0, :ABBA:BABE or simply IPv4 last octet for dual-stack
• By compromising hosts in a network, an attacker can learn new addresses to scan

Scanning Made Bad for CPU
Remote Neighbor Cache Exhaustion (RFC 6583)
Potential router CPU/memory attacks if aggressive scanning
• Router will do Neighbor Discovery ….And waste CPU and memory
NS: 2001:db8::3
NS: 2001:db8::2
NS: 2001:db8::1
NS: 2001:db8::3
NS: 2001:db8::2
NS: 2001:db8::1
NS: 2001:db8::3
NS: 2001:db8::2
NS: 2001:db8::1
2001:db8::/64
For Your
Reference
Mitigating Remote Neighbor Cache Exhaustion

• Built-in rate limiter with options to tune it
• Since 15.1(3)T: ipv6 nd cache interface-limit
• Or IOS-XE 2.6: ipv6 nd resolution data limit
• Destination-guard is part of First Hop Security
• Priority given to refresh existing entries vs. discovering new ones
• Using a /64 on point-to-point links => a lot of addresses to scan!

• Using /127 helps (RFC 6164) or even link-local address only (RFC 7404)
• Internet edge/presence: a target of choice

• Ingress ACL permitting traffic to specific statically configured (virtual) IPv6 addresses only
• Using infrastructure ACL prevents this scanning

• iACL: edge ACL denying packets addressed to your routers
• Easy with IPv6 because new addressing scheme 
http://www.insinuator.net/2013/03/ipv6-neighbor-cache-exhaustion-attacks-risk-assessment-mitigation-strategies-part-1
The IPsec Myth:
IPsec End-to-End will Save the World
• IPv6 originally mandated the implementation of IPsec (but not its use)
• Now, RFC 6434 “IPsec SHOULD be supported by all IPv6 nodes”
• Some organizations still believe that IPsec should be used to secure all flows...
• Need to trust endpoints and end-users because the network cannot secure the traffic: no IPS, no ACL, no
firewall
• Network telemetry is blinded: NetFlow of little use
• Network services hindered: what about QoS or AVC ?
Recommendation: do not use IPsec end to end within an administrative

domain.
Suggestion: Reserve IPsec for residential or hostile environment or high profile

targets EXACTLY as for IPv4
Is there NAT for IPv6 ? - “I need it for security”
• Network Prefix Translation, NPTv6, RFC 6296,
• 1:1 stateless prefix translation allowing all inbound/outbound packets.
• Main use case: multi-homing (see first section)
• Else, IETF has not specified any N:1 stateful translation (aka overload NAT or NAPT)
for IPv6
• Do not confuse stateful firewall and NAPT* even if they are often co-located
• Nowadays, NAPT (for IPv4) does not help security
• Host OS are way more resilient than in 2000
• Hosts are mobile and cannot always be behind your ‘controlled NAPT’
• Malware are not injected from ‘outside’ but are fetched from the ‘inside’ by visiting weird sites
or installing any trojanized application
NAPT = Network Address and Port Translation
“By looking at the IP addresses in the Torpig headers
we are able to determine that 144,236 (78.9%) of the
infected machines were behind a NAT, VPN, proxy, or
ﬁrewall. We identiﬁed these hosts by using the non-
publicly routable IP addresses listed in RFC 1918:
10/8, 192.168/16, and 172.16-172.31/16”
Stone-Gross et al., “Your Botnet is My Botnet: Analysis of a Botnet Takeover”, 2009

http://www.cs.ucsb.edu/~rgilbert/pubs/torpig_ccs09.pdf
NAT does not Protect IoT
“Early 2017, a multi-stage Windows Trojan containing code to scan
for vulnerable IoT devices and inject them with Mirai bot code was
discovered. The number of IoT devices which were previously safely
hidden inside corporate perimeters, vastly exceeds those directly
accessible from the Internet, allowing for the creation of botnets with
unprecedented reach and scale.”
“The call is coming from inside the house! Are you ready for the next evolution in DDoS attacks?”
Steinthor Bjanarson, Arbor Networks, DEFCON 25
Shared Issues
ICMPv4 vs. ICMPv6
ICMP Message Type ICMPv4 ICMPv6
• Significant changes Connectivity Checks X X
Informational/Error
• More relied upon Messaging
X X
Fragmentation Needed
X X
Notification
Address Assignment X
Address Resolution X
Router Discovery 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
RFC 4890: Border Firewall Transit Policy
Internal Server A
Internet
ICMPv6 ICMPv6
Action Src Dst Name
Type Code
Permit Any A 128 0 Echo Reply

Needed for
Teredo traffic
Permit Any A 129 0 Echo Request
Permit Any A 1 0 Unreachable
Permit Any A 2 0 Packet Too Big
Time Exceeded—
Permit Any A 3 0
HL Exceeded
Permit Any A 4 0 Parameter Problem
Potential Additional ICMPv6
RFC 4890: Border Firewall Transit Policy
Internal Server A
Firewall B
Internet
ICMPv6 ICMPv6
Action Src Dst Name
Type Code
Permit Any B 2 0 Packet too Big
For locally
generated
Permit Any B 4 0 Parameter Problem by the
device
Permit Any B 130–132 0 Multicast Listener
Neighbor Solicitation
Permit Any B 135/136 0
and Advertisement
Deny Any Any
Remote NDP Floods...
• https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-
20160525-ipv6 (May 2015)
• RFC 4890 is a little too open
• RFC 4861 (Neighbor Discovery)

• Hop Limit MUST be 255
• Source should be link-local, unspecified or global address belonging to the link and not "any"
IPv6 Attacks with Strong IPv4 Similarities
Good news
IPv4 IPS
signatures can
• Sniffing be re-used
• IPv6 is no more or less likely to fall victim to a sniffing attack than IPv4
• Application layer attacks
• 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 strong mutual authentication, any attacks utilizing MITM will have the same
likelihood in IPv6 as in IPv4
• Flooding
• Flooding attacks are identical between IPv4 and IPv6
Enforcing a
Security Policy
IOS IPv6 Extended ACL
• Can match on
• Upper layers: TCP, UDP, SCTP port numbers, ICMPv6 code and type
• TCP flags SYN, ACK, FIN, PUSH, URG, RST
• Traffic class (only six bits/8) = DSCP, Flow label (0-0xFFFFF)
• IPv6 extension headers

• routing matches any RH, routing-type matches specific RH
• mobility matches any MH, mobility-type matches specific MH
• dest-option matches any destination options
• auth matches AH
• hbh matches hop-by-hop (since 15.2(3)T)
• fragments keyword matches
• Non-initial fragments (same as IPv4)
• undetermined-transport keyword does not match
• TCP/UDP/SCTP and ports are in the fragment
• ICMP and type and code are in the fragment
• Everything else matches (including OSPFv3, …)
• Only for deny ACE Check your platform & release as your mileage can vary…
IPv6 ACL Implicit Rules
RFC 4890
• Implicit entries exist at the end of each IPv6 ACL to allow neighbor
discovery:
...
permit icmp any any nd-na
permit icmp any any nd-ns
• This is different on IOS XE (i.e. ASR1k) : no default permit of ND /

NA Packets
IPv6 ACL Implicit Rules – Cont.
Adding a deny-log
• The beginner’s mistake is to add a deny log at the end of IPv6 ACL
. . .
! Now log all denied packets
deny ipv6 any any log
! Heu . . . I forget about these implicit lines
deny ipv6 any any
Solution, explicitly add the implicit ACE
. . .
! Now log all denied packets
deny ipv6 any any log
For Your
ASA Firewall IPv6 Support

Reference
• Since version 7.0 ! (April 2005)

• IPv6 header security checks (length & order)
• Management access via IPv6: Telnet, SSH, HTTPS, ASDM
• Routed & transparent mode, fail-over

• v6 App inspection includes: DNS,FTP, HTTP, ICMP, SIP, SMTP, and IPSec pass-
through
• IPv6 support for site-to-site VPN tunnels was added in 8.3
(IKEv1 in ASA 8.3.1, and IKEv2 in ASA 8.4.1)
• Selective permit/deny of extension headers (ASA 8.4.2)
• OSPFv3, DHCPv6 relay, stateful NAT64/46/66, mixed mode objects (ASA 9.0)
RFC 8200 & DHCP-PD on ASA 9.10
• Allow ASA to process packet with hop interface GigabitEthernet1/1
nameif outside
limit of 0 (Follow RFC 8200) security-level 0
ipv6 address dhcp default
• CSCvi46759 ipv6 enable
ipv6 nd suppress-ra
• Fixing some bugs in the same shot (DHCP ipv6 dhcp client pd hint ::/48
packets sent with HL=0 by some CMTS 😱 ) ipv6 dhcp client pd ISP
interface GigabitEthernet1/2
nameif inside
• Alas, general-prefix cannot be used in security-level 100
ipv6 address ISP ::1/64
ACL... ipv6 address autoconfig
ipv6 enable
!
Check with
# show ipv6 general-prefix
Firepower Management Center: Extension
Header (Flexconfig)
policy-map type inspect ipv6 inspect_ipv6_fc_pmap
parameters
verify-header type
verify-header order
match header esp
log
match header fragment
drop
match header ah
log
match header destination-option
log
match header hop-by-hop
drop log
match header routing-type eq 2
log
drop
drop log
Firepower Management Center Mixed Mode
Objects
Spam over IPv6
Botnet member or open relay
from Germany
• Spammers are also using IPv6 of course...
• Probably even without knowing it!
Nov 14 00:44:18 ks postfix/smtpd[22843]: connect from unknown[2a01:4f8:d16:4351::2]

Nov 14 00:44:18 ks postfix/smtpd[22843]: A5CDC155: client=unknown[2a01:4f8:d16:4351::2]
Nov 14 00:44:18 ks postfix/cleanup[22847]: A5CDC155: message-
id=<mw879m.1ci1jl@front.chemise-homme234.com>
Nov 14 00:44:18 ks postfix/qmgr[3578]: A5CDC155: from=<bck@chemise-homme234.com>,
size=27742, nrcpt=1 (queue active)
• So, we need to fight IPv6 spam!

• Content filtering: nothing has changed
• Sender authentication (DKIM, SPF, DMARC) works with IPv6
• Sender reputation works with Cisco Senderbase / Talos
TalosIntelligence and IPv6: It Works 
No geolocation yet though

(albeit Maxmind supports IPv6)
Not a lot of data yet...

PLEASE HELP
Anti-Spam Black Lists also Support IPv6 For Your
Reference
BRKSEC-
ISE 2.6 Adding More IPv6 3018
Per-User ACL Downloadable ACL

ACL ACL
- ACL rules defined on RADIUS Server -- ACL

ACL on
on the
the RADIUS
RADIUS Server
Server
- Cisco AVP, limited by 4000 characters -- Cisco
Cisco AVP,
AVP, no
no limit
limit on
on ACL
ACL size
size
- Centralised policy management -- Centralised
Centralised policy
policy management
management
YES
IPv4 IPv4
YES
Cisco AVP: “ip:inacl#1=permit ip any any” Cisco AVP: "#ACSACL#-IP-ACL_NAME-
<SEQ_NUM>”
IPv6
YES IPv6
YES
Cisco AVP: “ipv6:inacl#1=permit ipv6 any Cisco AVP: "#ACSACL#-IPv6-ACL_NAME-
Not Applicable
any” <SEQ_NUM>”
Summary of Cisco IPv6 Security Products
• ASA Firewall (Since version 7.0 released 2005) • FirePower Threat Defence (FTD) no
• Extension header filtering and inspection (ASA 8.4.2) IPv6 inspection support on the GUI
• Dual-stack ACL & object grouping (ASA 9.0) (FlexConfig), no management over
IPV6
• Email Security Appliance (ESA) IPv6
support since 7.6.1 (May 2012) • FirePower Device Manager (FDM) no
IPv6 support
• Web Security Appliance (WSA) with explicit
and transparent proxy • Cisco Umbrella, answers AAAA but
cannot manage policy for IPv6
• FirePower NGIPS provides Decoder for network
IPv4 & IPv6 Packets
• Cisco Threat Defense / StealthWatch:
mostly forever including SMC
• ISE 2.2 added IPv6 support, more w/ 2.6
Meraki growing IPv6 Support

“Scapy”
Introduction
Packet Forgery with SCAPY /1
• Scapy is a open source packet forgery tool built on Python
• Powerful albeit complex to understand and to use:
evyncke@host1:~# scapy
Welcome to Scapy (2.1.0)
>>> target="2001:db8:23:0:60de:29ff:fe15:2”
>>> packet=IPv6(dst=target)/ICMPv6EchoRequest(id=0x1234, seq=RandShort(),
data="ERIC")
>>> sr1(packet)
Begin emission:
Finished to send 1 packets.
Received 2 packets, got 1 answers, remaining 0 packets
<IPv6 version=6L tc=0L fl=0L plen=12 nh=ICMPv6 hlim=62
src=2001:db8:23:0:60de:29ff:fe15:2 dst=2001:db8:1:0:60de:29ff:fe15:1
|<ICMPv6EchoReply type=Echo Reply code=0 cksum=0xdb04 id=0x1234 seq=0x956a
data='ERIC' |>>
Packet Forgery with SCAPY /2
• Variable can be assigned a value with “=“
• Packets are built with the concatenation operator “/”
• Headers are instantiated with default values (such as source address,
checksum, next header, length, ...) all can be overwritten
• Packet can be displayed in various format: ls(), packet.show()
• Packet can be sent by
• send(): simply send it
• sr1(): send it and wait for one reply
>>> target="2001:db8:23:0:60de:29ff:fe15:2”
>>> packet=IPv6(dst=target)/ICMPv6EchoRequest(id=0x1234, seq=RandShort(),
data="ERIC")
“Playing” with
Extension Headers
IPv6 Header Manipulation
• Unlimited size of header chain (spec-wise) can make
filtering difficult
• Potential DoS with poor IPv6 stack implementations
• More boundary conditions to exploit
• Can I overrun buffers with a lot of extension headers?
• Mitigation: a firewall such as ASA/FTD which can filter on headers
Perfectly Valid IPv6 Packet

According to the Sniffer
Header Should Only Appear

Once
Destination Header Which
Should
Occur at Most
Destination TwiceHeader
Options
Should
Be the Last
http://www.cisco.com/en/US/technologies/tk648/tk872/technologies_white_paper0900aecd8054d37d.html
Parsing the Extension Header Chain
• Finding the layer 4 information is not trivial in IPv6
• Skip all known extension header
• Until either known layer 4 header found => MATCH
• Or unknown extension header/layer 4 header found... => NO MATCH
IPv6 hdr HopByHop Routing AH TCP data
IPv6 hdr HopByHop Routing AH Unknown L4 ???
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

• Tunnel end-points are end systems => Fragmentation / re-assembly can happen inside the network
• Reassembly done by end system like in IPv4
• RFC 5722/8200: overlapping fragments => MUST drop the packet. Most OS implement it since 2012
• Attackers can still fragment in intermediate system on purpose
• ==> a great obfuscation tool
Fragmentation Used in IPv4 by Attackers
... Also applicable to IPv6 of course
• Great evasion techniques
• Some firewalls do not process fragments except for the first one
• Some firewalls cannot detect overlapping fragments with different content
• IPv4 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
• Send a fragment to force states (buffers, timers) in OS
• See also: http://insecure.org/stf/secnet_ids/secnet_ids.html 1998!
Parsing the Extension Header Chain
Fragments and Stateless Filters
• Layer 4 information could be in 2nd fragment
• But, stateless firewalls could not find it if a previous extension header is fragmented
IPv6 hdr HopByHop Routing Fragment1 Destination …
IPv6 hdr HopByHop Routing Fragment2 … Destination TCP Data
Layer 4 header is in 2nd fragment,

Stateless filters have no clue where
to find it!
• RFC 6980: “nodes MUST silently ignore NDP … if packets include a fragmentation header”
• RFC 7112: “A host that receives a First Fragment that does not satisfy… SHOULD discard the
packet”
• RFC 8200: “If the first fragment does not include all headers through an Upper-Layer header, then
that fragment should be discarded”
Fragment Obfuscation with Scapy & Tcpdump
>>> packet=IPv6(dst=dst)/IPv6ExtHdrDestOpt(options=PadN(optdata='A'*20))
/TCP(sport=sport,dport=22,flags="S", seq=100)
>>> frag1=IPv6(dst=dst)/IPv6ExtHdrFragment(nh=60, id=0xabbababe, m=1,
offset=0)/str(packet)[40:48]
>>> frag2=IPv6(dst=dst)/IPv6ExtHdrFragment(nh=60, id=0xabbababe, m=0,
offset=1)/str(packet)[48:84]
>>> send(frag1)
>>> send(frag2)
IP6 (hlim 64, next-header Fragment (44) payload length: 16) 2001:...:1 > 2001:...:2: frag (0xabbababe:0|8) [|DSTOPT]
0x0000: 6000 0000 0010 2c40 2001 0db8 0001 0000 `.....,@........
0x0010: 60de 29ff fe15 0001 2001 0db8 0023 0000 `.)..........#..
0x0020: 60de 29ff fe15 0002 3c00 0001 abba babe `.).....<.......
0x0030: 0602 0114 4141 4141 ....AAAA
IP6 (hlim 64, next-header Fragment (44) payload length: 44) 2001:...:1 > 2001:...:2: frag (0xabbababe:8|36)
0x0000: 6000 0000 002c 2c40 2001 0db8 0001 0000 `....,,@........
0x0010: 60de 29ff fe15 0001 2001 0db8 0023 0000 `.)..........#..
0x0020: 60de 29ff fe15 0002 3c00 0008 abba babe `.).....<.......
0x0030: 4141 4141 4141 4141 4141 4141 4141 4141 AAAAAAAAAAAAAAAA
0x0040: 47b3 0016 0000 0064 0000 0000 5002 2000 G......d....P...
0x0050: da35 0000
Let’s Try the Naive ACL...
ipv6 access-list NO_SSH
deny tcp any any eq 22 log
permit ipv6 any any
IP6 (hlim 62, next-header Fragment (44) payload length: 16) 2001:..:1 > 2001:..:2: frag
(0xabbababe:0|8) [|DSTOPT]
(0xabbababe:8|36)
SSH accepts connection and replies

IP6 (hlim 64, next-header TCP (6) payload length: 24) 2001:...:2.22 > 2001:...:1.18355: Flags
[S.], cksum 0x138c (correct), seq 621319016, ack 101, win 5760, options [mss 1440], length 0
IPv6 Fragmentation & IOS ACL
• Matching against the first fragment non-deterministic:
• layer 4 header might not be there but in a later fragment
 Need for stateful inspection
• fragment keyword matches

• Non-initial fragments (same as IPv4), permitted by default
• undetermined-transport keyword does not match
• If non-initial fragment
• Or if TCP/UDP/SCTP and ports are in the 1st fragment
• Or if ICMP and type and code are in the 1st fragment
• Everything else matches (including OSPFv3, RSVP, GRE, ESP, EIGRP, PIM …)
• Only for deny ACE
Let’s Try undetermined-transport...
ipv6 access-list NO_SSH2
deny ipv6 any any undetermined-transport log
deny tcp any any eq 22 log
permit ipv6 any any
%IPV6_ACL-6-ACCESSLOGSP: list NO_SSH2/10 denied tcp

2001:...:1 -> 2001:...:2, 1 packet
1st fragment is not received..
(0xabbababe:8|36)
Reassembly fails after time-out, connection is never established
Is it the End of the World?
• The lack of fast wirespeed stateless ACL is a bad news of course
• IETF made 1st IPv6 fragment without layer-4 invalid and it SHOULD be dropped by
receiving host and MAY be dropped by routers
• RFC 7112 (born as draft-ietf-6man-oversized-header-chain)
• RFC 8200 (the new IPv6 standard)
• Use of undetermined-transport is strongly recommended

• ASA/FTD always drops such initial fragment
• If not supported, consider
• Bidirectional traffic (TCP, ...): block on the other direction using the source port
• On an intermediate router: permit TCP, ICMP, UDP, ... Hence blocking everything else
(including 1st fragment without layer-4)
Extension Header Security Policy
• White list approach for your traffic
• Only allow the REQUIRED extension headers (and types), for example:
• Fragmentation header
• Routing header type 2 & destination option (when using mobile IPv6)
• IPsec  AH and ESP
• And layer 4: ICMPv6, UDP, TCP, GRE, ...
• If your firewall is capable:
• Drop 1st fragment without layer-4 header
• Drop routing header type 0
• Drop/ignore hop-by-hop
• See also draft-ietf-opsec-ipv6-eh-filtering Source: Tony Webster, Flickr
More on dual-
stack networks
Enabling IPv6 in the IPv4 Data Center
The Fool’s Way
Internet
2) Sending RA with
1) I want IPv6, prefix for auto-
send RA configuration
3) 3)
3) 3) Yahoo!
Yahoo! Yahoo!
Yahoo! IPv6 
IPv6  IPv6 
IPv6 
IPv4 protection: IPv4 protection: IPv4 Protection:

iptables Packet filter Security center
4) Default protection… IPv6 Protection: IPv6 Protection: IPv6 Protection:

No ip6tables ✗ Packet filter ✔ Security center ✔
Before Mac OS X 10.7, ipfw was IPv4 only….

Enabling IPv6 in the IPv4 Data Center
The Right Way
Internet
2) Sending RA with
1) I want IPv6, “no auto-config”
send RA
3) Yahoo! 3) No 3) No 3) No
Static IPv6 IPv6 IPv6
IPv6 SLAAC SLAAC SLAAC
address
IPv4 protection: IPv4 protection: IPv4 Protection:

iptables Packet filter Security center
Vulnerability Scanning in a Dual-Stack World
• Finding all hosts:
• Address enumeration does not work for IPv6
• Need to rely on DNS or NDP caches or NetFlow
• Vulnerability scanning
• IPv4 global address, IPv6 global address(es) (if any), IPv6 link-local address
• Some services are single stack only (currently mostly IPv4 but who knows...)
• Personal firewall rules could be different between IPv4/IPv6
• IPv6 vulnerability scanning MUST be done for IPv4 & IPv6 even in an
IPv4-only network
• IPv6 link-local addresses are active by default
More on tunnels
L3-L4 Spoofing in IPv6
• Most IPv4/IPv6 transition mechanisms have no authentication built in
• => an IPv4 attacker can inject IPv6 traffic if spoofing on IPv4 and
IPv6 addresses
IPv6 ACLs Are Ineffective since IPv4 & IPv6 are spoofed
Tunnel termination forwards the Inner IPv6 Packet
IPv4
IPv6
Public IPv4
Internet
IPv6 Network IPv6 Network
IPv6 in IPv4
Tunnel Tunnel
Server B
Server A Termination Termination
Looping Attack Between 2 ISATAP Routers
(RFC 6324)
ISATAP router 1 ISATAP router 2
1. Spoofed IPv6 packet
S: 2001:db8:2::200:5efe:c000:201 Prefix 2001:db8:1::/64 Prefix 2001:db8:2::/64
D: 2001:db8:1::200:5efe: c000:202
192.0.2.1 192.0.2.2
2. IPv4 ISATAP packet to 192.0.2.2 containing
S: 2001:db8:2::200:5efe:c000:201
D: 2001:db8:1::200:5efe:c000:202
3 IPv6 packet
S: 2001:db8:2::200:5efe:c000:201
D: 2001:db8:1::200:5efe:c000:202
• Root cause
Repeat until Hop Limit == 0
• ISATAP routers ignore each other
• ISATAP router: Mitigation:

• accepts native IPv6 packets IPv6 anti-spoofing everywhere
ACL on ISATAP routers accepting IPv4 from valid clients only
• forwards it inside its ISATAP tunnel Within an enterprise, block IPv4 ISATAP traffic between ISATAP routers
• Other ISATAP router decaps and Within an enterprise block IPv6 packets between ISATAP routers
forward as native IPv6
Telemetry
Available Tools
• Similar to IPv4 telemetry
• SNMP MIB
• Not always available yet on Cisco gears
• Flexible Netflow for IPv6
• Available in : 12.4(20)T, 12.2(33)SRE
• Public domain tools: nfsen, nfdump, nfcpad…
• Cisco Threat Defense
• Model Driven Telemetry (YANG, OpenConfig, gRPC, ....)
For Your
Cisco IOS IPv6 MIB Implementation

Reference
IP FWD
IP ICMP TCP UDP
(ROUTES)
Original IPv4 only 2096 2011 2012 2013
Protocol Version rfc2096-update rfc2011-update
Independent (PVI)
= =
4292 4293 = IP-MIB
rfc2012- rfc2013-
update update
= =
4022 4113
IPv4/IPv6 stats can be monitored from CLI “show interface accounting”

on most platforms
Using SNMP to Read IPv4/IPv6 Neighbors Cache
evyncke@charly:~$ snmpwalk -c secret -v 1 udp6:[2001:db8::1] -m IP-MIB
ipNetToPhysicalPhysAddress
IP-MIB::ipNetToPhysicalPhysAddress.1.ipv4."192.168.0.2" = STRING: 0:13:c4:43:cf:e
IP-MIB::ipNetToPhysicalPhysAddress.1.ipv4."192.168.0.3" = STRING: 0:23:48:2f:93:24
IP-MIB::ipNetToPhysicalPhysAddress.1.ipv4."192.168.0.4" = STRING: 0:80:c8:e0:d4:be
...
IP-MIB::ipNetToPhysicalPhysAddress.2.ipv6."2a:02:05:78:85:00:01:01:02:07:e9:ff:fe:f2:a0:c6"
= STRING: 0:7:e9:f2:a0:c6
IP-MIB::ipNetToPhysicalPhysAddress.2.ipv6."2a:02:05:78:85:00:01:01:02:20:4a:ff:fe:bf:ff:5f"
= STRING: 0:20:4a:bf:ff:5f
IP-MIB::ipNetToPhysicalPhysAddress.2.ipv6."2a:02:05:78:85:00:01:01:30:56:da:9d:23:91:5e:ea"
= STRING: 78:ca:39:e2:43:3
...
evyncke@charly:~$ snmptable -c secret -v 1 udp6:[2001:db8::1] -Ci -m IP-MIB
ipNetToPhysicalTable
For Your
Reference
Flexible Flow Record: IPv6 Key Fields

IPv6 Routing Transport
Destination AS Destination Port TCP Flag: ACK
IP (Source or
Payload Size
Destination) Peer AS Source Port TCP Flag: CWR
Prefix (Source or Packet Section Traffic Index ICMP Code TCP Flag: ECE
Destination) (Header) Forwarding ICMP Type TCP Flag: FIN
Status
Mask (Source or Packet Section IGMP Type TCP Flag: PSH
Destination) (Payload) Is-Multicast
TCP ACK Number TCP Flag: RST
Minimum-Mask IGP Next Hop
(Source or DSCP BGP Next Hop TCP Header Length TCP Flag: SYN
Destination) TCP Sequence
Flow TCP Flag: URG
Protocol Extension Number
Sampler ID UDP Message
Traffic Class Hop-Limit TCP Window-Size
Direction Length
Flow Label Length
TCP Source Port UDP Source Port
Option Header Next-header Interface TCP Destination UDP Destination
Header Length Version Input Port Port
Payload Length Output TCP Urgent Pointer
Flexible Flow Record: IPv6 Extension Header Map
Bits 11-31 Bit 10 Bit 9 Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
Res ESP AH PAY DST HOP Res UNK FRA0 RH FRA1 Res
 FRA1: Fragment header – not first fragment
 RH: Routing header
 FRA0: Fragment header – First fragment
 UNK: Unknown Layer 4 header (compressed, encrypted, not supported)
 HOP: Hop-by-hop extension header
 DST: Destination Options extension header
 PAY: Payload compression header
 AH: Authentication header
 ESP: Encapsulating Security Payload header
 Res: Reserved
For Y
Refer
Flexible NetFlow: Exporter, Record and Monitor

flow exporter FLOW-EXPORTER
destination 2001:db8::1 <<< IPv6 is supported
transport udp 9995
flow record FLOW-RECORD

match ipv6 source address <<< key fields
match ipv6 destination address
match ipv6 protocol
collect counter bytes <<< non key fields
collect counter packets
collect datalink mac source address input <<< can also collect MAC addresses ;-)
flow monitor FLOW-MONITOR

; record netflow ipv6 original-output <<< for traditional NetFlow records
record FLOW-RECORD
exporter FLOW-EXPORTER
statistics packet protocol
statistics packet size
interface GigEthernet0/15
ipv6 flow monitor FLOW-MONITOR output
Netflow Reverse Usage
• Scanning an IPv6 network is impossible (address space too large)
• How can we run a security audit?
• Easy
• Get all IPv6 addresses from Netflow
• Note: scanning link-local addresses requires layer-2 adjacency, i.e.
• ping6 ff02::1
Forensic
Multiple Facets to IPv6 Addresses
• Every host can have multiple IPv6 addresses simultaneously
• Need to do correlation!
• Ensure that your Security Information and Event Management (SIEM) supports IPv6
• Usually, a customer is identified by its /48 
• Every IPv6 address can be written in multiple ways
• 2001:0DB8:0BAD::0DAD
• 2001:DB8:BAD:0:0:0:0:DAD
• 2001:db8:bad::dad (this is the canonical RFC 5952 format)
• => Grep cannot be used anymore to sieve log files…
• See also RFC 7721 “Security and Privacy Considerations for IPv6 Address Generation Mechanisms”
How to Find the MAC Address of an IPv6
Address?
• Easy if EUI-64 format as MAC is embedded
• 2001:db8::0226:bbff:fe4e:9434
• (need to toggle bit 0x20 in the first MAC byte = U/L)
• Is 00:26:bb:4e:94:34
Address?
• DHCPv6 address or prefix… the client DHCP Unique ID (DUID) can be
• MAC address: trivial
• Time + MAC address: simply take the last 6 bytes
• Vendor number + any number: no luck… next slide can help
• No guarantee of course that DUID includes the real MAC address.
# show ipv6 dhcp binding

Client: FE80::225:9CFF:FEDC:7548
DUID: 000100010000000A00259CDC7548
Username : unassigned
Interface : FastEthernet0/0
IA PD: IA ID 0x0000007B, T1 302400, T2 483840
Prefix: 2001:DB8:612::/48
preferred lifetime 3600, valid lifetime 3600
expires at Nov 26 2010 01:22 PM (369)
DHCPv6 in Real Live…
• Not so attractive 
• Only supported in Windows Vista, and Windows 7, Max OS/X Lion
• Not in Linux (default installation), …
• Windows Vista does not place the used MAC address in DUID but any MAC address of
the PC
• See also: https://knowledge.zomers.eu/misc/Pages/How-to-reset-the-IPv6-DUID-in-
Windows.aspx
# show ipv6 dhcp binding

Client: FE80::FDFA:CB28:10A9:6DD0 Actual MAC address:
DUID: 0001000110DB0EA6001E33814DEE 0022.5f43.6522
Username : unassigned
IA NA: IA ID 0x1000225F, T1 300, T2 480
Address: 2001:DB8::D09A:95CA:6918:967
preferred lifetime 600, valid lifetime 600
expires at Oct 27 2010 05:02 PM (554 seconds)
RADIUS Accounting with IEEE 802.1X (WPA)
• Interesting attribute: Acct-Session-Id to map username to IPv6 addresses
• Can be sent at the begin and end of connections
• Can also be sent periodically to capture privacy addresses
• Not available through GUI, must use CLI to configure
config wlan radius_server acct framed-ipv6 both
username=joe@example.org Acct-Session-Id=xyz Acct-Status-Type=Start Framed-

IP-Address=192.0.2.1 Framed-IPv6-Address=fe80::cafe
username=joe@example.org Acct-Session-Id=xyz Acct-Status-Type=Alive Framed-
IP-Address=192.0.2.1 Framed-IPv6-Address=fe80::cafe Framed-IPv6-
Address=2001:db8::cafe Framed-IPv6-Address=2001:db8::babe
username=joe@example.org Acct-Session-Id=xyz Acct-Status-Type=Stop Framed-IP-
Address=192.0.2.1
Address?
• Last resort… look in the live NDP cache (CLI, SNMP, MDT telemetry)
#show ipv6 neighbors 2001:DB8::6DD0

IPv6 Address Age Link-layer Addr State Interface
2001:DB8::6DD0 8 0022.5f43.6522 STALE Fa0/1
• If no more in cache, then you should have scanned and saved the cache…
• EEM can be your friend
• First-Hop Security can generate a syslog event on each new binding
ipv6 neighbor binding logging
IPv6 VPN
Secure IPv6 over IPv4/6 Public Internet
• No traffic sniffing
• No traffic injection
• No service theft
Public Network Site 2 Site Remote Access
 6in4/GRE Tunnels Protected by  SSL VPN Client AnyConnect

IPsec
IPv4
 DMVPN 12.4(20)T
 FlexVPN
 IPsec VTI 12.4(6)T  AnyConnect 3.1 & ASA 9.0
IPv6  DMVPN 15.2(1)T
 FlexVPN
For Your
DMVPN for IPv6 Configuration

Reference
Hub Spoke
interface Tunnel0 interface Tunnel0
ipv6 address 2001:db8:100::1/64 ipv6 address 2001:db8:100::11/64
ipv6 eigrp 1 ipv6 eigrp 1
no ipv6 split-horizon eigrp 1 ipv6 nhrp map multicast 172.17.0.1
no ipv6 next-hop-self eigrp 1 ipv6 nhrp map 2001:db8:100::1/128 172.17.0.1
ipv6 nhrp map multicast dynamic ipv6 nhrp network-id 100006
ipv6 nhrp network-id 100006 ipv6 nhrp holdtime 300
ipv6 nhrp holdtime 300 ipv6 nhrp nhs 2001:db8:100::1
tunnel source Serial2/0 tunnel source Serial1/0
tunnel mode gre multipoint tunnel mode gre multipoint
tunnel protection ipsec profile vpnprof tunnel protection ipsec profile vpnprof
! !
interface Ethernet0/0 interface Ethernet0/0
ipv6 address 2001:db8:0::1/64 ipv6 address 2001:db8:1::1/64
ipv6 eigrp 1 ipv6 eigrp 1
! !
interface Serial2/0 interface Serial1/0
ip address 172.17.0.1 255.255.255.252 ip address 172.16.1.1 255.255.255.252
! !
ipv6 router eigrp 1 ipv6 router eigrp 1
no shutdown no shutdown
All combinations of IPv4 and IPv6 are allowed

FlexVPN Site-to-site: e.g. IPv6 over IPv4 For Your
Reference
• IPv4/IPv6 FlexVPN over IPv4 or IPv6 are allowed (IPv6 over IPv4 shown)
2001:db8:beef::/64
2001:db8:cafe::/64
172.16.1.1 172.16.2.1
interface Tunnel0 interface Tunnel0

ipv6 address fe80::1 link-local ipv6 address fe80::2 link-local
ipv6 ospf 1 area 0 ipv6 ospf 1 area 0
tunnel source FastEthernet0/0 tunnel source FastEthernet0/0
tunnel destination 172.16.2.1 tunnel destination 172.16.1.1
tunnel protection ipsec profile default tunnel protection ipsec profile default
interface FastEthernet0/1 interface FastEthernet0/1

ipv6 address 2001:db8:cafe::1/64 ipv6 address 2001:db8:beef::1/64
ipv6 ospf 1 area 0 ipv6 ospf 1 area 0
interface FastEthernet0/0 interface FastEthernet0/0

ip address 172.16.1.1 255.255.255.0 ip address 172.16.2.1 255.255.255.0
Global Addressing and VPN
• All inside hosts have a globally unique IPv6 address
• Routing-wise, remote sites could communicate over the Internet
• Even OUTSIDE of VPN tunnels
• Ensure routes point into the tunnel (FlexVPN, DMVPN)

• Drop packets from the Internet having Source and Destination from
your prefix
Secure RA IPv* over IPv* Public Network:
AnyConnect SSL VPN Client & ASA
IPv6/IPv4 Intranet
AnyConnect supports native
IPv4/6 connectivity
IPv4/6
• Connecting via IPv4/6 Internet to ASA
Transport
• SSL Tunneling IPv6 in IPv6 , IPv4 in IPv4, IPv6 Network
in IPv4, IPv4 in IPv6
• No support for DHCPv6 yet
• Mobile does not support IPv6 transport
See also:
http://blog.webernetz.net/2014/01/18/cisco-anyconnect-ipv6-access-through-ipv4-vpn-tunnel/
AnyConnect on CL-NAT64
Use Case: BC-Hydro IPv6 + IPsec for Smart
Meters
http://www.rmv6tf.org/wp-content/uploads/2015/10/2-Bavarian-Mauro_Success-and-
future-of-IPv6-from-an-Electrical-Utility-Perspective-rev5.compressed.pdf
On ciscolive.com:
BRKARC-2008 - Smart Grid: Field Area Network Multi-Service Architecture and BC
Hydro Case Study
http://www.cisco.com/c/dam/en_us/solutions/industries/retail/downloads/bc-hydro-cisco.pdf
Recommended Reading
Do not plan to attend BRKSEC-3200 as there are a

lot of similar contents
Complete your
online session • Please complete your session survey
evaluation after each session. Your feedback
is very important.
• Complete a minimum of 4 session
surveys and the Overall Conference
survey (starting on Thursday) to
receive your Cisco Live water bottle.
• All surveys can be taken in the Cisco Live
Mobile App or by logging in to the Session
Catalog on ciscolive.cisco.com/us.
Cisco Live sessions will be available for viewing
on demand after the event at ciscolive.cisco.com.
Continue your education
Demos in the
Walk-in labs
Cisco campus
Meet the engineer

Related sessions
1:1 meetings
More IPv6 Sessions
When Session Title
9 June 2019 / 9:00 TECRST-1991 Introduction to IPv6: Connecting nodes to the IPv6 access network
9 June 2019 / 14:00 TECRST-2001 Designing and deploying a security IPv6 network
10 June 2019/ 8:00 BRKRST-2619 IPv6 Deployment: Developing an IPv6 Addressing Plan and Developing IPv6
10 June 2019/ 8:00 BRKSPG-3001 Introduction to SRv6 technology
10 June 2019 / 13:00 BRKSPG-2602 IPv4 Exhaustion: IPv6 Transition and NAT Architectures
11 June 2019 / 8:00 BRKSEC-3018 IPv6 AAA, Port-Based auth and Security Implementation
11 June 2019/ 13:00 LTRRST-2016 IPv6 in the Enterprise for Fun and (fake) Profit: A Hands-On Lab
12 June / 8:00 BRKSEC-3200 Advanced IPv6 Security Threat and Mitigation
12 June / 8:00 BRKMPL-2132 Designing and deploying SRv6 networking overlaps

12 June / 13:00 BRKRST-3304 Hitchhiker's Guide to Troubleshooting IPv6
LABRST-2261 IPv6 planning, deployment and transition

LABRST-1000 Intro IPv6 Addressing and Routing Lab
LABSPG-1327 Introduction to Segment Routing v6 (SRv6) with IOS-XR
Thank you
#CLUS
#CLUS

Tecrst 2001

Uploaded by

Copyright:

Available Formats

You might also like

Tecrst 2001

Uploaded by

Document Information

Original Title

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

Tecrst 2001

Uploaded by

Copyright:

Available Formats

#CLUS

Webex Teams will be moderated cs.co/ciscolivebot# TECRST-2001

• Router ID Switching Services

• Single router, single circuit ipv6 router ospf 1

• Suppress RAs for global assigned addressing

• Recursive (next hop) ipv6 route 2001:db8:5::/48 2001:db8:4::1

• Default route ::/0 !default

LSPs* full mesh

• LSDB & cost per protocol !

• Swaps Left Most Bits of Address

• Peer over IPv6 for IPv6 prefixes ISP A ISP B

• Controlling hop limit, accepting ~254 only

ipv6 prefix-list ISPAout seq 5 2001:db8:460::/44

• Hot Standby Router Protocol (HSRP)

• Pointed at the Layer 3 switch

• IPv6 will require an iBGP peer link at Internet edge

• Layer 3 VPN service over ISP

• Advertise default route over this link to core routers AS 64498

• Redistribute the default route into the IGP

• Internet edge routers install prefixes

• RFC 7381 enterprise IPv6 guidelines

• One of the first questions discussed during the initial meeting(s)

• The more consumers will adopt a

• Where are we today in regards to

• Everything (on the infrastructure level) needs to be maintained for both

• Depending on the environment, more layers of NAT are necessary

• Currently, a /16 equates to 1.245.165$

• Prices for smaller network are even higher

• 73% of all Websites are still IPv4-only 

• In order to ensure a smooth user experience, packets need to be

• NAT64 is in basically all deployments used in conjunction with

• DNS64 sythesis AAAA records from A records

IPv6-only internal network

• Separate ALG necessary if translation of these packets shall succeed

• T-Mobile has successfully deployed IPv6-only networks.

• Full control on mobile devices and only allow IPv6-only compatible

• RFC6877 464xLAT, “fixes” broken code for now

Handset Carrier Network Internet

• Application supports IPv6 (web browser),

• Application does not support IPv6, the client must provide a

• Lots of misinformation floating, in different circles

• Thoroughly consider users, platforms, applications and

• Timeline might play a role, too.

• Please note: it is crucial that you perform your own testing if

Numbers/problems will get less/decrease over time

• Client-side apps increasingly support IPv6, not least due to Apple's

• Overall IPv6 support of client OSs and "exotic applications"

• Cisco ISR 4321 as NAT64 GW

• Unbound 1.9.0 as DNS64 resolver

• WLC + AP for Wifi Connectivity

Laptop iOS Android

• macOS 10.14 – Mojave

• Apple iOS – 12.1.4

• Arch Linux – Kernel 4.19

• Android 9 Pie (API 28)

• Define first set of (potential) relevant applications to be tested.

• Define test cases for each app

• Perform the tests