Skip to content

IPv6 Unicast Interface #85604

Description

@CDirkx

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:

impl Ipv6Addr {
    fn is_unicast_global(&self) -> bool;
    fn is_unicast_link_local(&self) -> bool;
    fn is_unicast_link_local_strict(&self) -> bool;
    fn is_unicast_site_local(&self) -> bool;
}

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 and is_unicast_link_local_strict(#66584 (comment)). is_unicast_link_local tests if an address is in FE80::/10, is_unicast_link_local_strict in the stricter FE80::/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 defines FE80::/10 as the link-local unicast addresses, and that other programming languages and the linux kernel all use FE80::/10 (#76098 (comment), #76098 (comment)). The conclusion seems to be that the current implementation of is_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 in is_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? Should SiteLocal be included in a possible IPv6UnicastScope?

Introduce IPv6UnicastScope

It was suggested (#76098 (comment)) to replace the existing unicast interface with an enum IPv6UnicastScope, similar to IPv6MulticastScope:

impl Ipv6Addr {
    fn unicast_scope(&self) -> Option<IPv6UnicastScope>
}

Positive reaction (#76098 (comment), #76098 (comment))

Unresolved: What would be the definition of IPv6UnicastScope?

RFCs

Previous Discussion

Activity

  1. CDirkx commented on May 25, 2021

    @CDirkx
    ContributorAuthor

    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)?.

  2. CDirkx commented on May 25, 2021

    @CDirkx
    ContributorAuthor

    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)
    
    1. Any address is either unicast or multicast
    2. The unspecified and loopback address are unicast (They are defined under section 2.5 Unicast Addresses)
    3. 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".
    4. 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 be true (2), but what would
    Ipv6Addr::UNSPECIFIED.unicast_scope() return? It can not return Some(LinkLocal) (3), and not Some(Global) (4). None?

    Edit: I checked and for multicast there are also instances where is_multicast() is true, but multicast_scope() returns None, 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
    }
    }

  3. CDirkx commented on May 25, 2021

    @CDirkx
    ContributorAuthor

    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 is_unicast_global and is_unicast_link_local with unicast_scope and

    #[non_exhaustive]
    enum Ipv6UnicastScope {
        LinkLocal,
        Global
    }
  4. added a commit that references this issue on May 31, 2021
  5. added a commit that references this issue on Jun 9, 2021
  6. added a commit that references this issue on Jun 16, 2021
  7. added a commit that references this issue on Jun 16, 2021
  8. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    T-libsRelevant to the library team, which will review and decide on the PR/issue.
    on Feb 22, 2023
  9. added a commit that references this issue on Mar 11, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueCategory: 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.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions