In message <[email protected]>, Curtis Villamizar writes: > > 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).
Define short? There are plenty of homes with equipment that isn't powered down every day and that has been up for months. I don't know about other but I maintain ssh connections for weeks from home to the main office at work. > 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. What's the dhcp stuff in the home? RA's work fine here. What is needed is a way to signal in the DNS to only use a deprecated address as a last resort measure. Named to address and address to name mappings need to exist until after the address has ceased being used. > 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". Actually you should be asking the OS vendors / distro maintainers to do this and send fixes to ISC. This is all done in shell scripts that are highly customised to the client platform. There isn't one linux script that works for all linux distros. This also doesn't work for many udp based services. > 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. At the moment. There is no good reason to not be listening on standard ports if you want to provide your own servers within the home. DNS will almost certainly be done if only to as hidden masters. Just publish your current addresses in the DNS and they can be reached. Cable and DSL are always on services. Homes are no longer dialup. > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
