Hello,
I tried to make a proposal which would deal with these network splits.
Even though I must say that the PA draft in the first place did not cause any
problem when network splits and joins later (collisions are dealt with). This
adds quite a bunch of complexity, and provides the conceptually pleasant idea
that splited home networks will end-up using different ULAs (even thought it’s
not a problem if they do).
So here it is:
9.1. ULA Prefix Generation
ULA prefixes can be randomly generated as specified in [RFC4193],
enabling stable in-home IPv6 connectivity.
In this section, we say a ULA delegated prefix is 'stable' if it has
been the only advertised ULA delegated prefix for at least
2*FLOODING_DELAY seconds. The behaviour specified in the following
sections tend to reuse a stable ULA prefix as long as its preferred
lifetime is not null.
Additionaly, we say a router is the owner of a spontaneously
generated ULA prefix if it randomly created the prefix in the first
place. A router SHOULD NOT create more than one prefix this way, and
MUST remember all the prefixes they own. As stated in the following
sections, only the owner of a prefix can extend its lifetimes.
9.1.1. Choosing the ULA prefix
When a stable ULA prefix is advertised, all routers SHOULD remember
that prefix alongwith its associated valid and preferred lifetime.
If this prefix stops being advertised (e.g. due to a network split)
while its preferred lifetime is not null, the same ULA prefix SHOULD
be selected using the same valid and preferred lifetimes.
If there was no stable ULA prefix advertised, or if the preferred
lifetime of the prefix was null, a prefix generated as specified in
[RFC4193] SHOULD be used. In case the stable storage can't be used
or the current date cannot be determined, the prefix MAY be pseudo-
randomly generated based on hardware specific values.
9.1.2. Advertising a ULA prefix
A router MAY start advertising a ULA prefix whenever the two
following conditions are met:
o It is the network leader.
o There is no other advertised ULA prefix.
If no IPv6 prefix is available at all, the network leader SHOULD
start advertising a ULA delegated prefix.
Additionaly, a router SHOULD start advertising its own ULA prefix
whenever the three following conditions are met:
o A stable ULA prefix is advertised by another router.
o The router owns the advertised stable ULA prefix.
o The preferred lifetime of the advertised ULA prefix is below 10
minutes.
This allows a router to restart advertising a owned prefix whenever
the preferred lifetime is approaching zero. Which later allows him
to extend the lifetime of the prefix.
A router MUST stop advertising a spontaenously generated ULA prefix
whenever one of the two following condition is met:
o A different ULA prefix is being advertised.
o The same prefix is advertised by another router, and the router
doesn't own that prefix.
9.1.3. Extending prefix lifetime
Routers MUST regularly extend the valid and preferred lifetimes of
the ULA delegated prefix they advertise and own, so that they never
drop to zero.
When a router advertises a prefix it doesn't own, lifetimes are never
extended. When the preferred lifetime of the prefix approaches zero,
either the owner of the prefix will start advertising the prefix with
a non-zero preferred lifetime, or a new prefix will be generated.
9.1.4. Authoritative ULAs
This section doesn't prevent multiple ULA prefixes from existing
simultaneously. ULA prefixes may be provided by different means, as
specified in Section 4.3. Delegated prefixes that are delegated by a
service provider or provisioned by an authority differ from
'spontaneously' generated prefixes. They MUST NOT be withdrawn if
another ULA delegated prefix is observed.
When at least one of such ULA prefixes is used, spontaneously
generated ULA prefixes are withdrawned.
Le 20 oct. 2014 à 23:00, Ted Lemon <[email protected]> a écrit :
> On Oct 20, 2014, at 4:52 PM, James Woodyatt <[email protected]> wrote:
>> I did read what you wrote, and I do not agree that you are taking into
>> account my concerns. Nevertheless, I shall stop arguing my case, and I will
>> accept that I've lost it.
>
> I persist in thinking that we are failing to communicate, but it would be a
> fair criticism to raise that this stuff is difficult to converge on in an
> email conversation, and a draft would be easier to discuss. So I will try to
> write one up in my copious free time this week, and then we can probably
> converge. I hesitate to write the draft because I am not convinced we will
> wind up actually doing what I am proposing, but it's probably worth it even
> if we don't actually proceed with it.
>
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
