-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IPv6 scoped link-local addresses (RFC4007) #15264
Comments
I think the biggest challenge is about how the zone_id gets exposed and passed around, zone_id can be an interface name on creation of the address, but that info gets lost pretty quickly and it's turned into a numeric interface ID. I believe it's sensible to provide the indextoname API at the same time, so there needs to be naming on the crystal side for both the always-numeric sin6_scope_id and the textual interface name. The parsing from address string part doesn't require any interface change at all, just additional parsing logic. The |
Since the crystal Additionally, While that could be a nice-to-have thing in some scenarios, I think the cons outweigh the potential benefits. |
Yes, I agree on only storing the numeric id, just wondering how to name the result of turning that back into an interface name. Should it be named just |
As mentioned in the inital description as well as in the IETF RFC4007, such interface identifiers are only valid / allowed for link-local IPv6 addresses. In all other cases, this property is supposed to just be You can also immediately specify the numerical interface index as the identifier in the address, e.g. For ease-of-use I'm preferring the ability to specify the interface name instead, and I'd expect the implementation to lookup its corresponding interface index for me (as per the RFC), so that I don't have to that. Within the kernel/libc structs, As for naming the "reverse" operating, I'd lean towards something like |
RFC 4007 actually goes to great pains to differentiate between ipv6 link-local addressing, and the more general construction of scopes and the As for naming, the specification seems clear that "scope" refers to the generic type, i.e. link-local, site-local, global, etc. and "zone" refers to the instance of that scope. So best that it's |
@RX14 these names make sense to me. |
Currently the crystal stdlib does not allow specifying scoped IPv6 link-local addresses.
The specifics around these are described in IETF RFC4007:
https://datatracker.ietf.org/doc/html/rfc4007
The gist of it is:
Per definition IPv6 link-local addresses are scoped to their specific interface (hence the
link-local
). This also means, that you can have the same link-local address on multiple interfaces.Without the ability to specify the corresponding interface as part of the address, using them is pretty much impossible in a meaningful manner.
As per RFC4007, these scoped IPv6 link-local addresses look like e.g.:
fe80::1%eth0
.The kernels and C libraries on the various platforms support exactly that via the
sin6_scope_id
property in thesockaddr_in6
struct.In order to support these in the crystal stdlib it would require some adjustments to
Socket::Address
parsing, its stucts and addingLibC
bindings toif_nameotindex()
and optionallyif_indextoname()
.This should be possible without breaking changes to existing interfaces.
There aren't really any alternatives that I could imagine, such a feature should be supported by the stdlib itself with its native datatypes.
Due to me failing to properly consult the contributing guidelines, I tackled this topic the wrong way around and have already created an implementation of this feature in #15263 .
To separate the discussion of the feature itself and its actual implementation in the stdlib, this feature-request issue is designated for the former.
The text was updated successfully, but these errors were encountered: