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 protected]> wrote: > On Wed, Oct 8, 2014 at 12:30 AM, Markus Stenberg <[email protected]> > wrote: > On 8.10.2014, at 2.14, James Woodyatt <[email protected]> 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 <[email protected]> > Nest Labs, Communications Engineering > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
