Hi Phil and list,
Phil Mayers <p.mayers@imperial.ac.uk> writes:
> On 13/04/15 09:55, Benedikt Stockebrand wrote:
>
>> Which is a major effort in some environments because---contrary to what
>> Nick wrote---pretty much anyone involved needs to be familiarized with
>> IPv6. The reason here is that if there is any problem once IPv6 is
>> enabled anywhere, then *all* people doing the troubleshooting need to
>> know how to exclude IPv6 from the list of possible problem causes.
>
> See, this makes sense - it's a reasonable assertion. But it's the
> opposite of what we've found.
and again, different environments *really* differ here:-)
> In all honesty, I doubt a large portion of the organisation
> understands how IPv*4* works. If you think about one of the many areas
> v6 differs -
> ARP/DHCP versus ND/SLAAC/DHCPv6 - how many people *really* understood
> the former that well?
That applies from a network operating point of view, but what about
making applications deal with multiple IP addresses, possibly mixed IPv4
and IPv6, the address selection algorithms, and how both affect the
getaddrinfo(3) library function?
And how about testing for IPv6 compliance in a given environment?
RIPE-554 and similar documents are good starting points, but if you
don't understand them and just throw them at your vendors as is, then
the only result you get is that you buy from the ones that lie to you
most convincingly.
>> [Blame games]
>
> OTOH, we often find the network blamed for basically everything. So
> this is only a small extension ;o)
With IPv6 this can and quite likely will get worse, except of course
that now it's "an IPv6 problem" rather than "a network problem".
For once however, I've long since made it a habit to get out of these
kinds of environments before I can get any reliably experience with this
issue:-)
>> While it's really convenient to use product refresh cycles to enable in
>> some cases, from what I've seen at least in enterprise environments this
>> frequently doesn't work as a general approach.
>
> What problems have you seen? Insufficiently demanding RFP or lack of
> awareness of the need to put it in an RFP? Or something else?
Not so much, but exceedingly long life cycles (think telephony setups in
arbitrary enterprises, 40+ year old Cobol software in banks, building
automation and so on) and---what's essential to really make this
ugly---environments where all these are so tightly interconnected that
it's pretty much impossible to update anything at all without bringing
the entire enterprise to a stop.
While I haven't personally worked with these, I've been involved with
environments where BS2000's are still strong. And apparently there's a
lively second hand market for PDP-11 components as well...
That's actually one of several reasons why ISPs aren't as badly hit by
IPv6 as a lot of enterprises: Their legacy stuff is orders of magnitude
less painful than what you find in many enterprises.
Cheers,
Benedikt
--
Benedikt Stockebrand, Stepladder IT Training+Consulting
Dipl.-Inform. http://www.stepladder-it.com/
Business Grade IPv6 --- Consulting, Training, Projects
BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/
Phil Mayers <p.mayers@imperial.ac.uk> writes:
> On 13/04/15 09:55, Benedikt Stockebrand wrote:
>
>> Which is a major effort in some environments because---contrary to what
>> Nick wrote---pretty much anyone involved needs to be familiarized with
>> IPv6. The reason here is that if there is any problem once IPv6 is
>> enabled anywhere, then *all* people doing the troubleshooting need to
>> know how to exclude IPv6 from the list of possible problem causes.
>
> See, this makes sense - it's a reasonable assertion. But it's the
> opposite of what we've found.
and again, different environments *really* differ here:-)
> In all honesty, I doubt a large portion of the organisation
> understands how IPv*4* works. If you think about one of the many areas
> v6 differs -
> ARP/DHCP versus ND/SLAAC/DHCPv6 - how many people *really* understood
> the former that well?
That applies from a network operating point of view, but what about
making applications deal with multiple IP addresses, possibly mixed IPv4
and IPv6, the address selection algorithms, and how both affect the
getaddrinfo(3) library function?
And how about testing for IPv6 compliance in a given environment?
RIPE-554 and similar documents are good starting points, but if you
don't understand them and just throw them at your vendors as is, then
the only result you get is that you buy from the ones that lie to you
most convincingly.
>> [Blame games]
>
> OTOH, we often find the network blamed for basically everything. So
> this is only a small extension ;o)
With IPv6 this can and quite likely will get worse, except of course
that now it's "an IPv6 problem" rather than "a network problem".
For once however, I've long since made it a habit to get out of these
kinds of environments before I can get any reliably experience with this
issue:-)
>> While it's really convenient to use product refresh cycles to enable in
>> some cases, from what I've seen at least in enterprise environments this
>> frequently doesn't work as a general approach.
>
> What problems have you seen? Insufficiently demanding RFP or lack of
> awareness of the need to put it in an RFP? Or something else?
Not so much, but exceedingly long life cycles (think telephony setups in
arbitrary enterprises, 40+ year old Cobol software in banks, building
automation and so on) and---what's essential to really make this
ugly---environments where all these are so tightly interconnected that
it's pretty much impossible to update anything at all without bringing
the entire enterprise to a stop.
While I haven't personally worked with these, I've been involved with
environments where BS2000's are still strong. And apparently there's a
lively second hand market for PDP-11 components as well...
That's actually one of several reasons why ISPs aren't as badly hit by
IPv6 as a lot of enterprises: Their legacy stuff is orders of magnitude
less painful than what you find in many enterprises.
Cheers,
Benedikt
--
Benedikt Stockebrand, Stepladder IT Training+Consulting
Dipl.-Inform. http://www.stepladder-it.com/
Business Grade IPv6 --- Consulting, Training, Projects
BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/