Excuse front posting, but... > Today there is no DHCP help in avoiding the "please reboot" messages.
Don't RECONFIGURE (DHCPv6) and FORCERENEW (DHCP) cover this, in theory? They are unicast, which is a scaling issue in enterprise networks but presumably not in homenets. Regards Brian On 01/08/2012 04:33, Curtis Villamizar wrote: > In message <[email protected]> > Brian E Carpenter writes: > >> On 31/07/2012 17:59, Michael Richardson wrote: >>>>>>>> "Brian" == Brian E Carpenter <Brian> writes: >>> >> I'm also surprised that we think we have to cope with flash >>> renumbering >>> >> as a regular event, rather than a service-interrupting, ISP truck >>> roll >>> >> catastrophy. >>> >>> Brian> But every time you reboot your antiquated v4-only CPE >>> Brian> and/or the antiquated >>> Brian> v4-only PCs behind it, the PCs all get new IP addresses, >>> Brian> which may or >>> Brian> may not be the same as the previous time. There's nothing >>> Brian> new in flash >>> Brian> renumbering for homenets. Not handling this would be a step >>> Brian> backwards. >>> >>> Well... >>> >>> 1) sure, but the *customer* does this, not the ISP. >>> 2) the clients do have DHCP leases, and if they ask to renew their >>> previous IP, it usually gets honored. >> >> It doesn't matter whether it's the user or the ISP that triggers a >> change, does it? >> >> The point is, users don't care about this, except if they reach their >> shiny new wireless printer via its IP static address. There are >> definitely parts of draft-ietf-6renum-static-problem that apply here. >> >> Brian > > > Brian, > > Enterprise renumbering and homenet renumbering are generally quite > different. Most homehets have short uptimes. Most enterprises have > very long uptimes. (insert favorite Microsoft reliability joke here). > > If a renumbering is done right, there is an time when both the old and > new numbers are in use. As in "ifconfig <intf> inet6 newaddr > ... alias" in the *ix world. During that transition time any use of > DHCP will hand out the new address. Then comes a time when the leases > refuse to be renewed. Then the old addresses go away. This can be > day, weeks, or longer depending on the size of the transition. During > that time a lot of "please reboot at least once ..." messages get > sent. > > Today there is no DHCP help in avoiding the "please reboot" messages. > It should be possible for a DHCP client (ISC guys, are you out there?) > to do the following if a lease can't be renew and a new address is > provided: > > 1. Add the new address using an "ifconfig <intf> ... alias" > equivalent. > > 2. Check (using netstat -an equivalent) for use of the old address. > Don't delete the old address if a socket still exists. > > 3. Periodically repeat step 2 until there is no connection using > the old address. > > 4. Delete the old address using the equivalent of "ifconfig <intf> > ... -alias". > > This would work for all client side connects that either were done > before the end of the transition period. For home nets this covers > 99.something percent of the sites with no user intervention or reboot. > > This requires no protocol change, just better coding in the DHCP > client software. > > What this does not cover is a service that is listenning on a well > known port. This is rare among home nets (except for homes of readers > of IETF lists) but very common among enterprises. > > Many points made about license servers, etc in > draft-ietf-6renum-static-problem don't apply to home nets. > > Renumbering an enterprise is doable. Renumbering my home net has been > quite easy. I've done it a few times already and I'm sure will have > to again. The procedure suggested above is just done manually. > > One hint is that on BSD and Linux at least a "netstat -an" should > reveal any listens on old addresses. An automated scan on an > enterprise network can identify servers and services needing a > reconfig and a service restart without any system reboot. [ Microsoft > systems may need to reboot or power down and remove the CMOS battery > from the motherboard or maybe buy new hardware. :-) ] > >>> In IPv6 space, the host part will generally stay the same (modulo >>> privacy extensions, which are default on for some clients). We've said >>> that the ULA ought to stay the same, so in fact, I agree, the internal >>> addresses actually all stay the same. >>> >>> I'm still surprised that an ISP will need to flash renumber faster than >>> it can just expire leases. If it's just repartitioning of network to >>> deal with growth, that ought to be predictable and prefix lifetimes can >>> be reduced in advance. >>> >>> If it's actually some equipment failing, resulting in service >>> interruptions, and then restoration by rewiring the network... then I >>> understand. > _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
