There's been a lot of on-and-off discussion about v6,
especially about security and operational concerns
about some aspects of IPv6 deployment, specifically
regarding neighbor discovery (although there are other
operational security concerns, as well).
I'd like to provide this as an example of those
concerns, without any additional commentary. 
See also:
http://www.ietf.org/mail-archive/web/ietf/current/msg89517.html
Reading the article what occurs to me is:
IPv4 requires a certain amount of administrative personnel overhead.
It's relatively low which is certainly one reason for the success of
IPv4. People are expensive so any new, pervasive technology will be
judged at least in part on its personnel requirements.
I'd go so far as to say that administering large IPv4 networks grows
in personnel roughly as the log of the number of nodes.
If what this is telling us, or warning us, is that IPv6 networks
require higher personnel costs then that could become a big issue.
Particularly among management where they've become used to a few to
several people in a team running the heart of quite large networks.
What if IPv6 deployment doubles or triples that personnel requirement
for the same quality of administration?
Does anyone know of any studies along these lines? My guess is that
there isn't enough data yet.
Reading the article what occurs to me is:
IPv4 requires a certain amount of administrative personnel overhead.
It's relatively low which is certainly one reason for the success of
IPv4. People are expensive so any new, pervasive technology will be
judged at least in part on its personnel requirements.I'd go so far as to say that administering large IPv4 networks grows
in personnel roughly as the log of the number of nodes.
surely this depends a LOT on the quality of the folk doing this job
and their foresight in automating as much as possible, no? (probably
this point isn't for debate, but the point is any network can be run
badly)
If what this is telling us, or warning us, is that IPv6 networks
require higher personnel costs then that could become a big issue.
is this a reflection of 'new technology' to the users (network folk)
in question?
What in ipv6 networking is inherently 'more people required' than ipv4
networking?
Particularly among management where they've become used to a few to
several people in a team running the heart of quite large networks.What if IPv6 deployment doubles or triples that personnel requirement
for the same quality of administration?
this sounds, to me, like: "People need training or comfort with :
instead of . in 'ip address' stuff..." (and other similar differences
between how v4 and v6 operate at scale)
Does anyone know of any studies along these lines? My guess is that
there isn't enough data yet.
that sounds reasonable.
Slightly off topic, but has there ever been a proposed protocol where hosts
can register their L2/L3 binding with their connected switch (which could
then propagate the binding to other switches in the Layer 2 domain)?
Further discovery requests (e.g. ARP, ND) from other attached hosts could
then all be directly replied, eliminating broadcast gratuitous arps. If the
switches don't support the protocol they would default to flooding the
discovery requests.
It seems to me that so many network are caused because of the inability to
change the host mechanisms.
Sam
It looks like in 2011 Cisco proposed a
technology called "OTV" that would do
just that, according to this page:
http://network-101.blogspot.com/2011/03/otv-vs-vpls.html
Granted, it was aimed for wide-area
networking, rather than control within
a datacenter; but as everyone who has
started doing BGP to their top of rack
switches has learned, there's often good
value in adopting techniques and protocols
used in the wide area network within the
datacenter as well.
However, I haven't heard recent mention
of it, so I'm guessing it failed to make a
big enough splash to get any widespread
adoption.
Matt
Also consider the emergence of eVPN and PBB-eVPN.
https://www.ciscolive.com/online/connect/sessionDetail.ww?SESSION_ID=5998&tclass=popup