IPv6 myths

Once you’ve spent a few hours trying to understand the implications of IPv6, you quickly realize that the only significant change is the increase in the address length. All the other goals that some people had been talking about were either forgotten or failed due to huge mismatch between idealistic view of the Internet IPv6 developers had 15 years ago and today’s reality. However, you still find mythical properties of IPv6 propagated across the Internet. Here are a few I’ve found; add your favorites in the comments.

Numerous IPv6 topics are covered in my Enterprise IPv6 Deployment workshop. You can attend an online version of the workshop or we can organize a dedicated event for your team.

IPv6 provides service/location separation. Total nonsense. The only mechanism used to find services is still DNS and it’s still used from the wrong position in the protocol stack.

IPv6 will reduce IP routing tables. Not true. IETF had 15 years to solve multihoming issues, but failed to do so. SHIM, SCTP ... are still in a very experimental stage. If anything, the situation will only get worse, as everyone will try to get PI address space.

IPv6 will reduce BGP problems. Just the opposite. Not only will the size of the IPv6 global routing table increase, IPv6 BGP tables use more space (and more bandwidth) than the corresponding IPv4 BGP tables.

IPv6 has better quality of service. Total nonsense; the only widespread QoS mechanism is DiffServ that uses DSCP.

IPv6 has better security. Not true. IPSec might be better integrated in IPv6 headers, but there’s nothing you can do with IPv6 IPSec that you cannot do with IPv4 IPSec.

Residential IPv6 is less secure because it does not require NAT. Anyone who thinks NAT is a security feature deserves to become part of a botnet.

23 comments:

  1. with no security config on the CPE (no port forwarding, no ACL, no FW, ...), it is easier to scan a public ipv6 address than a private ipv4 address (from the outside). therefore, NAT is more secure :) you can add me to your botnet now :)

    ReplyDelete
  2. И таки нат хоть и небольшая, но подпорка к секьюрити...

    ReplyDelete
  3. And how long would it take you to scan 2^64 addresses?

    ReplyDelete
  4. I assume we know the ipv6 address of the host behind the CPE. I agree that scanning an ipv6 subnet is more pain than scanning an ipv4 subnet.

    ReplyDelete
  5. And how would you know the IPv6 address of the host? If you've gleaned it from web server logs, it's (recently) way easier to download malware through the browser than through OS vulnerability.

    ReplyDelete
  6. BTW, to answer your original question:

    * stateful FW (or at least a reasonable ACL) will have to become a default configuration of low-end ($2.99 ;) CPE routers.
    * consumer NAT (not the Cisco IOS implementation) makes inside host vulnerable as soon as it opens an outbound session (at least on UDP).

    ReplyDelete
  7. I'm trying to come up with an argument against a firewall by default. That breaks the end to end model, and would make deploying new applications almost as hard with IPv6 as it is with IPv4.

    Modern hosts have grown up in the jungle, and my laptop I take around with me anywhere. Certainly to unprotected networks. What value does that firewall give me anyway? Most of the 'security' issues in the home aren't things which are caught by a firewall anyway.

    If you are concerned about simpler devices like printers and sensors; one could give them only a ULA address and virtually keep them off the big bad Internet.

    ReplyDelete
  8. i don't think the way we learn the ipv6 address of the host matters... it could be via bittorrent, webserver logs, whatever... your discussion is about ipv6 vs ipv4, not about browser vulns vs os/apps vulns, right?

    ReplyDelete
  9. 1) adding a stateful FW in low-end CPEs probably means more bugs for the end user :)

    2) vulnerable how exactly? what can the attacker inject from the outside besides packets from the UDP flow?

    note that you add a condition "as soon as ...". With ipv6, no condition required, I can send all the bad packets I want to my target since its address is public.

    ReplyDelete
  10. "Anyone who thinks NAT is a security feature deserves to become part of a botnet."

    I love it!

    For those who aren't getting it: NAT by itself does not provide security. Dynamic NAT (aka PAT, aka overloaded NAT, aka multiplexing multiple conversations onto a single layer 3 address using layer 4 port translations) provides some degree of security because it has the side effect of creating state. You will need to run a simple stateful firewall in front of IPv6 clients to get the same effect. This is not a hard problem. Stateful firewalls have no place in front of servers in the first place; owners of IPv6 server farms will need to ensure that their vendor supports stateless ACLs in hardware for IPv6 just like they do for IPv4.

    ReplyDelete
  11. What about enhanced Multicast?

    I think it's great on a site-local level, it's gonna be huge on a global level.

    ReplyDelete
  12. @Ole: I prefer IPv6 statefull fireewalls instead of NAT. Which solution breaks end2end more?

    @Ivan: Agree with most of the explanations except:

    IPv6 has better quality of service - that's standard in the header, not just recomandation as in v4.

    IPv6 has better security - partially agree - in v4 ipsec is in userspace, in v6 in stack. Huge difference.

    Overall I agree with Ivan. I specially like the last myth. The last myth to break remains ICMP role in networks - in general. That's hard to understand for some people, specially ones coming strictly from v4 world :)

    Jan

    ReplyDelete
  13. IVAN

    I agree with all the myths except LISP and not able to understand what exactly the problem is? I think more discussion and debate on LISP will get some fruitful results. O:-)

    ReplyDelete
  14. @Jan Zorz: Both IPv4 and IPv6 provide an 8-bit field dedicated for QoS marking. Use of this field in either protocol is completely optional. See http://tools.ietf.org/html/rfc2460#section-7

    ReplyDelete
  15. 99% of NAT on earth is Dynamic NAT. that's what i was talking about. and you say it provides some degree of security. Ok, so we agree. You can join the botnet.

    ReplyDelete
  16. It all depends on how it is presented or when that pitch was made (e.g. - QoS. Yes, today QoS is 99% identical between IPv4 and IPv6 (the other 1% has to due with a better chance of uniquely identifying the true SRC and DST, which is a Good Thing). However, moving forward, that Flow Label (not useful today) may make QoS much better ... while routing table bloat was semi-solved through Forced Aggregation, but now PI space has undone that (but 'solved' multi-homing, for now).)

    Major bonus points for "Anyone who thinks NAT is a security feature deserves to become part of a botnet." :)


    /TJ

    ReplyDelete
  17. Ivan Pepelnjak06 March, 2010 09:46

    Flow label is only useful if you do per-flow QoS, which is not scalable at the line speeds we have today (it could have been useful at T1/E1 and below).

    ReplyDelete
  18. What about mobility?!

    ReplyDelete
  19. Ivan Pepelnjak16 March, 2010 07:11

    Where were you during the last 3 weeks, I've been waiting for you ;) Somehow I've managed to stumble across that one as well; it's included in the more detailed article:

    http://blog.ioshints.info/2010/03/more-details-seven-ipv6-myths.html

    ReplyDelete
  20. Very biased article.
    Many assumptions are made without thinking that the way the Internet works has changed and will change in future.

    ReplyDelete
  21. Ivan Pepelnjak16 March, 2010 18:21

    I would love to hear where you've found the bias. Also, in polite societies (and blogs) people tend to introduce themselves before judging other people's work.

    ReplyDelete
  22. Another short list :-)

    http://www.ismyipv6working.com/the_truth/

    ReplyDelete
  23. Ivan Pepelnjak16 March, 2010 19:58

    Thanks for the list. I like the "you can have 'babe' and 'b00b' in your IP address" part ;) He forgot to mention you there's also 'c0ffee' (if you need it) and 'beef' (if you're really hungry) :-D

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.