Visitar URL original
Tracking issue for Ipv{4,6}Addr convenience methods · Issue #27709 · rust-lang/rust · GitHub
Skip to content

Tracking issue for Ipv{4,6}Addr convenience methods #27709

Open
Open
Tracking issue for Ipv{4,6}Addr convenience methods#27709
Labels
A-ioArea: `std::io`, `std::fs`, `std::net` and `std::path`B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCI-libs-radarLibs issues that are tracked on the team's radar.T-libsRelevant to the library team, which will review and decide on the PR/issue.

Description

@alexcrichton
alexcrichton
opened on Aug 12, 2015

View all comments

The below is a list of methods left to be stabilized under the ip feature. The path forward today is unclear; if you'd like to push through any method on here the libs team is interested in a PR with links to the associated RFCs or other official documentation. Let us know!

Steps

Subsets of the listed methods can be stabilized, rather than attempting to stabilize everything at once.

Unresolved Questions

From @KodrAus in #76098 (comment):

  • Should we replace the Ipv6Addr::is_unicast_* methods with a Ipv6Addr::unicast_scope method that returns a Ipv6UnicastScope enum (Stabilize the "IP" feature #76098 (comment))?
  • Should we change the behavior of Ipv6Addr::to_ipv4 to ignore deprecated IPv4-compatible addresses, or deprecate the whole method in favor of the more correct Ipv6Addr::to_ipv4_mapped method (Stabilize the "IP" feature #76098 (comment))?
  • Are we ok with Ipv6Addr::is_* methods now properly considering mapped (non-deprecated) IPv4 addresses? I'd personally be comfortable considering the old behavior a bug.
  • Are there any behavioral differences between other language implementations that we should investigate? (Stabilize the "IP" feature #76098 (comment))

Activity

  1. alexcrichton
    added
    A-io
    T-libs-api[DEPRECATED; DO NOT USE]
    B-unstableBlocker: Implemented in the nightly compiler and unstable.
    on Aug 12, 2015

  2. aturon commented on Nov 3, 2015

    @aturon
    aturon
    on Nov 3, 2015
    Contributor

    I think we should consider this for stabilization in 1.6. Nominating.

  3. aturon
    added
    I-nominated
    on Nov 3, 2015

  4. alexcrichton commented on Nov 5, 2015

    @alexcrichton
    alexcrichton
    on Nov 5, 2015
    MemberAuthor

    🔔 This issue is now entering its cycle-long final comment period for stabilization 🔔

    Concretely, we discussed this in the libs meeting and the conclusion was that the boolean accessors are likely ready for stabilization after verifying that they're all the canonical definitions, but the enum-returning variants will likely remain unstable for now.

  5. alexcrichton
    added
    final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.
    and removed
    I-nominated
    on Nov 5, 2015

  6. briansmith commented on Nov 5, 2015

    @briansmith
    briansmith
    on Nov 5, 2015
    Contributor

    What, exactly, is the "ip feature"? Could you link to the RustDoc(s) of the specific things that are supposed to be reviewed?

  7. SimonSapin commented on Nov 5, 2015

    @SimonSapin
    SimonSapin
    on Nov 5, 2015
    Contributor

    I think "ip feature" in this context refers to things annotated with #![unstable(feature = "ip", …)], which require #![feature(ip)] to be used.

  8. briansmith commented on Nov 6, 2015

    @briansmith
    briansmith
    on Nov 6, 2015
    Contributor

    I think "ip feature" in this context refers to things annotated with #![unstable(feature = "ip", …)], which require #![feature(ip)] to be used.

    I don't mean to be rude, but that's just a restating my question as the answer. if you want people to actually give feedback on the proposal, it should be easier to understand what the proposal is. In this case, it is pretty difficult to tell what is being proposed because the module mixes stable and unstable features.

    I noticed that a large part of this module could work in #![no_std] mode. I suggest moving the #![no_std]-compatible parts to core::net, or at least consider how making it work with #![no_std] would affect the API.

    It also seems odd that Ipv4Addr and Ipv6Addr have things like is_multicast and is_global but there's no trait that allows code to make these queries generically over those types of addresses. If such a trait were to bad added later, would the existence of these non-trait methods cause problems? If so, it might be worth considering building the trait first.

  9. steveklabnik commented on Nov 6, 2015

    @steveklabnik
    steveklabnik
    on Nov 6, 2015
    Contributor

    @briansmith I don't think that's being rude, there's just tension here between "we've been doing this a while so we're a bit short" and "newer people might not know what that is." @SimonSapin leaned a bit towards a literal explanation, but you're right to point out that more detail is good.

    I read @alexcrichton 's comment as:

    that the boolean accessors are likely ready for stabilization after verifying that they're all the canonical definitions,

    http://doc.rust-lang.org/std/net/struct.Ipv4Addr.html and http://doc.rust-lang.org/std/net/struct.Ipv6Addr.html <- all the stuff here that is -> bool

    but the enum-returning variants will likely remain unstable for now.

    http://doc.rust-lang.org/std/net/struct.Ipv6Addr.html#method.multicast_scope is the only one I see that's unstable.

  10. huonw commented on Nov 6, 2015

    @huonw
    huonw
    on Nov 6, 2015
    Contributor

    FWIW, I filed #29221 a while ago, which would make tracking down what these tracking issues refer to slightly easier.

  11. alexcrichton commented on Nov 6, 2015

    @alexcrichton
    alexcrichton
    on Nov 6, 2015
    MemberAuthor

    Yes, to be concrete, I was proposing stabilizing:

    • Ipv4Addr::is_unspecified
    • Ipv4Addr::is_loopback
    • Ipv4Addr::is_private
    • Ipv4Addr::is_link_local
    • Ipv4Addr::is_global
    • Ipv4Addr::is_multicast
    • Ipv4Addr::is_broadcast
    • Ipv4Addr::is_documentation
    • Ipv6Addr::is_unspecified
    • Ipv6Addr::is_loopback
    • Ipv6Addr::is_global
    • Ipv6Addr::is_unique_local
    • Ipv6Addr::is_unicast_link_local
    • Ipv6Addr::is_unicast_site_local
    • Ipv6Addr::is_unicast_global
    • Ipv6Addr::is_multicast

    Note that this is all pending actually verifying that these are standard properties of the respective IP address space and are well known with canonical implementations. I believe they fit this requirement already but would like to double-check.

    @briansmith

    I suggest moving the #![no_std]-compatible parts to core::net

    Yeah these things can certainly move around over time (it's backwards compatible to move them at a later date). I'd be a little wary of putting things in core "just because" without a concrete purpose, and these kinda fall into the category I'd be wary of. For example the internal representation of each of these primitives is the libc equivalent (e.g. libc::sockaddr_in6 or libc::in_addr) which unfortunately isn't available in libcore, so if we move it to core we'd have to invent our own storage format.

    It also seems odd that Ipv4Addr and Ipv6Addr have things like is_multicast and is_global but there's no trait that allows code to make these queries generically over those types of addresses. If such a trait were to bad added later, would the existence of these non-trait methods cause problems?

    Method resolution favors inherent methods (methods defined on the type itself) over trait methods (e.g. impl'd traits plus the trait being in scope), so in that sense we're covered to add a trait at a future date. That being said the standard library doesn't have too many traits like this for abstracting between one or two types, so I would personally want to hold off on this extension for now.

    A possible alternative, however, could be adding the common set of methods to IpAddr if we end up stabilizing that as well.

  12. ollie27 commented on Nov 9, 2015

    @ollie27
    ollie27
    on Nov 9, 2015
    Contributor

    A couple of issues I have noticed with what we have:

    • 0.0.0.0/8, :: and many more ranges shouldn't return true for is_global()
    • Ipv6Addr::is_documentation is missing and should be 2001:db8::/32

    On a more general note, might some of these functions need to be updated in the future if new ranges are assigned? How would that be handled?

  13. 132 remaining items

  14. fgsch commented on Sep 23, 2025

    @fgsch
    fgsch
    on Sep 23, 2025

    What's missing here to get this stabilised? Is just getting @alexcrichton to mark it as such?
    Anything we can do to get this moving?

  15. Elvyria
    added a commit that references this issue on Sep 30, 2025

    Changed is_valid_ipv4 to is_global_ipv4 and added a link to the block…

    606533f
  16. Zalathar
    added a commit that references this issue on Mar 28, 2026

    Rollup merge of rust-lang#154196 - Jules-Bertholet:ipv6-multicast-dis…

    50fe743
  17. rust-timer
    added a commit that references this issue on Mar 28, 2026

    Unrolled build for #154196

    8890616
  18. phash
    added a commit that references this issue on May 12, 2026

    fix(sharer): redact IPs in dbg_log, validate UPnP responses, document…

    b8a9336

  19. DenizUgur commented on May 21, 2026

    @DenizUgur
    DenizUgur
    on May 21, 2026

    What needs to be done for this feature to be stabilized?

  20. alangou
    added 4 commits that reference this issue on Jun 8, 2026

    fix(core): classify TEST-NET-1 and broadcast as internal IPv4

    ed9dd73

    fix(core): classify TEST-NET-1 and broadcast as internal IPv4

    471b69c

    fix(core): classify TEST-NET-1 and broadcast as internal IPv4

    e5ee277

    fix(core): classify TEST-NET-1 and broadcast as internal IPv4

    5e6d7fa

  21. joshhansen commented on Jul 20, 2026

    @joshhansen
    joshhansen
    on Jul 20, 2026

    Just chiming in that a stabilization of IpAddr::is_global, Ipv4Addr::is_global, and Ipv6Addr::is_global would fill an important gap for my project, particularly given is_loopback, is_multicast, and is_unspecified are already present. Or if there is some particular difficulty to stabilizing, it would be helpful to get some word on what that is, in case we might help push it across the finish line. Thanks

  22. clarfonthey
    added
    T-libsRelevant to the library team, which will review and decide on the PR/issue.
    and removed
    T-libs-api[DEPRECATED; DO NOT USE]
    on Aug 12, 2026
  23. WasewaseX
    added 2 commits that reference this issue on Oct 11, 2026

    test+fix(native): adversarial coverage for the download engine and ne…

    4854d9a

    test+fix(native): adversarial coverage for the download engine and ne…

    bd9e1ba
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

    A-ioArea: `std::io`, `std::fs`, `std::net` and `std::path`B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCI-libs-radarLibs issues that are tracked on the team's radar.T-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