On 01/08/2012 15:39, Curtis Villamizar wrote:
> 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.
Really? I can't test it in my current native-IPv6-deprived state, but
it seems to me that Windows (at least) runs happily with multiple IPv6
addresses on one interface, and I can't imagine that changing one of them
will kill the others. I have to admit I haven't studied the semantics
of RECONFIGURE closely, though.
The RFC 4192 model would look a bit sick if the interfaces get reset.
Brian
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
