[180161] in North American Network Operators' Group
RE: Multiple vendors' IPv6 issues
daemon@ATHENA.MIT.EDU (Tony Hain)
Wed May 27 02:59:49 2015
X-Original-To: nanog@nanog.org
From: "Tony Hain" <alh-ietf@tndh.net>
To: "'David Sotnick'" <sotnickd-nanog@ddv.com>,
"'NANOG'" <nanog@nanog.org>
In-Reply-To: <CALwYWVMrumAkrSRB7dLFtyH7qs2UXP026sAZ0ZHtRE4m17LdNw@mail.gmail.com>
Date: Tue, 26 May 2015 23:59:49 -0700
X-SA-Exim-Mail-From: alh-ietf@tndh.net
Errors-To: nanog-bounces@nanog.org
David,
While I agree with you that there is no excuse for the general IPv6 =
brokenness across all vendors, they are just doing what participants on =
lists like this one tell them. Name&Shame may help a little, but until a =
large number of people get serious and stop prioritizing IPv4 in their =
purchasing demands, the vendors are not going to prioritize IPv6. Until =
the vendors clearly hear a collective "we are not buying this product =
because IPv6 is broken", everyone will get exactly the behavior you are =
witnessing.=20
While I appreciate the challenges you are facing, it is likely that you =
will be helped by documenting the percentage of IPv6 traffic you see =
when things do work. While it may not be much now, that can change =
quickly and will provide internal ammunition when you try to take a =
stand about refusing to use a product. If your IPv6 percentage grows =
anywhere near the 2x/yr rate that Google has been seeing it won't take =
long before IPv6 is the driving protocol. For fun, project this=20
http://www.google.com/intl/en/ipv6/statistics.html forward 4 years and =
hand it to the vendors that can't get their IPv6 act together. Then ask =
them how they plan to still be in business at that point ......
Tony
> -----Original Message-----
> From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of David
> Sotnick
> Sent: Tuesday, May 26, 2015 4:19 PM
> To: NANOG
> Subject: Multiple vendors' IPv6 issues
>=20
> Hi NANOG,
>=20
> The company I work for has no business case for being on the =
IPv6-Internet.
> However, I am an inquisitive person and I am always looking to learn =
new
> things, so about 3 years ago I started down the IPv6 path. This was =
early
> 2012.
>=20
> Fast forward to today. We have a /44 presence for our company's =
multiple
> sites; All our desktop computers have been on the IPv6 Internet since =
June,
> 2012 and we have a few AAAAs in our external DNS for some key services =
=E2=80=94
> and, there have been bugs. *Lots* of bugs.
>=20
> Now, maybe (_maybe_) I can have some sympathy for smaller network
> companies (like Arista Networks at the time) to not quite have their =
act
> together as far as IPv6 goes, but for larger, well-established =
companies to
> still have critical IPv6 bugs is just inexcusable!
>=20
> This month has just been the most disheartening time working with =
IPv6.
>=20
> Vendor 1:
>=20
> Aruba Networks. Upon adding an IPv6 address to start managing our WiFi
> controller over IPv6, I receive a call from our Telecom Lead saying =
that or
> WiFi VoIP phones have just gone offline. WHAT? All I did was add an =
IPv6
> address to a management interface which has *nothing* to do with our =
VoIP
> system or SSID, ACLs, policies, roles, etc.
>=20
> Vendor 2:
>=20
> Palo Alto Networks: After upgrading our firewalls from a version which =
has a
> nasty bug where the IPv6 neighbor table wasn't being cleaned up =
properly
> (which would overflow the table and break IPv6), we now have a *new*
> IPv6 neighbor discovery bug where one of our V6-enabled DMZ hosts just
> falls of the IPv6 network. The only solution: clear the neighbor table =
on the
> Palo Alto or the client (linux) host.
>=20
> Vendor 3:
>=20
> Arista Networks: We are seeing a very similar ND bug with Arista. This =
one is
> slightly more interesting because it only started after upgrading our =
Arista
> EOS code =E2=80=94 and it only appears to affect Virtual Machines =
which are behind
> our RedHat Enterprise Virtualization cluster. None of the hundreds of
> VMware-connected hosts are affected. The symptom is basically the same
> as the Palo Alto bug. Neighbor table gets in some weird state where ND
> breaks and the host is unreachable until the neighbor table is =
cleared.
>=20
> Oh, and the final straw today, which is *almost* leading me to throw =
in the
> IPv6 towel completely (for now): On certain hosts (VMs), scp'ing a =
file over
> the [Arista] LAN (10 gigabit LAN) takes 5 minutes over IPv6 and <1 =
second
> over IPv4. What happened?
>=20
> It really saddens me that it is still not receiving anywhere near the =
kind of
> QA (partly as a result of lack of adoption) that IPv4 has.
>=20
> Oh, and let's not forget everybody's "favorite" vendor, Cisco. Why is =
it,
> Cisco, that I have to restart my IPv6 OSPF3 process on my ASA every =
time my
> Palo Alto firewall crashes and fails over, otherwise none of my VPN =
clients
> can connect via IPv6?
>=20
> Why do you hurt me so, IPv6? I just wanted to be friends, and now I =
just
> want to break up with you. Maybe we can try to be friends again when =
your
> vendors get their shit together.
>=20
> -David
