Re: [v6ops] Operational Consensus on deployment

[Owen DeLong <[e-mail]>]

> The thing is, if you've built your infrastructure on IPv4, removing it
> is going to be a royal pain in the arse. Even if all the IPv4 users have
> left the public internet, if your application server speaks to your
> database server over IPv4, and the database server speaks to the iSCSI
> array over IPv4, and so on and so on, then you're simply not in a
> position to easily shut IPv4 off.

Yes and no…

Upgrading your application to be protocol agnostic about its connection
to the database server shouldn’t be very difficult these days.

Once that’s done, getting your database server to speak dual stack also
shouldn’t be very hard (you’ve been talking to your database vendor about
this for at least a couple of years now, right?).

Surely your iSCSI clients and servers are also on their way to being protocol
agnostic since you’ve been having those discussions with the appropriate vendors
as well, right?

Seems to me that your database server should speak to the iSCSI array
via configured hostname(s) and that if the client and server are dual-stack
capable, then adding IPv6 addresses to interfaces and AAAA records to
DNS should be about all that is required for the communication to move
relatively seamlessly from IPv4 to IPv6.

Likewise with your client <-> database communication.

Once that’s done, it shouldn’t be too hard to remove the A records, wait for
IPv4 to stop carrying traffic (or pick a maintenance window), and drop the
IPv4 addresses from the interfaces (with appropriate regard for quiescence
and/or restart of the various services/clients).

All of this should be achievable with 5 or fewer maintenance windows (2 or
fewer if your software is up to snuff).

Owen