Hi Kerry and Michael > Kerry Lynn <kerlyn=40ieee....@dmarc.ietf.org> wrote: > > My main reason is that the draft has no Security Considerations > section, > > and I am not sure the > > scheme can be made secure. I believe the WG should always consider the > > I don't think that the lack of a SC section is a reason not to adopt. > (They are *drafts* and do not need to be complete. This is not WGLC) > > If you think that the scheme can never be secured, then that would be > different.
Yes, this is WG adoption not IETF last call. For the use cases I have in mind, this scheme is actually a lot safer than more dynamic stuff. > > > Second, the fact that routing is based on addressing makes me wonder > > whether this effort > > would encroach on Routing Area's charter. > > I don't think that they want it. There's no routing. Think of a network that's an array or a matrix of sensors, hard wired, like a ccd. Say you want to reach each sensor in the ccd with IPv6/6LoWPAN. You could index them x, y, and encode x, y in an IP address so the addressing is automatic and predictable. No need of ND, all usable addresses known in advance so you can block a number of well-known attacks. Now, say that instead of being organized as an array, the sensors are organized as an hard wired tree (possibly with redundancy depending on the application). Just like you may be doing with a few switches at home today, no meshing, no need for STP. Should that make a difference? Couldn't we automatically and predictably assign an address to each of these sensors? The application I have in mind uses hard wired devices and switches and everything is done at L2. There's a L2 form of L2 learning that feels like transparent bridging. It's over complicated for the need, and prone to bugs. With the proposed scheme, the address embeds the structure of the last hop which can be more complex than x or x,y and still as predictable. From the IP perspective it's still one hop, no routing. > > > Third, one potential application that has been suggested is low-cost > > sensors in server racks, > > yet I have seen no suggested wired MAC for this application. RFC 8163 > > covers this base. > > I don't buy this solution either, btw. You need a good use case for that I guess. Once the WG owns the draft, we can improve the encoding and possibly extend it to more classical physical structure. Note that x and x,y are very simple trees and already supported. All the best Pascal > -- > Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 > IoT consulting =- > > _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
