rust-cidr
rust-cidr copied to clipboard
stbuehler
ipv6 scope / zone id's?
It would be nice if Ipv6Cidr supported storing the scope id / zone id.
For example, it would be nice if it could parse and store "fe80::%en0/64". I could strip out the scope ID and store it separately, but it wouldn't be pretty because I'm using IpCidr as a key in a BTreeMap, and "fe80::%en0/64" and "fe80::%utun0/64" should not be the same key so I'd need to use a pair or a struct as the key rather than IpCidr directly.
A few thoughts:
- I won't modify
Ipv6Cidr- the main motivation (for me) for this crate is that it can be used inRadixMap- i.e. in a "routing table/tree". For that it needs to represent a bitstring (where prefixes have a sane semantic), and nothing else. - I could add
Ipv6CidrScopedand lots of other related types - but those would mostly be(Ipv6Cidr, u32), so I'm not sure what value they'd add. - rust only has the scope id in sockaddr, not in IpAddr - because sockaddr matches the C sockaddr_in6. It only has a
u32scope id, no string representation, because there (probably) isn't a good way to do that cross platform. (I think the scope id represents the network interface id on all platforms, but what names are allowed, how long, how to resolve them, ...) - Although IPv4 sockaddr_in doesn't have a scope id, it might make sense to implement it for IPv4 as well (there should be platform specific ways to apply those as a socket option)
I'd be willing to review PRs adding new types with scope id - although I think they could easily live in a different crate as well.
Sounds reasonable. Any chance of making ParseableAddress public so I can borrow your parsing code? Not that there's much to it and I could easily lift the code, but it feels like you have an implicit test corpus with your own use case and other users so it's always nice to rely on that rather than my own...
Which is an ironic request given https://github.com/stbuehler/rust-cidr/issues/15. Perhaps it's just best to ignore my previous comment.