On Mon, Oct 20, 2014 at 12:34 PM, Ted Lemon <[email protected]> wrote:

> On Oct 20, 2014, at 2:00 PM, James Woodyatt <[email protected]> wrote:
> > Okay... except it seems you're admitting that my scenario where a simple
> reconfiguration of a network topology, e.g. one caused by an intermittent
> RF interference on an unlicensed band of the radio spectrum, would result
> in a fully regular and normalized generation of a ULA prefix that would
> subsequently be deprecated on network rejoin and subsequently deprecated
> again. This could happen several times per hour, right?
>
> No, if it's done right the network would have to be partitioned for on the
> order of a week or two before the new ULA would be generated.


Did you respond to my previous criticism of this idea? If so, then I missed
it. It's not a good idea to commission a new standalone network with the
same ULA as a previously commissioned network, because it destroys the main
property of ULA prefixes that makes them useful: the statistical
unlikelihood of merge collisions in the global address realm.


> The reason I think it's beneficial is that it reduces to the minimum the
> number of instances where a long-lived connection will have to be broken
> because of a renumbering event.   I don't think we can reduce that number
> to zero, but I think we can make it a lot less likely than it would be if
> we renumber every time the upstream link goes away.
>

Sounds to me like a benefit of very dubious value at best.  It's a fact
that applications cannot depend on the network never encountering a
renumbering event. That's the whole reason addresses have valid and
preferred lifetimes in the first place.  Applications that use long-lived
IPv6 connections cannot escape the problem that interface addresses may
expire at any time.  If they're not coded to recover from such events, then
it's their logic error, not ours.

I see no reason to work very hard to provide applications with a class of
global scope interface addresses that IETF documents encourage developers
to assume will never reach vltime=0 except when that assumption is
mysteriously invalid anyway because reasons. If there is a good reason for
it, which I'm missing, then I'm happy to consider it.


-- 
james woodyatt <[email protected]>
Nest Labs, Communications Engineering
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to