INET6 -- and why I don't use it

[Vadim Goncharov]

Hi Jeremy Chadwick! 

On Wed, 5 Mar 2008 08:01:43 -0800; Jeremy Chadwick wrote about 'Re: INET6 -- and why I don't use it':

>> Makes it harder to debug, etc. Don't want to see anything IPv6 related in
>> command output, to let programs to bind on IPv6 addresses, etc.
> Changing the Subject (but keeping the thread ID reference), since the
> original topic of discussion has now been skewed.
> I have the same attitude Vadim does.  Actually, most of my IPv6 fear
> isn't so much fear as much as it is annoyance and confusion.  Here's
> my list of things, as trivial as they may sound (and I guarantee they
> will):
> * I'm not familiar with the intricacies of the protocol.  This is
> partially my own fault (lack of interest mainly, combined with lack of
> need), while I am very familiar with IPv4.

This is technically not an argument, but has an economic effect of training
staff.

> * The last I read about IPv6 in mainstream news, there were major
> concerns cited over some of the security aspects of the protocol.  I
> also remember reading somewhere that IPv6 was supposed to address issues
> like packet spoofing and DoS -- what became of this?



> * I have never liked how IPv6 denotes its addresses by using colon-
> delimited hexadecimal strings.  I can expand on this if asked, but it's
> more than just "they're MAC-like" (which is also true, even though
> they're grouped by 16-bit values and not octets).  Reading off an IPv4
> address over the phone is bad enough, and typos are even worse.  IPv6?
> Good grief.

+100. And this 128 bit length is absolutely unnecessary - 64 bits of it
are wasted for EUI-64. Moreover, it was debated whether IPv6 will 64 bit or 128
bit - and everyone switched to 128 bit after this message:
http://ftp.sayclub.com/pub/ietf/concluded-wg-ietf-mail-archive/sipp/1994-07
- WITHOUT any discussion. And 64 bit addresses could be much better.

But even more, look how easily currently IPb5' /24 and another such big blocks
are assigned. Do they want to waste 128 bits?!!

> * Consumer ISPs here in the States do not "pass packets" -- you aren't
> given a raw pipe; you're given a physical transport with IPv4 service.
> The reality here is that the vast majority will not embrace IPv6 until
> there's an actual market/need for it.  No consumer ISP I know of
> delegates a customer an IPv6 IP address or netblock.  Backbone providers
> support IPv6 now, yup -- and even some peering providers and
> datacenter/co-location facilities do.  But they're all in the minority.

All this is for money. As currently much of hardware don't support IPv6, there
will be a big upfrade on switching from IPv4. And this would result in a HUGE
money piece flowing to hardware vendors. Of course, they are interested in
IPv6.

> * The "we're running out of address space" argument doesn't hold
> much ground with me.  Yes, it's getting tight, but it's not THAT tight.
> ARIN very regularly returns large amounts of IPv4 space to the world for
> use (I used to be subscribed to NANOG, so I'm aware of this).  Want to
> do something useful?  Start campaigns to get General Electric and MIT to
> give up huge portions of 3/8 and 18/8, respectively.  This is ARIN's
> job, and I sure wouldn't want it.

Agreed.

> * NAT with IPv4 appears to be "solving" most of the address space issues
> in this day and age.  I use quotes because it adds extra complexities
> at the same time (port forwarding, for example, is an annoying
> requirement, mainly because so many protocols were written during the
> days when NAT didn't exist, or are simply badly-written protocols (I'm
> looking at you, Microsoft)).  Only once in my life have I seen a single
> network so large that it required use of 192.168/16, 172.16/12, and 10/8
> all at once.  Another fact is that NAT is **incredibly** integrated in
> consumer society now.  The attitude given is "NAT suffices, use it".
> Until we can teach people "no, it doesn't suffice, and here's why" and
> get people to believe and accept that, it isn't going to change.

Not only. The NAT is very important in function of hiding internal network
structure, may be even more than address limiting problem. I think it is
SO important that some kind of NAT with this function will be created for
IPv6. Of course, this means additional money for hardware vendors!

> * I don't like incorporating "stuff" into my kernel, my utilities, or
> my systems in general which I do not use.  I don't want to see an IPv6
> address on my machines or my network.  Why?  It's about minimalism.  I
> would gladly "embrace" IPv6 if I had reasons to, but I've none,
> therefore I do not.

Sure, me too. Not counting an imapct on the link if it is enabled (I'll least
some below).

> Sufficient?

Not sufficient. So I'll list some more IPv6' evils.

* Too long address. I said about wasted length for EUI-64 - but it means
that MAC address is part of IP address. They could say that it is more handy
to not have ARP e.g. for small devices (IP address for your toaster? huh) -
but that's device memory will be consumpted by too long address, not arp table.

Also, this has a security effect - MAC is globally unique - imagine you've
bought a notebook from somebody, received an IP address... and then police
discovers that his previous owner is a terrorist or MP3s thief.

And not only so - L2/L3 separation in IPv4 is a benefit. Imagine a WWW or DNS
server which has changed his IP because of a NIC change. Of course it can use
logical address, but problem still actual for ordinary users.

* Long addressed have impact on routing. Current /24 prefixes consume
significant amount of memeory in BGP full-view. Imagine /48 prefixes and
four times larger tables due to longer address, huh?

* NAT is absent, but source routing resurrected! What a good thing for
hackers! Not only all internal network structure is clear (no NAT), but
source routing makes it too complex to secure properly... and every
entry is again 128 bit. And this was already exploited - remember SA about
IPv6 routing header?...

* Fragmentation was eliminated! PMTUD is bad, it was invented before dumb
admins blocking ICMP, etc. But with IPv4 you can do ``sysctl
net.inet.tcp.path_mtu_discovery=0'' - with IPv6 you can't. But this is crucial
for tunnels. IPv6 authors live in 80-ties, with no security, tunnels, etc...

* TCP/UDP are left unchanged, with 16 bit ports and 32-bit seq numbers. And
if ports are enough yet (some years to future, currently this is imapct only
for very specific cases), 32-bit seq numbers already have been attacked. Of
course, SCTP can address this, but it will not be popular for several years,
and IPv6 is already here.

* Yes, what we have now? Now we already have bad security. ICMPv6
Routing Advertisement / Router Solicitation - NO auth. No need to fake DHCP
- it is ALWAYS enabled. ARP gone, ARP spoofing is still here. ICMPv6
Neighbor Solicitation / Neighbor Advertisement - you can bomb victim with
fake addresses and become a Man-in-the-Middle. Already now, together with
not authenticated ICMP redirects (Neighbor Discovery Protoco),tested with
Linux and Windows! Can be addressed, of course, but that's YEARS !
Currently the ONLY solution is to disable IPv6 on clients and filter it
on routers.

* IPSEC ?.. How can you use IKE without first discovering peers' MAC ?
That's leads to previous problem. And static keys (the same on all machines,
huh?) are problematic.

* Again routing. Let' take a tester's workstation with two NICs, internal
network is NATed, all is clear on external network. But if you enable
forwarding with IPv6, it will participate in Router Solicitation, unecessary.

* Can list more and describe previous more precisely, but I'm too lazy to
continue :)

* So, the only IPv6 benefits are: more address space and not recomputing
checksum after TTL change.

After all, conclusion is clear - IPv6 is a classical effect of secondary
system (remember Brooks' Mythical Man-Month?). It's historical mission is
collecting bugs for creating IPv8...

It is interesting that in early 90-ies, there were several alternatives, but
disappeared, e.g.
http://www.ietf.cnri.reston.va.us/proceedings/94mar/charters/sipp-charter.html
SIPP lived 03.94 - 08.94
"PIP supported variable length addressing in 16-bit units, separation
of addresses from identifiers, support for provider selection, mobility,
and efficient forwarding." Looks good, instead of IPv6...

And for more than 10 years of developing, with spam and hackers, IPv6 still
assumes friendly Internet and non-limited expanding, not even trying to
look at basics...

Ceterum censeo IPv6 esse delendam!

P.S. Disclaimer. My additions are briefly translated from russian at
http://netch.livejournal.com/tag/ipv6

-- 
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight at mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]