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

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 <jhw@nestlabs.com> 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 <jhw@nestlabs.com>
> Nest Labs, Communications Engineering
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet