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
Hi Brian,
I'm sort of vaguely aware of this stuff on renumbering and of course
you are an author of much of it. Some comments on this.
btw- this thread is almost certainly on the wrong WG mailing list so
if you'd like to redirect it, that would be a good thing for homenet.
It seems to be entirely enterprise renumbering focused. Therefore
I've dropped the WG from the Cc for now.
The opsarea-ipv6-renumbering-guidelines draft seems like a bad
starting point.
For one thing the advice is change DNS first (break everything) and
then renumber. No mention of dropping TTL to the minimum first which
would be less bad, but still bad (minimum 15 minute outage).
Oh wait ... that is essentially the topic of RFC 4192. Just cite RFC
4192.
If it is a provider or enterprise renumber, then two prefixes are
available. First add aliases allowing everything to be reachable
using either the old or new address. Test. Then change DNS. Retest.
Then long after DNS caches have the new entry, drop the old addresses.
Retest should not be necessary but retest anyway.
Don't bother with ULAs unless there is no way to get a globally
routeable address.
Both routers and hosts with modern operating systems support numbering
the loopback. These usually also support configuring the IPv6
preference to make binding to the loopback preferred without the
source code changes that used to be required in IPv4 years of old.
Perhaps RFC 2894 is a candidate for historic.
It is much easier to use RA and advertise the old prefix with a
prefered lifetime of zero. Not that routers today take advantage of
either AFAIK.
RFC 5887 mentions both using RA and using DHCPv6 FORCERENEW or
RECONFIGURE for renumbering.
Is the use of RA M bit with no prefix or O bit with prefix still
considered ambiguous?
nit: Does anything really have a 128 bit DIP switch to set IPv6
address as implied in RFC 5887? Certainly configured in
flash exists, but DIP switch.
In RFC 5887 section 7. There is no need for address lifetimes in the
socket API if applications don't use bind to set the source address.
RFC 5887 7.1 :
FORCERENEW in particular requires DHCP authentication [RFC3118] to
be deployed.
Really? I can see why since it could be used in a DoS attack if the
host didn't rate limit renewals. But if it did rate limit renewal ...
In RFC 5887 7.2 - ISPs have figured out how to renumber. Most already
generate configurations and push them out automatically even if that
means using a variety of "proprietary methods" (CLI). And yes,
netconf is a good starting point but there may only be a problem for
small routers and/or smaller deployments that still hand configure.
I'm not sure that RFC 6866 and RFC 6879 add much value.
RFC 7010 does add value but IMHO not much.
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". First keep track of
everything that is configured, save the configuration, and know how to
reach that device to reconfigure it. This includes DHCP servers.
<aside type="semi-rabid-rant"> <!-- no reply please :) -->
For example, even for my home net I have a SVN controlled directory
known as system-files. It has every configuration file
(boot/loader.conf, /etc/fstabs, /etc/rc.conf, /etc/mail/*, dhcpd.conf,
rtadvd.conf, etc). It also has shell scripts for anything supporting
an automatable access to configs to compare the running config files
on a host to the stored ones or to update the config. Renumbering was
a breeze - update all configs, mostly with emacs macros, then push out
new configs. I did not have the luxury of a transition period but I
used the old addresses while updating and making the transition to the
new addresses.
I set this up this way because I had worked for an ISP and know that
if they had 2,000 things and didn't know where they were, what configs
they were running, or how to change them remotely, they would have
never survived. Not everyone running an enterprise network has the
benefit of that prior experience. And we certainly can't expect
anyone in a homenet to ever do this which is a big part of why we are
here. And yes, all my rackmount servers and VMs and jails and desktop
are static configured. Nothing is dynamic except those things
connecting on WiFi, where configs (where applicable, which just means
my FreeBSD based laptop) are static but use DHCP and SLAAC.
The fact that most enterprises don't even know how many devices out
there have a DHCP configuration just shows that the state of IT
management practices in enterprise is abysmal. You get what you pay
for. So if IT is mostly recent grad PC weenies with minimal
understanding of networking and a fill in the dialog box and then
forget about it mentality about configuring things, then you have a
mess if renumbering is needed. (No general flame of IT intended.
There are some very competent people in IT, but perhaps too few and
in very many case with too little influence).
</aside>
If you'd like to resurrect the issue of enterprise renumbering in a
new draft, please don't use opsarea-ipv6-renumbering-guidelines as a
starting point. Consider the approach in the paragraph prior to the
aside (aka the rant).
Also consider a "web based configuration consider harmful" draft since
too many consumer and low end enterprise thingies have no means of
fetching or changing configurations that is both secure and can be
automated. Not an issue for home, but definitely contributes to bad
practices in enterprise. Remote configuration of PCs using KVM and
filling in the dialog boxes remotely is also a really bad enterprise
IT practice, particularly as the PC count rises. In addition to being
secure the means of remote configuration should not create hidden
security vulnerabilities (ie: IPMI).
Curtis
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
