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
