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.
<https://tools.ietf.org/html/draft-ietf-homenet-prefix-assignment-00#section-9.1> 9.1 <https://tools.ietf.org/html/draft-ietf-homenet-prefix-assignment-00#section-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 <https://tools.ietf.org/html/draft-ietf-homenet-prefix-assignment-00#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
