IPv6 deployment excuses

Sat Jul 2 16:49:40 UTC 2016

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".

On 16-07-02 09:35 AM, Ruairi Carroll wrote:
> 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
>
>
>
>
>
> On 2 July 2016 at 13:44, Mike Jones <mike at mikejones.in> wrote:
>
>> 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
>>
>