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 <m...@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