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

[James Woodyatt <[e-mail]>]

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

> On 8.10.2014, at 2.14, James Woodyatt <[e-mail]> wrote:
> > 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.
>
> 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.


-- 
james woodyatt <[e-mail]>
Nest Labs, Communications Engineering