Repository navigation
IPv6 Unicast Interface #85604
Description
Activity
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:
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)- Any address is either unicast or multicast
- The unspecified and loopback address are unicast (They are defined under section 2.5 Unicast Addresses)
- The unspecified and loopback address are not link-local unicast (link-local addresses have prefix
FE80::/10), although of the loopback address it is stated that "it is treated as having Link-Local scope". - The unspecified and loopback address are not global unicast, as per the above table.
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> }
Ipv6Addr::UNSPECIFIED.is_unicast()would have to betrue(2), but what would
Ipv6Addr::UNSPECIFIED.unicast_scope()return? It can not returnSome(LinkLocal)(3), and notSome(Global)(4).None?Edit: I checked and for multicast there are also instances where
is_multicast()istrue, butmulticast_scope()returnsNone, so that is less of a problem then I thought.rust/library/std/src/net/ip.rs
Lines 1498 to 1513 in ff2c947
pub const fn multicast_scope(&self) -> Option<Ipv6MulticastScope> { if self.is_multicast() { match self.segments()[0] & 0x000f { 1 => Some(Ipv6MulticastScope::InterfaceLocal), 2 => Some(Ipv6MulticastScope::LinkLocal), 3 => Some(Ipv6MulticastScope::RealmLocal), 4 => Some(Ipv6MulticastScope::AdminLocal), 5 => Some(Ipv6MulticastScope::SiteLocal), 8 => Some(Ipv6MulticastScope::OrganizationLocal), 14 => Some(Ipv6MulticastScope::Global), _ => None, } } else { None } } My plan forward for the IPv6 unicast interface:
- Fix
is_unicast_globalto check for global unicast scope (currently it tries to check if the address appears globally reachable, which is not the same thing): PR FixIpv6Addr::is_unicast_globalto check for unicast global scope #85696 submitted - Remove
is_unicast_link_local_strict: PR RemoveIpv6Addr::is_unicast_link_local_strict #85819 merged - Remove
is_unicast_site_local: PR RemoveIpv6Addr::is_unicast_site_local #85820 accepted - Add
is_unicast: PR AddIpv6Addr::is_unicast #85791 accepted
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
is_unicast_globalandis_unicast_link_localwithunicast_scopeand#[non_exhaustive] enum Ipv6UnicastScope { LinkLocal, Global }
- Fix
- addedC-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.
on Feb 22, 2023
This issue is split out of the larger discussion around stabilization of the
ipfeature (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_strictConcern was raised about the need for both
is_unicast_link_localandis_unicast_link_local_strict(#66584 (comment)).is_unicast_link_localtests if an address is inFE80::/10,is_unicast_link_local_strictin 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::/10as 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_localis correct and consistent with other implementations,is_unicast_link_local_strictcould be removed.Unresolved: Should
is_unicast_link_local_strictbe 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_localand 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_localbe removed? ShouldSiteLocalbe included in a possibleIPv6UnicastScope?Introduce
IPv6UnicastScopeIt 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