Jared Mauch <[email protected]> writes: >> You have at least two addresses to configure, which leads to two DNS >> records, two services to be monitored, more firewall rules, ... And in >> the end more things to document. > > This sure is true in an environment where humans are still the gating factor > in setting the machines up.
Sure. But unfortunately that's the majority of customers I work for. > Where some amount of automation or database driven configuration exist > (and i define database loosely) it will not be measurably more. The > initial investment in the tooling/scripts/magic is the cost. I helped implementing IPv6 for a big German website (well two but the same network, the same servers, same admins, same tools, different developers) back in 2012. The Admins new their infrastructure, developers knew their code, almost everything was automated. And most important: They worked together, exchanged knowledge. After three month everything was ready and there was not much extra work that had to be done. Most work was on the development side (numbers with three dots in between is not a very good regexp for finding valid IPs and integer is most likely to small too save IPv6 addresses to a database). On the other hand I know many enterprises / universities / ISPs / ... who don't automate things. Everything is done manually and any many tasks are just copy'n'paste (and if that fails they have a problem because they don't know what they are doing). One of them is using 2001:db8::/32 internally (well with a typo in the db8 part). They do have IPv4 PI. They could easily implement IPv6 PI. They don't want to. They got used to the problems they have. In the last couple of month I worked on two projects where I really liked to have used some config management system like puppet, saltstack, chef, ... The admins at the customers had heard that such tools exists but haven't had time to decide which one to use. And IPv6 was absolutely no topic (I got "Well the data sheet for the server says that it supports IPb6 that's enough" and "No we don't need IPV6" as reply when I asked about it.) >> 2. Troubleshooting >> >> When looking for problems you always have to remember that there are now >> two >> protocols and then the fun begins: Is this problem only v4? Or only >> v6? Or do have a completely different problem. > > I think there are some issues here due to the divergent functions of tools. Not only that. Remembering that there are two different protocols would be a first step. Not blaming IPv6 when you only see IPv4 traffic in a wireshark trace the next. Talking to each other is also important. One of my favorite examples: http://blog.quux.de/?p=1542 > This means understanding how the tool works. I find this is a skill often > missing, and the subjective reasoning. This is difficult to teach but is > unrelated to IPv6. Troubleshooting is an art. And many people lack the basic knowledge. Don't get me started about DNS problems, ssh-keys, monitoring (or the lack of monitoring), updates, ... >> [1] Someone told me a story about a database server which stopped >> working after IPv6 was deployed. The DB amdin blamed the IPv6 >> deployment. Of course it hat nothing to do with IPv6, the hard drive was >> full. > > And these people need to be called out for not doing their jobs properly. But they won't listen to us. They probably would listen to their boss but he (or she) doesn't know any better. Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: [email protected] | --------------- | ----------------------------------------------------------------------------
