On 8.10.2014, at 2.14, James Woodyatt <j...@nestlabs.com> 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. > 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.) 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 _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
