Skip to content
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

Add Ipv6Addr::to_ipv4_mapped #75019

Merged
merged 1 commit into from
Aug 12, 2020
Merged

Add Ipv6Addr::to_ipv4_mapped #75019

merged 1 commit into from
Aug 12, 2020

Conversation

nanpuyue
Copy link
Contributor

@nanpuyue nanpuyue commented Aug 1, 2020

According to IETF RFC 4291, the "IPv4-Compatible IPv6 address" is deprecated.

2.5.5.1. IPv4-Compatible IPv6 Address

The "IPv4-Compatible IPv6 address" was defined to assist in the IPv6
transition. The format of the "IPv4-Compatible IPv6 address" is as
follows:

| 80 bits | 16 | 32 bits |
+--------------------------------------+--------------------------+
|0000..............................0000|0000| IPv4 address |
+--------------------------------------+----+---------------------+

Note: The IPv4 address used in the "IPv4-Compatible IPv6 address"
must be a globally-unique IPv4 unicast address.

The "IPv4-Compatible IPv6 address" is now deprecated because the
current IPv6 transition mechanisms no longer use these addresses.
New or updated implementations are not required to support this
address type.

And the current implementation of Ipv4Addr::to_ipv6_compatibleis incorrect: it does not check whether the IPv4 address is a globally-unique IPv4 unicast address.

Please let me know if there are any issues with this pull request.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @hanna-kruppe (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 1, 2020
@nanpuyue nanpuyue force-pushed the to_ipv4_mapped branch 4 times, most recently from a89e2ed to 5f0be61 Compare August 2, 2020 03:13
/// Some(Ipv4Addr::new(192, 10, 2, 255)));
/// assert_eq!(Ipv6Addr::new(0, 0, 0, 0, 0, 0, 0, 1).to_ipv4_mapped(), None);
/// ```
pub fn to_ipv4_mapped(&self) -> Option<Ipv4Addr> {
Copy link
Contributor

@tesuji tesuji Aug 2, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
pub fn to_ipv4_mapped(&self) -> Option<Ipv4Addr> {
#[unstable(feature = "ipv4_mapped", issue = "none")]
pub fn to_ipv4_mapped(&self) -> Option<Ipv4Addr> {

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thx~

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do I need to add #![feature(ipv4_mapped)] to the lib.rs?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, certainly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's done.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although there is already an unstable feature named ip, do I still need to add a new unstable feature?

#27709
https://github.com/rust-lang/rust/blob/master/library/std/src/net/ip.rs#L1-L7

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I asked on Zulip and it looks like adding stuff to existing unstable features is fine. So just use the ip feature :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you requested another review: the unstable attribute is still missing. Please add #[unstable(feature = "ip", issue = "27709")] right above the line containing pub fn.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since the following lines have been added at the beginning of this file (ip.rs):

#![unstable(
    feature = "ip",
    reason = "extra functionality has not been \
                                      scrutinized to the level that it should \
                                      be to be stable",
    issue = "27709"
)]

Adding #[unstable(feature = "ip", issue = "27709")] above this fn is unnecessary.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(It is better to give a permanent link to those code lines in the future).

@nanpuyue nanpuyue force-pushed the to_ipv4_mapped branch 3 times, most recently from c889fc3 to 288784e Compare August 2, 2020 06:20
library/std/src/net/ip.rs Outdated Show resolved Hide resolved
@hanna-kruppe
Copy link
Contributor

@lzutao is right, the deprecation should not happen before the replacement is stable. It's also not clear to me why the deprecation in the IETF RFC ("New or updated implementations are not required to support this address type.") should translate to a deprecation of the Rust API (which remains useful for any particular implementation that intends to support such addresses in some way). Both issues can be side-stepped by only adding the new encoding for now, without deprecating anything. Deprecating could be a separate discussion at a later date (e.g., after stabilization of the new API) and should probably go through @rust-lang/libs in some way.

@nanpuyue
Copy link
Contributor Author

nanpuyue commented Aug 2, 2020

There is no replacement for Ipv4Addr::to_ipv6_compatible, it just should be deprecated for the following reasons:

  • The current version of IETF RFC 4291 was released on 2006-02-17. It was a long time ago and before the birth of Rust. The "IPv4-Compatible IPv6 address" was deprecated before 2006.

  • The current implementation of Ipv4Addr::to_ipv6_compatible and Ipv6Addr::to_ipv4 (IPv4-Compatible part) does not check whether the IPv4 address is a globally unique unicast address. This is incorrect (for example, conflicts with the unspecified address and the loopback address), and may mislead the caller.

@tesuji
Copy link
Contributor

tesuji commented Aug 2, 2020

does not check whether the IPv4 address is a globally unique unicast address

Do you want to fix it in a different PR although the intention is to deprecate it ?

@nanpuyue
Copy link
Contributor Author

nanpuyue commented Aug 2, 2020

@lzutao If we want to fix it, we may need to change the return type of Ipv4Addr::to_ipv6_compatible to Option<Ipv6Addr> or panic when the requirements are not met.

@nanpuyue
Copy link
Contributor Author

nanpuyue commented Aug 2, 2020

Perhaps it should be discussed when to deprecate Ipv6Addr::to_ipv4.

@nanpuyue
Copy link
Contributor Author

nanpuyue commented Aug 2, 2020

@lzutao #75046

@hanna-kruppe
Copy link
Contributor

Deprecating a stable method without deprecation sounds like something that needs a @rust-lang/libs FCP, so (rolls dice) r? @LukasKalbertodt

@hanna-kruppe hanna-kruppe added needs-fcp This change is insta-stable, so needs a completed FCP to proceed. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Aug 3, 2020
@nanpuyue nanpuyue mentioned this pull request Aug 4, 2020
Copy link
Member

@LukasKalbertodt LukasKalbertodt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know a lot about IP6 and that stuff, but since it looks like the RFC defines these mappable addresses, it seems useful to add this method, I think.

@hanna-kruppe @lzutao Do you agree adding this as unstable makes sense?

library/std/src/net/ip.rs Outdated Show resolved Hide resolved
/// Some(Ipv4Addr::new(192, 10, 2, 255)));
/// assert_eq!(Ipv6Addr::new(0, 0, 0, 0, 0, 0, 0, 1).to_ipv4_mapped(), None);
/// ```
pub fn to_ipv4_mapped(&self) -> Option<Ipv4Addr> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You still need to add the unstable attribute.

@hanna-kruppe
Copy link
Contributor

I don't know much about networking either, but FWIW I do agree.

/// Converts this address to an [IPv4 address] if it's an "IPv4-mapped IPv6 address"
/// defined in [IETF RFC 4291 section 2.5.5.2], otherwise returns [`None`].
///
/// ::ffff:a.b.c.d becomes a.b.c.d
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This paragraph should still be improved. See my suggestion here

/// Some(Ipv4Addr::new(192, 10, 2, 255)));
/// assert_eq!(Ipv6Addr::new(0, 0, 0, 0, 0, 0, 0, 1).to_ipv4_mapped(), None);
/// ```
pub fn to_ipv4_mapped(&self) -> Option<Ipv4Addr> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you requested another review: the unstable attribute is still missing. Please add #[unstable(feature = "ip", issue = "27709")] right above the line containing pub fn.

@LukasKalbertodt
Copy link
Member

Thanks, the docs look fine now.

But I am somewhat confused: the unstable attribute is still not on the method, right? Or am I completely overlooking something? I am confused as we asked you to add the attribute several times now. Did you overlook those comments by any chance? If it's not clear what we want you to add, just ask :)
But yeah, this PR won't be merged without #[unstable(feature = "ip", issue = "27709")] so you really have to add it. I am actually confused that CI is green with a public method without stable or unstable attribute...

@nanpuyue
Copy link
Contributor Author

@LukasKalbertodt
You may have overlooked this comment from me: #75019 (comment)

@LukasKalbertodt
Copy link
Member

@nanpuyue Oh I indeed missed that comment, I'm sorry! I have never seen the unstable attribute being applied to a module. Interesting!

@bors r+

@bors
Copy link
Contributor

bors commented Aug 12, 2020

📌 Commit d892a07 has been approved by LukasKalbertodt

@bors
Copy link
Contributor

bors commented Aug 12, 2020

🌲 The tree is currently closed for pull requests below priority 1000, this pull request will be tested once the tree is reopened

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 12, 2020
@bors
Copy link
Contributor

bors commented Aug 12, 2020

⌛ Testing commit d892a07 with merge 3df25ae...

@bors
Copy link
Contributor

bors commented Aug 12, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: LukasKalbertodt
Pushing 3df25ae to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Aug 12, 2020
@bors bors merged commit 3df25ae into rust-lang:master Aug 12, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Sep 3, 2020
…le, r=LukasKalbertodt

Add a note for Ipv4Addr::to_ipv6_compatible

Previous discussion: rust-lang#75019

> I think adding a comment saying "This isn't typically the method you want; these addresses don't typically function on modern systems. Use `to_ipv6_mapped` instead." would be a good first step, whether this method gets marked as deprecated or not.

_Originally posted by @joshtriplett in rust-lang#75150 (comment)
JohnTitor added a commit to JohnTitor/rust that referenced this pull request May 26, 2021
Move stability attribute for items under the `ip` feature

The `#[unstable]` attribute for items under the `ip` feature is currently located on the `std::net::ip` module itself. This is unusual, and less readable. This has sidetracked discussion about these items numerous times (rust-lang#60145 (comment), rust-lang#76098 (comment), rust-lang#76098 (comment), rust-lang#75019 (comment), rust-lang#75019 (comment)) and lead to incorrect assumptions about which items are actually stable (rust-lang#60145 (comment), rust-lang#76098 (comment)).

This PR moves the attribute from the module to the items themselves.
JohnTitor added a commit to JohnTitor/rust that referenced this pull request May 26, 2021
Move stability attribute for items under the `ip` feature

The `#[unstable]` attribute for items under the `ip` feature is currently located on the `std::net::ip` module itself. This is unusual, and less readable. This has sidetracked discussion about these items numerous times (rust-lang#60145 (comment), rust-lang#76098 (comment), rust-lang#76098 (comment), rust-lang#75019 (comment), rust-lang#75019 (comment)) and lead to incorrect assumptions about which items are actually stable (rust-lang#60145 (comment), rust-lang#76098 (comment)).

This PR moves the attribute from the module to the items themselves.
@cuviper cuviper added this to the 1.47.0 milestone May 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. needs-fcp This change is insta-stable, so needs a completed FCP to proceed. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants