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

From: James Woodyatt <[email-masked]>
Date: Tue, 7 Oct 2014 16:14:11 -0700

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-masked]>
Nest Labs, Communications Engineering

---

From: James Woodyatt <[email-masked]>
Date: Tue, 7 Oct 2014 16:15:15 -0700

Apologies for the duplicate. It was a manual error, not an automatic one.

On Tue, Oct 7, 2014 at 4:14 PM, James Woodyatt <[email-masked]> wrote:

> 9.1 <https://tools.ietf.org/html/draft-ietf-homenet-prefix-assignment-00#section-9.1>.  ULA Prefix Generation
>
>    o  It is the Network Leader (Section 4.4 <https://tools.ietf.org/html/draft-ietf-homenet-prefix-assignment-00#section-4.4>).
>
> 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.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Oct 2014 13:32:06 +1300

On 08/10/2014 12:14, James Woodyatt wrote:

(quoting draft-ietf-homenet-prefix-assignment-00)

>    randomly generated, or generated from hardware specific values.

That sentence is not OK. It should be:

If no ULA prefix can be found in stable storage, it MUST be generated
as specified in [RFC4193].

> own ULA prefix based on a method defined by its current conventions.

I sincerely hope that method conforms to RFC4193.

    Brian

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 8 Oct 2014 09:22:56 +0200

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-masked]> 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
>    o  It is the Network Leader (Section 4.4).
> 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.)
> 
> -- 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 8 Oct 2014 10:30:53 +0300

> 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 it…

I do not think it precludes use of ULAs otherwise, just prevents their spontaneous generation according to that particular 0-1 ULAs-in-a-network algorithm. 

> (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.)

Just out of curiosity, have you experimented with actually providing ULAs and IPv4 connectivity only to normal hosts? We tried that experiment in late 2012 (Atlanta IETF 86) and the results based on variety of hosts IETF comers came to play with us at the time were somewhat mixed. Some hosts notably wanted to use the ULA instead of v4 (and in one case, even ULA over IPv6 GUA). That, combined with the fact that you more or less have to provide default route to have that ULA usable (thanks to MSR RA option being ignored by half the players out there currently), and you may have trouble.

Cheers,

-Markus

---

From: Pierre Pfister <[email-masked]>
Date: Wed, 8 Oct 2014 09:50:22 +0200

Hello Brian

Please find my answer inline.

> as specified in [RFC4193].

The point was to have a pseudo-random algorithm that always generates the same ULA.
Stable storage can be used, but on most crappy home routers, writing on the SSD too much will kill it in a few thousands writes.

[RFC4193] states:
3.2.1.  Locally Assigned Global IDs

   Locally assigned Global IDs MUST be generated with a pseudo-random
   algorithm consistent with [RANDOM].

If remembering the ULA prefix and using it again and again (using stable storage) is OK, I don’t see why we would need cryptographic pseudo-randomness here.
And actually that’s even worse. Why would a cryptographic pseudo-random function would be used with a *known* seed. 
The ULA doesn’t need to be secret. It just needs to be random enough to avoid collisions.

My point here is that if we conform to RFC4193, we lose the stability of the generated ULA, and IMHO we win nothing.
Correct me if I’m wrong, but I think using hardware specific values as seed is perfectly fine with the collision-avoidance requirement.

Cheers,

Pierre

---

From: James Woodyatt <[email-masked]>
Date: Wed, 8 Oct 2014 11:28:05 -0700

On Tue, Oct 7, 2014 at 5:32 PM, Brian E Carpenter <
[email-masked]> wrote:

> interop

Yes, it does.

---

From: James Woodyatt <[email-masked]>
Date: Wed, 8 Oct 2014 12:08:52 -0700

On Wed, Oct 8, 2014 at 12:30 AM, Markus Stenberg <[email-masked]>
wrote:

> I do not think it precludes use of ULAs otherwise, just prevents their
> spontaneous generation according to that particular 0-1 ULAs-in-a-network
> algorithm.

That may be the intent, but if so then that wasn't clear to me in reading
it.

> Just out of curiosity, have you experimented with actually providing ULAs
> and IPv4 connectivity only to normal hosts? We tried that experiment in
> late 2012 (Atlanta IETF 86) and the results based on variety of hosts IETF
> comers came to play with us at the time were somewhat mixed. Some hosts
> notably wanted to use the ULA instead of v4 (and in one case, even ULA over
> IPv6 GUA). That, combined with the fact that you more or less have to
> provide default route to have that ULA usable (thanks to MSR RA option
> being ignored by half the players out there currently), and you may have
> trouble.
>

Experimented? We shipped already.

Yes, we have some problems with hosts running a certain family of operating
systems that don't process RFC 4191 MSR options. We reported the problem
several years ago, but there are very few signs of anything in the works to
help.

My hope is that we will eventually see industry adoption of HOMENET, which
will provide interior routing domains into which we may advertise our
Thread networks via our border routers, providing interoperability with
those hosts that don't accept MSR options in our RA messages.  In the
meantime, we must do something horrible, crude and proprietary where an
elegant, standard solution would be, of course, so much more preferable.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 8 Oct 2014 22:25:39 +0200

I have a fairly clear memory of this being discussed during a meeting at least. My recollection of the summary was "don't preclude more than one ULA prefix, but try to control creating and announcing more than you really need whenever possible".

Let's be more clear about that in the text. Certainly, if we support multiple prefixes, we shouldn't care if there are one or more than one ULA as far as the routing system is concerned. Any limiting of ULAs should be more about the local decision to fire one up and announce it into the homenet, not whether the homenet accepts it. Conservative in what you send, liberal and what you accept.

- Mark

PS. All that said, as with any operation that causes memory to be allocated and state tracked, it wouldn't be unreasonable for an implementation to start getting suspicious if, say, there are 8x more ULAs than total homenet routers in a given network, or a similarly crazy number coming out of a single homenet router, etc. Avoid DOS vectors at all times ;-)

On Oct 8, 2014, at 9:08 PM, James Woodyatt <[email-masked]> wrote:

> On Wed, Oct 8, 2014 at 12:30 AM, Markus Stenberg <[email-masked]> wrote:
> That may be the intent, but if so then that wasn't clear to me in reading it.
>  
> Yes, we have some problems with hosts running a certain family of operating systems that don't process RFC 4191 MSR options. We reported the problem several years ago, but there are very few signs of anything in the works to help.
> 
> My hope is that we will eventually see industry adoption of HOMENET, which will provide interior routing domains into which we may advertise our Thread networks via our border routers, providing interoperability with those hosts that don't accept MSR options in our RA messages.  In the meantime, we must do something horrible, crude and proprietary where an elegant, standard solution would be, of course, so much more preferable.
> 
> 
> --

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Oct 2014 13:23:34 +1300

> Stable storage can be used, but on most crappy home routers, writing on the SSD too much will kill it in a few thousands writes.

There is nothing in RFC 4193 that prevents saving the generated ULA in
stable storage for future use; so I think you need to be clearer that
when a ULA is generated, it SHOULD be stored for future use (until the
next factory reset). I don't see why that generates more than a very few
writes to SSD.

> The ULA doesn’t need to be secret. It just needs to be random enough to avoid collisions.

Well, yes, but randomness is randomness, i.e. all values are equally likely.
It's really the same thing. I think the assumption was that any box capable
of generating a ULA would already have something better than rand() built in
for other reasons.

> My point here is that if we conform to RFC4193, we lose the stability of the generated ULA, and IMHO we win nothing.

But if you deviate from the standard you need to say so explicitly.
"This procedure deviates from [RFC4193] because...".

> Correct me if I’m wrong, but I think using hardware specific values as seed is perfectly fine with the collision-avoidance requirement.

I would expect so, and I'm not against what you propose, it just needs
to be clearly documented.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Oct 2014 11:45:59 +1100

Why are we arguing about this?

You need to be able to *set* the ULA prefix to something that is
externally generated.  This needs to remembered across reboots,
power cycles etc.

There is no point in having a stable algorithm to generate a ULA
prefix.  As far as I can see the only purpose is to avoid having
any non-volatile memory in the box and I don't see that as a realistic
box.

You will also need non-volatile memory for internal prefix delegation
etc.  You you do want the same prefix to be handed to the same
internal router regardless of the request order.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 9 Oct 2014 11:04:21 +0200

Hello James and Brian,

What do you think of the following proposal ?
It allows any router to generate a ULA (it adds more complexity because collisions must be avoided, even though the Backoff was necessary at boot anyway).
And it conforms to RFC4193 whenever possible (date is available and stable storage can be used).

   A router MAY spontaneously generate a ULA delegated prefix whenever
   the two following conditions are met.

   o  No other ULA delegated prefix is being advertised network-wide.

   o  The ULA Backoff Timer is not running.

   At startup, the ULA Backoff Timer is set to a random value between 0
   and ULA_DELAY_FACTOR * FLOODING_DELAY.  Whenever some other router
   starts advertising a ULA prefix, all routers except the Network
   Leader (Section 4.4) increase their Backoff Timer to a random value
   between 0 and ULA_DELAY_FACTOR * FLOODING_DELAY.

   ULA_DELAY_FACTOR initial value is 2 and is doubled each time the
   router has to withdraw its own spontaneously generated ULA prefix due
   to a collision.  The ULA_DELAY_FACTOR is reset to 2 if at least one
   ULA delegated prefix is advertised network-wide and no new ULA
   delegated prefix is advertised, for a lapse of time of 4 *
   FLOODING_DELAY.

   The most recently used ULA prefix SHOULD be stored in stable storage
   and reused whenever generating a ULA delegated prefix.  If no ULA
   prefix can be found in the stable storage, it MUST be randomly
   generated.

   ULA prefix generation SHOULD conform to [RFC4193].  Nevertheless, if
   the stable storage can't be used or the current date cannot be
   determined, the prefix CAN be pseudo-randomly generated based on
   hardware specific values.

   Not as well that this section doesn't prevent multiple ULA prefixes
   from existing simultaneously.  ULA prefixes may be provided by
   DHCPv6-PD or static configuration, as specified in Section 4.3, in
   which case they are not considered as 'spontaneously' generated and
   MUST NOT be withdrawn if another ULA delegated prefix is observed.

---

From: James Woodyatt <[email-masked]>
Date: Thu, 9 Oct 2014 12:01:11 -0700

On Thu, Oct 9, 2014 at 2:04 AM, Pierre Pfister <[email-masked]>
wrote:

> It allows any router to generate a ULA (it adds more complexity because
> collisions must be avoided, even though the Backoff was necessary at boot
> anyway).
>

As this is a Standards Track requirements draft, I hope to be excused if
I'm seeming to be overly pedantic, but this revision still leaves me
concerned that we are setting requirements that do not admit Thread
networks into HOMENET routing domains.  Here is the excerpt that I find
most troubling:

ULA prefixes may be provided by DHCPv6-PD or static configuration, as
specified in Section 4.3, in which case they are not considered as
"spontaneously" generated and MUST NOT be withdrawn if another ULA
delegated prefix is observed.

My problem is that Thread networks autonomously number themselves with a
ULA /64 prefix, i.e. a ULA /48 prefix with a well-known 16-bit subnet
identifier. This happens when the first element in a disconnected network
commissions itself. Thread networks will keep this /64 prefix as more
elements are commissioned with network credentials to join the mesh. In the
highly likely event that one or more elements capable of acting as Thread
border routers to the HOMENET domain later join the mesh, then each of them
would naturally want to advertise into the HOMENET domain this autonomously
generated ULA /64 prefix. The language in this proposed revision still
seems to admit only ULA delegated prefixes obtained by DHCPv6-PD and by
*static* configuration, but neither of those are applicable in the case of
Thread networks.

I think my concern might be ameliorated by drawing a distinction in the
requirements between a single distinguished Home ULA Prefix and any number
of other Exterior ULA Prefix delegations.  The former prefix is
autonomously generated by the HOMENET router in the Leader role, whereas
the latter are delegated by exterior numbering authorities outside the
HOMENET domain, and they are just like any other globally scoped IPv6
network prefix.

Would it be helpful if I tried to write up a proposed set of edits for this?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Oct 2014 08:12:02 +1300

Works for me, but for RFC 2119, s/CAN/MAY/.

Thanks
   Brian

---

From: Pierre Pfister <[email-masked]>
Date: Thu, 9 Oct 2014 21:26:29 +0200

> 
> I think my concern might be ameliorated by drawing a distinction in the requirements between a single distinguished Home ULA Prefix and any number of other Exterior ULA Prefix delegations.  The former prefix is autonomously generated by the HOMENET router in the Leader role, whereas the latter are delegated by exterior numbering authorities outside the HOMENET domain, and they are just like any other globally scoped IPv6 network prefix.
> 

There is no intent to prevent that at all. And I totally agree with you that ULAs are just prefixes like other.
The last paragraph I put here is just a reminder that, exactly as you want, you can have has many ULA prefixes as you want when they are provided by the mean of the two first points of section 4.3.

The first point is what you want. "delegated by exterior numbering authorities outside the HOMENET" perfectly fits to the first point.
I mean, it can be using DHCP-PD, netconf, static conf, or any other means.

It’s funny cause it looks like adding that last paragraph, that intended to clarify, i making it less clear.

But I’m going to change it and making it more clear that authorities can provide their own prefixes. Even ULAs.

Cheers

- Pierre

---

From: James Woodyatt <[email-masked]>
Date: Thu, 9 Oct 2014 13:49:51 -0700

> provide their own prefixes. Even ULAs.

Thanks! I'm very pleased to see this agreement.

---

From: Pierre Pfister <[email-masked]>
Date: Fri, 10 Oct 2014 08:50:50 +0200

Hello Brian and James,

Thanks for the heads up. CANs will be replaced in next version.

So I’m clarifying the two first points in 4.3

   o  It can be delegated by a service provider (DHCPv6 PD, 6rd
      [RFC5969], etc..).

   o  It can be provisioned by an administrative authority (user
      configuration, netconf [RFC6241], etc... ).

And changing the last paragraph of the ULA generation section.

   Note as well that 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.

Cheers,

- Pierre

Le 9 oct. 2014 à 22:49, James Woodyatt <[email-masked]> a écrit :

> On Thu, Oct 9, 2014 at 12:26 PM, Pierre Pfister <[email-masked]> wrote:
>

---

From: James Woodyatt <[email-masked]>
Date: Fri, 10 Oct 2014 10:10:58 -0700

This makes me feel a lot better. Thanks.