-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 Unicast Interface #85604
Comments
With site-local unicast addresses deprecated, are the only two unicast scopes now link-local and global? If a unicast address is not-link-local, is it always global (and vice versa)?. |
If I read the following table and the rest of RFC 4291 correctly:
This leads to a problem if we would want to model unicast addresses similar to multicast addresses: enum Ipv6UnicastScope {
LinkLocal,
Global
}
impl Ipv6Addr {
fn is_unicast(&self) -> bool;
fn unicast_scope(&self) -> Option<Ipv6UnicastScope>
}
Edit: I checked and for multicast there are also instances where rust/library/std/src/net/ip.rs Lines 1498 to 1513 in ff2c947
|
My plan forward for the IPv6 unicast interface:
After those steps the interface will look like this: impl Ipv6Addr {
fn is_unicast(&self) -> bool;
fn is_unicast_global(&self) -> bool;
fn is_unicast_link_local(&self) -> bool;
} and we can then consider replacing #[non_exhaustive]
enum Ipv6UnicastScope {
LinkLocal,
Global
} |
…r=joshtriplett Remove `Ipv6Addr::is_unicast_link_local_strict` Removes the unstable method `Ipv6Addr::is_unicast_link_local_strict` and keeps the behaviour of `Ipv6Addr::is_unicast_link_local`, see also rust-lang#85604 where I have tried to summarize related discussion so far. My intent is for `is_unicast_link_local`, `is_unicast_site_local` and `is_unicast_global` to have the semantics of checking if an address has Link-Local, Site-Local or Global scope, see also rust-lang#85696 which changes the behaviour of `is_unicast_global` and renames these methods to `has_unicast_XXX_scope` to reflect this. For checking Link-Local scope we currently have two methods: `is_unicast_link_local` and `is_unicast_link_local_strict`. This is because of what appears to be conflicting definitions in [IETF RFC 4291](https://datatracker.ietf.org/doc/html/rfc4291). From [IETF RFC 4291 section 2.4](https://datatracker.ietf.org/doc/html/rfc4291#section-2.4): "Link-Local unicast" (`FE80::/10`) ```text Address type Binary prefix IPv6 notation Section ------------ ------------- ------------- ------- Unspecified 00...0 (128 bits) ::/128 2.5.2 Loopback 00...1 (128 bits) ::1/128 2.5.3 Multicast 11111111 FF00::/8 2.7 Link-Local unicast 1111111010 FE80::/10 2.5.6 Global Unicast (everything else) ``` From [IETF RFC 4291 section 2.5.6](https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.6): "Link-Local IPv6 Unicast Addresses" (`FE80::/64`) ```text | 10 bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ ``` With `is_unicast_link_local` checking `FE80::/10` and `is_unicast_link_local_strict` checking `FE80::/64`. There is also [IETF RFC 5156 section 2.4](https://datatracker.ietf.org/doc/html/rfc5156#section-2.4) which defines "Link-Scoped Unicast" as `FE80::/10`. It has been pointed out that implementations in other languages and the linux kernel all use `FE80::/10` (rust-lang#76098 (comment), rust-lang#76098 (comment)). Given all of this I believe the correct interpretation to be the following: All addresses in `FE80::/10` are defined as having Link-Local scope, however currently only the block `FE80::/64` has been allocated for "Link-Local IPv6 Unicast Addresses". This might change in the future however; more addresses in `FE80::/10` could be allocated and those will have Link-Local scope. I therefore believe the current behaviour of `is_unicast_link_local` to be correct (if interpreting it to have the semantics of `has_unicast_link_local_scope`) and `is_unicast_link_local_strict` to be unnecessary, confusing and even a potential source of future bugs: Currently there is no real difference in checking `FE80::/10` or `FE80::/64`, since any address in practice will be `FE80::/64`. However if an application uses `is_unicast_link_local_strict` to implement link-local (so non-global) behaviour, it will be incorrect in the future if addresses outside of `FE80::/64` are allocated. r? `@joshtriplett` as reviewer of all the related PRs
Add `Ipv6Addr::is_unicast` Adds an unstable utility method `Ipv6Addr::is_unicast` under the feature flag `ip` (tracking issue: rust-lang#27709). Added for completeness with the other unicast methods (see also rust-lang#85604 (comment)) and opposite of `is_multicast`.
…htriplett Remove `Ipv6Addr::is_unicast_site_local` Removes the unstable method `Ipv6Addr::is_unicast_site_local`, see also rust-lang#85604 where I have tried to summarize related discussion so far. Unicast site-local addresses (`fec0::/10`) were deprecated in [IETF RFC rust-lang#3879](https://datatracker.ietf.org/doc/html/rfc3879), see also [RFC rust-lang#4291 Section 2.5.7](https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.7). Any new implementation must no longer support the special behaviour of site-local addresses. This is mentioned in the docs of `is_unicast_site_local` and already implemented in `is_unicast_global`, which considers addresses in `fec0::/10` to have global scope, thus overlapping with `is_unicast_site_local`. Given that RFC rust-lang#3879 was published in 2004, long before Rust existed, and it is specified that any new implementation must no longer support the special behaviour of site-local addresses, I don't see how a user would ever have a need for `is_unicast_site_local`. It is also confusing that currently both `is_unicast_site_local` and `is_unicast_global` can be `true` for an address, but an address can actually only have a single scope. The deprecating RFC mentions that Site-Local scope was confusing to work with and that the classification of an address as either Link-Local or Global better matches the mental model of users. There has been earlier discussion of removing `is_unicast_site_local` (rust-lang#60145 (comment)) which decided against it, but that had the incorrect assumption that the method was already stable; it is not. (This confusion arose from the placement of the unstable attribute on the entire module, instead of on individual methods, resolved in rust-lang#85672) r? `@joshtriplett` as reviewer of all the related PRs
…riplett Remove `Ipv6Addr::is_unicast_site_local` Removes the unstable method `Ipv6Addr::is_unicast_site_local`, see also rust-lang#85604 where I have tried to summarize related discussion so far. Unicast site-local addresses (`fec0::/10`) were deprecated in [IETF RFC rust-lang#3879](https://datatracker.ietf.org/doc/html/rfc3879), see also [RFC rust-lang#4291 Section 2.5.7](https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.7). Any new implementation must no longer support the special behaviour of site-local addresses. This is mentioned in the docs of `is_unicast_site_local` and already implemented in `is_unicast_global`, which considers addresses in `fec0::/10` to have global scope, thus overlapping with `is_unicast_site_local`. Given that RFC rust-lang#3879 was published in 2004, long before Rust existed, and it is specified that any new implementation must no longer support the special behaviour of site-local addresses, I don't see how a user would ever have a need for `is_unicast_site_local`. It is also confusing that currently both `is_unicast_site_local` and `is_unicast_global` can be `true` for an address, but an address can actually only have a single scope. The deprecating RFC mentions that Site-Local scope was confusing to work with and that the classification of an address as either Link-Local or Global better matches the mental model of users. There has been earlier discussion of removing `is_unicast_site_local` (rust-lang#60145 (comment)) which decided against it, but that had the incorrect assumption that the method was already stable; it is not. (This confusion arose from the placement of the unstable attribute on the entire module, instead of on individual methods, resolved in rust-lang#85672) r? `@joshtriplett` as reviewer of all the related PRs
This issue is split out of the larger discussion around stabilization of the
ip
feature (tracking issue: #27709). The focus of this issue on the question of what interface Rust should provide for IPv6 unicast adresses.The current unstable interface is as follows:
Open Problems
Behaviour of
is_unicast_link_local
/is_unicast_link_local_strict
Concern was raised about the need for both
is_unicast_link_local
andis_unicast_link_local_strict
(#66584 (comment)).is_unicast_link_local
tests if an address is inFE80::/10
,is_unicast_link_local_strict
in the stricterFE80::/64
. For a time it was unclear which interpretation was the correct one, see #76098 (comment) for a more complete overview. However, it was mentioned (#76098 (comment)) that IETF RFC #5156 Section 2.4 definesFE80::/10
as the link-local unicast addresses, and that other programming languages and the linux kernel all useFE80::/10
(#76098 (comment), #76098 (comment)). The conclusion seems to be that the current implementation ofis_unicast_link_local
is correct and consistent with other implementations,is_unicast_link_local_strict
could be removed.Unresolved: Should
is_unicast_link_local_strict
be removed?Deprecation of site-local addresses
Unicast site-local addresses were deprecated in IETF RFC #3879, see also RFC #4291 Section 2.5.7. Any new implementation must no longer support the special behaviour of site-local addresses. This is mentioned in the docs of
is_unicast_site_local
and already implemented inis_unicast_global
, which considers site-local addresses to be global.For reference; .NET has IsIPv6SiteLocal, Python has is_site_local but mentions that is has been deprecated.
Unresolved: Should
is_unicast_site_local
be removed? ShouldSiteLocal
be included in a possibleIPv6UnicastScope
?Introduce
IPv6UnicastScope
It was suggested (#76098 (comment)) to replace the existing unicast interface with an enum
IPv6UnicastScope
, similar toIPv6MulticastScope
:Positive reaction (#76098 (comment), #76098 (comment))
Unresolved: What would be the definition of
IPv6UnicastScope
?RFCs
Previous Discussion
The text was updated successfully, but these errors were encountered: