4. IP version 6
• “IP” (Internet Protocol) is the glue that makes the Internet work
– Every device on the network has an IP “address”
• What we use today is IP version 4
– In production use for 27 years (1983), and showing its age
– 32 bit addresses
• IPv6 is the next generation Internet protocol
– Huge address space (128 bit addresses)
– Aggregation based hierarchy for route table efficiency
– Simplified, fixed length header – better options support
– Mandatory IPsec (promise for improved security)
– Autoconfiguration, ease of renumbering
– Support for QoS
• The most important piece right now is that it has incredibly vast
address space
17-May-10 4
5. The piece that has changed
ISO 7 Layer Model
Application
Internet Stack
Presentation
Session Sockets
Transport TCP, UDP
Network IPv6
IP
Link Mac Layer
Physical
17-May-10 5
6. The Transition to IPv6
• Running out of IPv4 address space
– Expected depletion in 2012
• Every network connected device must
upgrade.
• Transition to IPv6 should have happened by
now
– delays in product availability and maturity
– apathy on all fronts, lack of sense of urgency
– other priorities
17-May-10 6
7. Implementation approach:
“Dual Stack”
• IPv6 is not compatible with IPv4.
– They can exist side by side, but don’t interoperate.
• It is not possible to communicate between IPv4 and
IPv6 Internets without translators.
– Translators are problematic, and we should avoid them.
• “Dual Stack” is when you run both protocols on all
networks and systems.
– This allows full connectivity to both IPv4 and IPv6 Internets.
– It is the most pragmatic transition mechanism today if you
have sufficient IPv4 addresses.
• When we speak of “transition”, we mean “transition
to dual-stack”, not to “IPv6 only”.
17-May-10 7
8. Address exhaustion
• ARIN Board of Trustees Resolution dated 7 May 2007:
RESOLUTION OF THE BOARD OF TRUSTEES OF ARIN ON INTERNET
PROTOCOL NUMBERING RESOURCE AVAILABILITY
WHEREAS, community access to Internet Protocol (IP) numbering Resources has proved
essential to the successful growth of the Internet; and,
WHEREAS, ongoing community access to Internet Protocol version 4 (IPv4) numbering
resources can not be assured indefinitely; and,
WHEREAS, Internet Protocol version 6 (IPv6) numbering resources are available and
suitable for many Internet applications,
BE IT RESOLVED, that this Board of Trustees hereby advises the Internet community that
migration to IPv6 numbering resources is necessary for any applications which require
ongoing availability from ARIN of contiguous IP numbering resources; and,
BE IT ORDERED, that this Board of Trustees hereby directs ARIN staff to take any and all measures necessary to assure
veracity of applications to ARIN for IPv4 numbering resources; and,
BE IT RESOLVED, that this Board of Trustees hereby requests the ARIN Advisory Council to consider Internet Numbering
Resource Policy changes advisable to encourage migration to IPv6 numbering resources where possible.
Unanimously passed by the Board of Trustees on 7 May 2007.
17-May-10 8
10. Notice of IPv4 Address
Depletion
“Make your organization’s
publicly accessible resources
available via IPv6 as soon as
possible”
17-May-10 10
11. Potential scenario
• Projected IPv4 address depletion in 2012
– Address blocks become scarce commodity
– Broken into smaller pieces, and “sold”
• Then, IPv4 Routing tables exceed router capacity
– Upwards of 2M routes, won’t fit router memory
– Some parts of Internet become isolated
• Islands of IPv6-only
– Can’t get IPv4 addresses
– Don’t want complexity of dual stack
– National mandates
• No good IPv4/IPv6 translator solution yet
– But IETF is working on proposals.
17-May-10 11
13. Background
• DREN (Defense Research and Engineering Network)
– is DoD’s Internet Service Provider for the Research and
Engineering community
– also serves as the DoD IPv6 “pilot” network
• Started the transition to IPv6 nearly 10 years ago
• In full production “dual stack” for some years now
– Significant operational experience, and lessons learned
17-May-10 13
14. Benefits already realized
• Adversaries can’t map nets, due to sparse addressing
• Vastly reduced routing tables, resulting in faster convergence
• Everything gets an address (or many of them), and NATs are
eliminated.
– End to end model is restored
– With IPSEC, an end to end security model is possible
– Facilitates “one-IP one-service” model
– Improved battery life of network devices (sensors, cell phones)
• Multicast is greatly simplified
– Rendezvous Point (RP) embedded in multicast group address
– No more MSDP
* NATs: Network Address Translators
* IPSEC: Internet Protocol Security
* MSDP: Multicast Source Discovery Protocol
17-May-10 14
16. IPv6 Security Review
• Independent security review
performed by SAIC for DREN
during 2005
– Publicly available
• Conclusions:
– protocol is no less secure
than v4
17-May-10 16
17. Maturity of Implementations
• IPv4 is very mature, implementations are
solid
– used heavily for over 20 years
• IPv6 is very new
– limited production experience
– vendors aren’t “eating their own dogfood”
– we haven’t found all the bugs yet
Near certainty that we will find Denial of Service Vulnerabilities
17-May-10 17
18. Tunnels
• If systems are connected to a network that does not
support IPv6, they may try to “tunnel” IPv6 in IPv4
packets
– Popular mechanisms are 6to4, ISATAP, Teredo
– Default in Windows
• Tunnels can bypass firewalls and other security
protections
– can easily happen by accident
– you may not be aware that it is happening
• Recommendation:
– Block tunnels (IP Protocol 41) at security boundaries
17-May-10 18
19. Rogue routers
• In IPv6, routers announce themselves using “RA” (router
advertisements)
• Systems on the network learn a default gateway from the RAs
– part of the auto-configuration feature of IPv6
• Any system could pretend to be an IPv6 router and send RAs
– other systems will hear this and route traffic to this rogue router
– denial of service to the entire subnet
• Windows systems that have Internet Connection Sharing (ICS)
enabled will do this automatically.
• Solution:
– Long term – Implement “RA Guard” when available
– Near term – set router priority to “high” on the true routers
17-May-10 19
20. THC report - 2008
• http://www.thc.org
• Confirms early implementations are immature
– 47 implementation bugs reported by June 2008
• Conclusions:
– no serious new risks with IPv6
– some security improvements over IPv4
• scanning and worming will be harder
• no record-route, no uptime check
• easier filtering and attack tracing
17-May-10 20
21. Many products lack IPv6 support
• Many products that are critical to security
infrastructure are not IPv6-enabled
– Firewall
– Web cache/proxy
– Load balancer
– Intrusion Detection System (IDS)
– Intrusion Prevention System (IPS)
– Many VPN products
• Both SSL VPNs and IPSEC VPNs
– Vulnerability assessment and forensics tools from
most vendors
17-May-10 21
22. Privacy addresses
• See RFC 4941
• Windows systems do this by default (and we don’t like it!)
• Breaks many things in our environment
– Forensics
– Stable DNS entries
– Automated management tools
• Could fix with DHCPv6, but client not available in important OS’s
– Windows XP, Mac OSX
• Would be nice if RA’s could say “don’t do this”
• So we have to visit every Windows machine to disable this.
– Breaks the “plug and play” goal of IPv6 for clients.
• How To: (next slide)
17-May-10 22
23. Disabling privacy
addresses
• Windows XP
ipv6 -p gpu UseTemporaryAddresses no
• Windows 2003
netsh interface ipv6 set privacy state=disabled store=persistent
• Windows Vista
netsh interface ipv6 set privacy state=disabled store=persistent
netsh interface ipv6 set global randomizeidentifiers=disabled
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
• Windows 2008
netsh interface ipv6 set global randomizeidentifiers=disabled
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
17-May-10 23
24. Dual Stack complexities
• Operating dual stack is like running two separate
networks in parallel
• All security mechanisms must be equally applied to
both network protocols
– otherwise one of them becomes the “weakest link”
– new entry vector for adversaries
• Addition of complexity
– makes it harder to maintain
– more prone to mistakes
• Recommendation: topological and security
congruency
– same topology for both IPv4 and IPv6 components
– identical security policies, ACLs, defences, etc.
17-May-10 24
25. VPN problems
• Travelers and telecommuters use client VPNs to connect to the
corporate Intranet securely
– Like Cisco IPSEC VPN or Juniper SSL VPN
• Only tunnels the IPv4 traffic (today)
• IPv6 traffic, if supported at all, goes outside this tunnel
– IPv6 traffic is now in the clear over the Internet, where user may think it is
protected
– But it may be blocked by the corporate firewall
• Seriously impacts performance for IPv6-enabled remote users.
• Users disable IPv6 to fix it (bad scenario)
• Solution:
– Deploy ISATAP to Intranet.
– But MACs don’t have ISATAP client support.
17-May-10 25
26. Crisis response
• Deployment of anything in a crisis is prone to
mistakes
– insufficient time to plan and design the solution
– insufficient time to develop or procure the best
tools
• Waiting too long to deploy IPv6 will put you
into a crisis scenario at some point
• Recommendation: deploy IPv6 now
– you should have been working on it for a few
years now
17-May-10 26
27. Summary
• DREN has been successfully using IPv6 in a
production environment, with many dual-
stack systems and services, for years
• IPv6 presents some new security challenges,
but it is fundamentally no less secure than
IPv4
• Most significant problem is the very limited
deployment to date
• Strongest recommendation: IPv6-enable your
public facing services now!
17-May-10 27
