Hello James,
Thanks for your comment.
I understand your point. I think I was not clear enough in the draft. Nothing
prevents multiple ULAs, but let me explain.
Section 9.1 refers to a spontaneous generation mechanism authorized when there
is no available ULA delegated prefix.
It is mostly useful in order to enable IPv6 in-home networking when there is no
IPv6 uplink, or allow using a ULA when desired
Section 4.3 tells how delegated prefixes may be created
4.3. Obtaining a Delegated Prefix
A Delegated Prefix can be obtained or generated through different
means:
o It can be dynamically delegated, for instance using DHCPv6 PD.
o It can be created statically, specified in router's configuration.
o A ULA prefix may be spontaneously generated as defined in
Section 9.1.
o An IPv4 private prefix may be spontaneously generated as defined
in Section 9.2.
Prefixes that are obtained through DHCPv6 or manually configured CAN be ULAs.
In Thread Networks, do you need a specific ULA (provided by some server) to be
used ?
If ‘yes', you fit in case #2 and can generate as many ULAs as you want.
Or maybe any ULA would work and you are just concerned by the « Being the
network leader » choice ?
The reason for this was to avoid every router to generate their own ULA prefix
when they boot together, and later remove it.
But you made a point here. I think I will allow non-leader routers to generate
a ULA in a randomly delayed fashion.
Cheers,
- Pierre
Le 8 oct. 2014 à 01:14, James Woodyatt <[email protected]> a écrit :
> Everyone—
>
> I have skimmed I-D.ietf-homenet-prefix-assignment, and I have some questions
> and a concern about the topic of ULA Prefix Generation and specifically the
> requirements language used in section 9.1.
>
> 9.1. ULA Prefix Generation
> A router MAY generate a ULA prefix when the two following conditions
> are met.
> o It is the Network Leader (Section 4.4).
> o No other ULA delegated prefix is advertised by any other router.
> A router MUST stop advertising a spontaneously generated ULA prefix
> whenever another router is advertising a ULA delegated prefix.
> The most recently used ULA prefix SHOULD be stored in stable storage
> by all routers and reused whenever choosing a new ULA delegated
> prefix. If no ULA prefix can be found in stable storage, it MUST be
> randomly generated, or generated from hardware specific values.
>
> The requirements keywords in this section make for a pretty serious interop
> clash with Thread networks <http://threadgroup.org/>, which generate their
> own ULA prefix based on a method defined by its current conventions.
>
> If a Thread border router cannot publish its ULA prefix into the HOMENET
> routing domain, unless it is the Network Leader (which it almost certainly
> never will be), then this language would seem to force Thread border routers
> not to use HOMENET standard protocols, and instead to implement some kind of
> non-standard tunneling overlay between devices inside the Thread mesh and
> hosts on the rest of the home network.
>
> Is that what the working group wants to happen? What is the intended purpose
> of this requirement? Is there a way the intended purpose can be served
> without breaking interop with Thread networks?
>
> (My apologies if I missed the relevant discussion. I was trying to pay
> attention, but regular life has been assailing me with other concerns over
> the last year or so. I'm on top of things now, though.)
>
> --
> james woodyatt <[email protected]>
> Nest Labs, Communications Engineering
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
