In message <[email protected]> Brian E Carpenter writes: > 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
These only force a renew before the lease expires. For the sometimes very long IPv6 leases, this is essential. For often relatively shorter IPv4 leases, it is nice but not quite as essential. The issue is not forcing the renew to occur earlier, it is the way in which a renew that changes the address is handled. Maybe its just implementations taking a shortcut, but I think in practice changing the IP address takes the interface down, kills all connections, including listens, and then brings it back up with a new address. Its a bit like a reboot as implemented, except the user doesn't know its coming and therefore may have open TCP connections that break. What I've suggested is what to do on a renew that changes the address. Add an alias. Until the old address has no more connections or listens on the old address, keep the old address. Then remove the old address. If someone has an open connection, ssh for example, the old address could be in use indefinitely, but if the transition is weeks, then its unlikely to go beyond that. For example, if someone was using ssh to do a long compile on another machine, breaking the connection and killing the compile would be bad. There are certain to be plenty of other uses of long duration TCP connections that would have to be broken in this sort of transition, unless we can also extend TCP to negotiate a change to one side of the address pair. Curtis > 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
