In message <54f26a38.8070...@gmail.com> Brian E Carpenter writes: > Admittedly 6renum was targetted at enterprise networks, partly because > of the > observation that homenets renumber anyway after every power cut. But > we have spent a lot of cycles on this issue. > > http://tools.ietf.org/html/rfc4192 > http://tools.ietf.org/html/rfc5887 > http://tools.ietf.org/html/rfc6866 > http://tools.ietf.org/html/rfc6879 > http://tools.ietf.org/html/rfc7010 > and maybe it's time to revive > https://tools.ietf.org/html/draft-liu-opsarea-ipv6-renumbering-guidelines > > Brian
Brian, To summarize my prior inelegantly made point: Perhaps the emphasis should not be on "network renumbering is hard" encouraging further whining. The emphasis should not be on "network renumbering does not need to be hard but can be very hard if certain bad network management practices are followed". Through some coincidence or bad karma, my colocation provider arranged for a quick demo. I was typing through an slogin when I noticed no response. To make a long story short the colo provider planned renumbered into a new IPv6 space, sent a mass email which is probably in my spam folder (to: undiclosed; bcc: ..the world..), and then did the renumber. When I called and heard about this it didn't really bother me partly since it Sunday. IPv4 still worked so I could recover. First fix all of my stored config files in one shot. foreach f ( `find * -type f | xargs grep -l 2001:550:3800` ) sed < $f > $f.tmp -e 's,<old>,<new>,g' && mv $f.tmp $f end Then push these out to one bhyve host and two VM. gmake REMOTE_HOST=<host> REMOTE_USER=root SSH_AF_ARG=-4 install Then slogin to each and compare old and new: sh build-02-etc-files.sh -cmp | & less After that check update it sh build-02-etc-files.sh -destdir / -targethost <host> Then for the VM with jails check first foreach j ( <list of jail names> ) sh build-03-jails.sh -cmp -destdir /j0/$j -targethost $j |& less end then update /etc/rc.d/jail stop foreach j ( <list of jail names> ) sh build-03-jails.sh -config-only -destdir /j0/$j -targethost $j end then restart the VMs (old interface was used new one is shown): /etc/bhyve/rc.d/<host> restart Done with everything at the colo site. Then figure out (very easily, look in a file) who is running a caching nameserver with DNS secondaries configured to the old addresses. if it is not a jail: gmake REMOTE_HOST=<host> REMOTE_USER=root SSH_AF_ARG=-4 install if it is a jail then on the supporting host: sh build-03-jails.sh -config-only -destdir /j0/<host> -targethost <host> then ssh <host> -l root /usr/local/etc/rc.d/named stop ssh <host> -l root rm -f /etc/named/s/* ssh <host> -l root /usr/local/etc/rc.d/named start Done with all hosts Now just fix DNS glue records at the registrar and done. The whole thing was under two hours including adding the SSH_AF_ARG support to a bunch of gmake .mk files. 2 rackmount servers 1 destop (DNS only) 4 VM on the 3 rackmounts 16 jails on the 4 VMs rebuild zone files, named.conf (part of the gmake) update sendmail config files all system files such as rc.conf and sshd_config web server config including virtual host configs unaffected were kdc and svn server (no fixed addresses). This was all done remotely (since I still had working IPv4). Not terribly painful. But it could have been. Not planned, but a quick demo of renummbering something that looks a bit more like an enterprise network than a homenet (because it is). Curtis ps- and no these gmake files and perl and shell stuff is not yet available anywhere. Sorry. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet