That's a neat tool, and I'd probably use it in my own projects -- I'm a big fan of the shell-script-only approach for userland tools -- but the algorithm it uses has a few rough edges I'd prefer didn't get standardized:
- The hash is taken over a (newline-terminated!) Base64-encoded key and not the raw bytes; there's nothing else in the protocol that would require implementations to have a Base64 encoder. (This might matter in a microcontroller implementation.) It wouldn't be hard to pipe to `base64 -d` before hashing, which would fix this. - I'm a fan of SHA-256 in general, but again, there's nothing else in the protocol that would require implementers to have a SHA-256 engine. (This would definitely matter in a microcontroller implementation.) OTOH, `sha256sum` is a commonly available utility and reasonable to use in a bash script, while `b2sum` is not so much. My prototype also uses the `(subnet & mask) | (hash & ~mask)` construction, though I use the full fe80::/10 space, instead of fe80::/64. There's a decent argument to be made for just using the /64, though -- it's the "interface identifier" portion of the address, which is why that's what RFC 3972 does as well. That said, I'm not sure there's quite the same need for subnetting in a link-local address space. (I also feel like the subnet id/interface id dichotomy is going the way of IPv4 class-based routing, and was probably only conceived of as a clever ploy to keep ISPs from screwing everyone over by only handing out out /120s.) I've taken another look at RFC 3972, and the only way it would work here would be by using well-known modifier and Sec parameters of zero -- and it would force reliance on SHA-1. So I'm now thinking we don't bother. In any case, that makes at least two independent engineering efforts that both use `(subnet & mask) | (hash & ~mask)` rather than using subnet as a prefix for the hash. --Reid
