IPv6 deployment excuses

Mailman List Mirror (Read Only)
1

Hi,

I am in contact with a couple of network operators trying to prod them
to deploy IPv6, I figured that 10 minutes to send a couple of emails
was worth the effort to make them "see a customer demand" (now none of
them can use the excuse that nobody has asked for it!), but the
replies I got were less than impressive to say the least.

I was wondering if you guys could summarise your experiences with
people who make excuses for not deploying IPv6? I regularly see a
specific person saying "we can't deploy it because X" followed by you
guys "correcting them" and telling them how to deploy it without the
problems they claim they will have, but that is only a small snapshot
of the people who bother to post about their ignorance in public. I
suspect there is also a lot of selection-bias in the NANOG membership
base but you deal with a lot of enterprise networks off of this list
so probably have broader experience than the NANOG archives.

Can we have a thread summarising the most common excuses you've heard,
and if they are actual problems blocking IPv6 deployment or just down
to ignorance? Perhaps this could be the basis for an FAQ type page
that I can point people to when they say they don't know how to deploy
IPv6 on their networks? :slight_smile:

- Mike Jones

2

When I talked to one European residential cable provider ca. 2008
they used a similar argument. Fast forward to 2016 and
IPv6 (and dual stack lite) is *the* way they provide Internet access
those days. The reason is simple: their growth rate is way too high
to provide IPv4 to everyone at this point.

If the provider is still using the "see a customer demand" argument
this could mean their IPv4 demand may not be growing fast enough.
Depending on the market they operate on this an be an indication that
their market growth rate may not be fast enough.

Maybe their customer demand for IP(v4) leaves something to be desired?
Or they sit on some almost empty /8s.

Marcin

3

---- From: Mike Jones <mike@mikejones.in> -- Sent: 2016-07-01 - 12:52 ----

Hi,

I am in contact with a couple of network operators trying to prod them
to deploy IPv6, I figured that 10 minutes to send a couple of emails
was worth the effort to make them "see a customer demand" (now none of
them can use the excuse that nobody has asked for it!), but the
replies I got were less than impressive to say the least.

I was wondering if you guys could summarise your experiences with
people who make excuses for not deploying IPv6?

http://ipv6excuses.com/
https://twitter.com/ipv6excuses

4

https://youtu.be/v26BAlfWBm8

Is always good for a reminder and laughs on a holiday weekend.

Jared Mauch

5

http://ipv6excuses.com/

That website only supports IPv4.

Gary

6

>
> http://ipv6excuses.com/

That website only supports IPv4.

It’s on your side.

alarig@pikachu ~ % telnet ipv6excuses.com http
Trying 2403:7000:8000:500::26...
Connected to ipv6excuses.com.
Escape character is '^]'.
^]

quit

Connection closed.

7

---- From: Alarig Le Lay <alarig@swordarmor.fr> -- Sent: 2016-07-01 - 14:53 ----

8

Ok,

I didn't dig.

Evidently it's because not all of the content could be delivered over v6.

9

Jared Mauch wrote:

https://youtu.be/v26BAlfWBm8

Is always good for a reminder and laughs on a holiday weekend.

But, end to end NATs are actually good:

  draft-ohta-e2e-nat-00

fully transparent to all the transport and application layer
protocols.

And, to applications running over TCP/UDP, UPnP capable legacy
NATs are transparent, if host TCP/UDP are modified to perform
reverse NAT, information to do so is provided by UPnP.

            Masataka Ohta

10

Actually they are not that great. Look at the DDoS mess that UPnP has created and problems for IoT (I call it Internet of trash, as most devices are poorly implemented without safety in mind) folks on all sides.

The fact that I go to a hotel and that AT&T mobility have limited internet reach is a technology problem that we all must work to fix.

Jared Mauch

11

Thanks guys, this is what I have come up with so far. Next week i'll
put together a web page or something with slightly better write-ups,
but these are my initial ideas for responses to each point. Better
answers would be welcome.

"We have NAT, therefore we don't need IPv6."
"We still have plenty of IPv4 addresses"
"IPv4 works so we don't need IPv6."

They said similar things about IPX, DECNET, Appletalk........ but they
eventually realised it was easier to move to IP than to keep making
excuses for why their network can't connect to anything.

"we want NAT for IPv6 for security reasons"

NAT does not provide any security, typically a NAT will also include a
stateful firewall which provides the security. You can deploy a
stateful firewall for your IPv6 network if you like, however it isn't
required as much as you probably think it is - see below.

"IPv6 is just another way for hackers to get in."

There is no difference between IPv4 and IPv6 when it comes to
firewalls and reachability. It is worth noting that hosts which
support IPv6 are typically a lot more secure than older IPv4-only
hosts. As an example every version of Windows that ships with IPv6
support also ships with the firewall turned on by default.

"End users don't care about IPv6"

Are you saying this in response to someone asking for IPv6? because
that would be contradictory. I am an end user and I care about IPv6!

"But it isn't a priority and we have other stuff to do"

Reconfiguring every router on your network is not something you want
to rush when you realise you needed IPv6 yesterday, early adopters
have the advantage that they can gain experience with running IPv6 and
test their infrastructure without worrying about critical traffic
being IPv6-only.

"None of the software vendors support IPv6."

If your software vendors were following best practices and writing
decent code then this would not be a problem, I suggest pushing your
vendors to fix their code. If you only have 1 of two systems that are
IPv4-only then you can always "special case" them. See NAT64 for
information about one way of reaching IPv4 hosts from an IPv6 network.
If you dual stack then it doesn't matter and you can just use IPv4 for
those few services than require it until you get a fix from the
vendor.

"None of our staff understand IPv6."

Do your staff understand IPv4? because it's not that different...

"IPv6 addresses are too long to remember"

You shouldn't need to remember IP addresses, that's what DNS is for.
However I will say that in my experience and many other peoples having
the extra bits to structure your network in a logical fasion can make
addresses more obvious and easier to remember. You have a single
prefix to remember, then can address hosts within that subnet however
you like. In IPv4 you rarely have the luxury of being able to number
your DNS server 192.0.2.53 and your web server 192.0.2.80 to make them
easier to remember, whereas in IPv6 you can easily assign hosts easy
to remember addresses.

"Having to dual stack means I still have to manage a 4 and 6 network."

Good point, however if you want to ease your network management and
run an IPv6-only network with IPv4-only services still reachable over
the top of it then there are several ways to do it, the most obvious
being NAT64.

"Our DNS provider won't let us as add AAAA records"

Seriously? who is your DNS provider? You need to ask them why they
don't support standard record types. If they refuse to add standard
records to your zone, get a new provider there are plenty out there.

"We'll deploy IPv6 right after we finish deploying DNSSEC"

The 2 are not mutually exclusive - at a large organisation where this
sort of project would be major work, you probably have different teams
dealing with IP and DNS so there's no reason one would stop the other.

"But Android doesn't support stateful DHCPv6."

I will admit that the specifications were written a little loosely so
you have 2 ways of configuring hosts, however if you configure both RA
and DHCP then you will cover 100% of IPv6-capible hosts.

"Our legal intercept setup does not work with IPv6"

If your lawful intercept equipment can't see traffic just because they
used an "unknown" protocol then it has a major flaw!

- Mike Jones

12

Issues I've faced in the past with v6 deployments, from the point of view
of stub networks. Feel free to pick/choose as you wish:

- Badly understood (By the team) methods to assign addressing to servers.
- Poor tooling in regards to log processing/external providers.
- Unknown cost in dev time to debug badly written applications (ie: cheaper
to buy v4 space than assign dev time, which is inherently expensive)
- PMTUD issues (Mostly around PTB handling)
- ECMP issues (Mostly around flow labels and vendor support for that, also
feeds back into PMTUD issues)
- Cogent/HE "spat" causes legitimate concerns about reachability (ie: why
should I buy an extra transit because someone else is playing silly buggers)
- Lack of backbone forces stubs to de-aggregate to much annoyance (but 0
choice) of everyone else
- Maintaining 2x IP stacks is inherently expensive Vs 1

Of course, you can say "v4 has these issues too" to some of these, and call
bullshit on others. That's not the point, I'm just airing some issues that
can be deal breakers.

I would imagine that as v4 becomes more expensive, most of the list will no
longer be an issue.

/Ruairi

13

There is no difference between IPv4 and IPv6 when it comes to
firewalls and reachability. It is worth noting that hosts which
support IPv6 are typically a lot more secure than older IPv4-only
hosts. As an example every version of Windows that ships with IPv6
support also ships with the firewall turned on by default.

Just because the firewall is turned on does not mean that it is configured properly.

Every version of Windows that ships with IPv6 support also ships with the Firewall configured in such a fashion that you may as well have it turned off.

This is especially true in Windows 8 and later where the firewall is reconfigured without your permission by Microsoft every time you install any update whatsoever back to the "totally insecure" default state -- and there is absolutely no way to fix this other than to check, every single minute, that the firewall is still configured as you configured it, and not as Microsoft (and their NSA partners) choose to configure it.

All versions of Windows 8 and later whether using IPv4 or IPv6 are completely unsuitable for use on a network attached to the Internet by any means (whether using NAT or not) that does not include an external (to Windows) -- ie, in network -- statefull firewall over which Windows, Microsoft, (and their NSA partners) have no automatic means of control. If you allow UPnP control of the external statefull firewall from Windows version 8 or later, you may as well not bother having any firewall at all because it is not under your control.

14

Windows 8 and 10 with the most recent service packs default the firewall to
on with very few inbound exemptions.

15

Yes, the default is "on". An exception is added for EVERY SINGLE PIECE of Microsoft Crapware, whether it is needed or not (and in every single case, it is not). And if you turn those exceptions "off", then they are turned back on by Microsoft and their NSA partners for you, without your permission, whenever automatic updates run (and also at other times that I have not determined the trigger). You must continuously check that the firewall (although ON) remains configured as you configured it, or if Microsoft (and their NSA partners) have changed the configuration without your permission.

Of course, most people do not bother configuring the firewall and do not wonder why every piece of Crapware has in incoming exception, and do not bother to turn those off (including some on this list apparently). So they will never notice these nefarious doings which have been a hotbed of discussion on the Internet for many years.

And this is on the latest distribution of Windows 10 including the upcoming anniversary edition and has been that way since at least the first version of Windows 8.

Whether or not Windows 7 also behaves the same way I do not know because I never ran it.

16

There's one other major issue faced by stub networks which I have encountered at $DAYJOB:

- My upstream(s) refuse(s) to support IPv6

This *is* a deal breaker. The pat response of "get new upstreams" is not helpful and shows the distinct bias among this community to the large players who actually have budgets to work with. It's not always possible to change to a better upstream and even when it is, it is often prohibitively expensive. This is particularly the case with colocation where the cost of changing providers is huge as it requires physically relocating equipment. That either requires doubling up (very expensive) or non-trivial downtime (also likely very expensive). This is an especially sad state of affairs given that at least one very large network (AS701) has pulled this refusal at some data centres on their network. Their specific excuse du jour changes every few months but it usually boils down to "we don't want to put any effort or resources into updating anything".

17

And they must be right as their clients won't go away... :stuck_out_tongue:

18

Security that is too strict will be disabled and be far less effective than proper security measures. Security zealots are often blind to that.

19

Living in an area where we have a dense pocket without broadband available is a key problem. The two incumbents fail to service the area despite one having fiber 1200' away at the entry to our street.

One area incumbent can do native v6, the other does 6rd but they don't serve the area so it's even moot. I'm in the process of building my own fiber now due to this problem. The service will likely look like native v6 and 100.64 for v4 w/ nat. This penalty for v4 will become more apparent over time is my guess.

Jared Mauch

20

This is a non sequitur.

In what way is the blocking of incoming unsolicited connections not a "proper security measure"?

What gives you (or anyone else) the right to "disable" security measures which you (or anyone else) consider "too strict"?

How do you arrive at the conclusion that disabling unsolicited incoming connections to software that does not require it (and which you do not want to accept such unsolicited incoming connections) is "far less effective" than "proper security measures" (and what are those alleged "proper security measures)?

Explain especially in light of built-in crapware which cannot otherwise be removed from the system because it has been "integrated" by scattering its parts (with no purpose other than to make the crapware non-removeable) into critical components so as to prevent removal without breaking the system?

Please explain how expecting firewall setting to remain set as they have been deliberately set makes one a "security zealot"?

If the ACLs on your Cisco router suddenly decided to change all by themselves because Cisco had decided they did not like the way you had set them, I am quite sure that you take an entirely different position!