Welcome to this Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about IPv6 Security with experts Eric Vyncke and Andrew Yourtchenko.
Distinguished System Engineer Eric Vyncke and Engineering Technical Leader Andrew Yourtchenko explain the security myths and security issues in the IPv6 protocol. Though IPv6 is only available to 3 percent of Internet users, this number is doubling every 6 to 9 months, and, more important, all host OSes have IPv6 enabled by default. The session will focus mainly on the protocol security itself, though some product features will also be explained. It is expected that the attendees have some knowledge of IPv6 and also of IPv4 network security.
This is a continuation of the live webcast.
Eric Vyncke is a distinguished engineer based in the Brussels office of Cisco. His main current technical focus is security and IPv6. He has designed several secured large IPsec networks and other security-related designs. In his work for the IETF, he coauthored RFC 3585 and 5514 and is active in V6OPS, 6MAN, and OPSEC working groups. His recent works are related to IPv6, including coauthoring a book on IPv6 security; he also authored a book on Layer 2 security. Eric is the current cochair of the Belgian IPv6 Council; www.vyncke.org/ipv6status is well known for several years to collect statistics about IPv6 deployment. He is also a visiting professor for security topics at the University of Mons. He is an adjunct professor at HEC, the business school of University of Liège, Belgium. He holds a CISSP certification, is a member of ISSA, and speaks frequently at international conferences.
Andrew Yourtchenko, CCIE No.5423 is a Technical Leader at Cisco Systems Network Operating Systems Technology Group, and has been involved in networking since 1995, specializing in the areas of applications and network security. He spent a significant portion of his career at Cisco TAC, driving the resolution of complex technical problems. He contributes to IETF, and is a frequent speaker at IPv6 conferences. He actively engages with Cisco customers and partners in the areas of IPv6 transition, focusing on the transport and application levels.
Remember to use the rating system to let Eric and Andrew know if you have received an adequate response.
Because of the volume expected during this event, our experts might not be able to answer every question. Remember that you can continue the conversation in the Security community under subcommunity Other Security Subjects shortly after the event. This event lasts through May 9, 2014. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.
Webcast Related Links
Yet another classical question :-)
First, please note that NAT (while being often colocated with a firewall) offers nearly no security (after all most of the botnet members are being a home router doing NAT -- CodeRed, Nimda have been replaced by more sophisticated attacks). NAT makes security even harder: writing ACL is more complex and audit-trail is either impossible or way too long.
Second, as you know, RFC 1918 address and ULA does not prevent 'by magic' any communication with the outside. There are a lot of packets on the Internet whose source address is RFC 1918 or ULA... My point is that even with those addresses, a security policy MUST be enforced at the perimeter of your network.
So, NAT makes thing more complex hence less secure. But, of course, esp for enterprise network, please use a network firewall (plus IPS, ...) to block some traffic based on layer-3 or layer-4 information such as addresses.
A promise of IPv6 is to make network cleaner and easier (hence safer) to operate thanks to the absence of NAT. So, think twice before using NAT for IPv6.
If you really want to make your life miserable, then you can use NAT for IPv6 on ASA (even overloading, i.e. all your zillions of internal IPv6 addresses mapped to a single 'public' IPv6 address). Again, not recommended.
To be honest, this is a frequent question. It will take some time for your security dept to swallow it and to digest the above answer 
[Retyping the whole reply after this $*%! system failed to accept my reply 
]
Hi Jim
Nice to read from you again and thanks for participating in the webcast!
Cisco has implemented 'undetermined-transport' years before RFC 7112 in order to block those too-long-extension-header packets. Of course, as it is a data-plane feature, it is heavily depending on the existing HW hence not available on every switches... The missing platforms keep me awake at night sometimes... A real threat.
Regarding the regression tests, I am unsure and cannot reply to you. I know for sure that Cisco Product Security Incident Response Team is aware and usually they are pretty efficient to fix bug and to prevent them to occur in other places/time.
Point taken for white papers as well
Thanks again for your interest and looking forward to meeting you at Cisco Live in a couple of weeks
Cheers
-éric
