On Friday, 10 June, 2016 05:48, "Mark Foster" <blak...@blakjak.net> said:
> Router-jockeys and purists often cite this. I've done it myself.
> But there are a lot more moving parts in most service providers than
> simply the ones and zeros.
> Bandwidth Accounting, Billing, Provisioning systems in particular - and
> the developers/maintainers of these who have little or no knowledge of
> IPv6 and perhaps not a lot more than that of IPv4, except that it's more
> easily human-read and digested?
+1. (Actually, +lots)
Making the packet-shifting tin shift v6 packets is not that complex, certainly
not in the normal cycle of equipment upgrades, and assuming you started
thinking about it years ago.
All the business systems that sit around it? Not so much. $DAYJOB has plenty
of code, database structures etc that are built around "an IP address is no
more than 15 characters long and matches
'[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}'". To fix that, you need
development time - typically expensive analyst time to work out *what* you need
to change, not just code-grinder make-the-field-bigger time. IT departments
seem reluctant to provide that resource, unless you've got people at the very
top of the business bought into the fact that you *need* to do IPv6. In my
experience, the IT part of the business, even within an ISP, tends to be the
part that loves their NAT == security and private addressing for everything[0],
so just doesn't see what all the fuss is about...
Even putting that aside, there are decisions to be made as a business around
how you present IPv6 to the customer. Someone in Sales or Finance will want to
be charging per /64 (or worse, per address). Support will want good canned
answers to the "I have a public address now - where is my NAT?" calls. Tech
Pre-Sales will need upskilling to think in networks, not addresses. Probably a
whole bunch more.
Regards,
Tim.
[0] In fairness, this is at least in part due to a decade of beatings from
checklist-monkey auditors, but that's a different rant.
