[homenet] I-D.ietf-homenet-prefix-assignment

[James Woodyatt <[e-mail]>]

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 <[e-mail]>
Nest Labs, Communications Engineering