Skip to content

stabilize the "ip" feature #66584

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

Closed
wants to merge 2 commits into from
Closed

stabilize the "ip" feature #66584

wants to merge 2 commits into from

Conversation

little-dude
Copy link
Contributor

@little-dude little-dude commented Nov 20, 2019

This my first time doing that, so I hope I didn't mess this up.


Stabilize the "ip" feature (fixes #27709), and add a disclaimer about the IP helpers stability (fixes #60239)

Stabilize the following methods:

  • IpAddr::is_global
  • IpAddr::is_documentation
  • Ipv4Addr::is_global
  • Ipv4addr::is_shared
  • Ipv4Addr::is_ietf_protocol_assignment
  • Ipv4addr::is_benchmarking
  • Ipv4Addr::is_reserved
  • Ipv6Addr::is_global
  • Ipv6Addr::is_unique_local
  • Ipv6Addr::is_unicast_link_local_strict
  • Ipv6Addr::is_unicast_link_local
  • Ipv6Addr::is_unicast_site_local
  • Ipv6Addr::is_documentation
  • Ipv6Addr::is_unicast_global
  • Ipv6Addr::multicast_scope

Stabilize the following enum: Ipv6MulticastScope

@rust-highfive
Copy link
Contributor

r? @Kimundi

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 20, 2019
@jonas-schievink jonas-schievink added relnotes Marks issues that should be documented in the release notes of the next release. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Nov 20, 2019
@jonas-schievink jonas-schievink added this to the 1.41 milestone Nov 20, 2019
@jonas-schievink jonas-schievink added the needs-fcp This change is insta-stable, so needs a completed FCP to proceed. label Nov 20, 2019
@little-dude
Copy link
Contributor Author

@the8472, what do you think of the "stability guarantees" disclaimer?

@Dylan-DPC-zz
Copy link

r? @kennytm

@rust-highfive rust-highfive assigned kennytm and unassigned Kimundi Dec 8, 2019
@kennytm
Copy link
Member

kennytm commented Dec 8, 2019

@Dylan-DPC This stabilization PR requires FCP from the libs team. Could you r? a libs team member instead? Thanks.

@Dylan-DPC-zz
Copy link

Thanks for reviewing.

r? @KodrAus

@rust-highfive rust-highfive assigned KodrAus and unassigned kennytm Dec 8, 2019
@little-dude
Copy link
Contributor Author

Hi, is there anything I can do to push this forward?

@Dylan-DPC-zz
Copy link

@little-dude nothing. we will do a team consensus voting after the holiday break.

@Centril Centril modified the milestones: 1.41, 1.42 Dec 20, 2019
@bors
Copy link
Collaborator

bors commented Dec 23, 2019

☔ The latest upstream changes (presumably #67540) made this pull request unmergeable. Please resolve the merge conflicts.

@little-dude
Copy link
Contributor Author

@Dylan-DPC @KodrAus can we start an FCP? I seems that it did not make it to 1.41 so I'd like to make sure it's not forgotten for 1.42.

Copy link
Contributor

@KodrAus KodrAus left a comment

Choose a reason for hiding this comment

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

Thanks for your patience @little-dude!

I’ve just left a few comments around docs, but I don’t think that needs to hold up the FCP.

@rfcbot fcp merge

@@ -124,13 +116,21 @@ pub struct Ipv6Addr {

#[allow(missing_docs)]
Copy link
Contributor

Choose a reason for hiding this comment

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

Let’s make sure we have proper docs for this before stabilizing, which I think would include linking to the appropriate section of the RFC.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I just noticed that the Reserved and Unassigned variants are part of the table but are missing from the enum. Instead, Ipv6Address::multicast_scope() returns None for such scopes. I don't think this is a problem but I think it's worth mentioning. Maybe @therealbstern or @the8472 have an opinion on that API?

Copy link
Contributor

Choose a reason for hiding this comment

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

FWIW, I think Reserved and Unassigned are good things to put in the enum, but my concern is that there's a non-zero chance the Reserved/Unassigned space will get assigned to something in the future.

On the other hand, None is just as wrong as Reserved or Unassigned if the IETF assigns them in the future. In addition, IPv6 is so big that who knows when/if they'll get assigned.

My measured opinion is that we should add Reserved and Unassigned right now, since it's correct right now and might remain correct indefinitely.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it’s something to consider now before stabilization.

Let’s at least drop a #[non_exhaustive] attribute on the enum so we can add those variants later if need be.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, nonexhaustive should cover future RFC changes nicely.

Copy link
Contributor Author

@little-dude little-dude Jan 12, 2020

Choose a reason for hiding this comment

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

sounds good, I'll make the changes.
edit: pushed a commit with the changes.

@kennytm
Copy link
Member

kennytm commented Jan 11, 2020

@KodrAus I think rfcbot only responds to normal comments , not review comments

@little-dude
Copy link
Contributor Author

Thanks for the review @KodrAus. I addressed your comments and squashed the commits.

@rust-highfive
Copy link
Contributor

The job mingw-check of your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
2020-01-11T16:41:58.1082254Z ##[command]git remote add origin https://github.com/rust-lang/rust
2020-01-11T16:41:58.1092634Z ##[command]git config gc.auto 0
2020-01-11T16:41:58.1095047Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2020-01-11T16:41:58.1097051Z ##[command]git config --get-all http.proxy
2020-01-11T16:41:58.1099683Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/66584/merge:refs/remotes/pull/66584/merge
---
2020-01-11T16:47:14.0226461Z 
2020-01-11T16:47:14.0231668Z error: missing documentation for a variant
2020-01-11T16:47:14.0233103Z    --> src/libstd/net/ip.rs:128:5
2020-01-11T16:47:14.0233741Z     |
2020-01-11T16:47:14.0234282Z 128 |     RealmLocal,
2020-01-11T16:47:14.0234944Z 
2020-01-11T16:47:14.0242248Z error: missing documentation for a variant
2020-01-11T16:47:14.0242835Z    --> src/libstd/net/ip.rs:130:5
2020-01-11T16:47:14.0243286Z     |
2020-01-11T16:47:14.0243286Z     |
2020-01-11T16:47:14.0243789Z 130 |     AdminLocal,
2020-01-11T16:47:14.0244492Z 
2020-01-11T16:47:14.0250660Z error: missing documentation for a variant
2020-01-11T16:47:14.0251237Z    --> src/libstd/net/ip.rs:132:5
2020-01-11T16:47:14.0251679Z     |
---
2020-01-11T16:47:15.1851148Z   local time: Sat Jan 11 16:47:14 UTC 2020
2020-01-11T16:47:15.1851302Z   network time: Sat, 11 Jan 2020 16:47:14 GMT
2020-01-11T16:47:15.1851453Z == end clock drift check ==
2020-01-11T16:47:15.3288271Z 
2020-01-11T16:47:15.3401967Z ##[error]Bash exited with code '1'.
2020-01-11T16:47:15.3438874Z ##[section]Starting: Checkout
2020-01-11T16:47:15.3441041Z ==============================================================================
2020-01-11T16:47:15.3441127Z Task         : Get sources
2020-01-11T16:47:15.3441177Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@rust-highfive
Copy link
Contributor

The job x86_64-gnu-llvm-7 of your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
2020-01-11T17:07:41.3277746Z ##[command]git remote add origin https://github.com/rust-lang/rust
2020-01-11T17:07:41.3367572Z ##[command]git config gc.auto 0
2020-01-11T17:07:41.3467798Z ##[command]git config --get-all http.https://github.com/rust-lang/rust.extraheader
2020-01-11T17:07:41.3545204Z ##[command]git config --get-all http.proxy
2020-01-11T17:07:41.3682369Z ##[command]git -c http.extraheader="AUTHORIZATION: basic ***" fetch --force --tags --prune --progress --no-recurse-submodules --depth=2 origin +refs/heads/*:refs/remotes/origin/* +refs/pull/66584/merge:refs/remotes/pull/66584/merge
---
2020-01-11T18:03:55.1640843Z .........................................i...............i.......................................... 4900/9516
2020-01-11T18:04:04.1243654Z .................................................................................................... 5000/9516
2020-01-11T18:04:10.4046039Z ....................................................................................i............... 5100/9516
2020-01-11T18:04:15.6301389Z .................................................................................................... 5200/9516
2020-01-11T18:04:25.7345337Z .......................................................ii.ii...........i............................ 5300/9516
2020-01-11T18:04:34.4841427Z .................................................................................................... 5500/9516
2020-01-11T18:04:44.3599801Z .................................................................................................... 5600/9516
2020-01-11T18:04:50.7021014Z ........................................i........................................................... 5700/9516
2020-01-11T18:04:57.0677045Z .................................................................................................... 5800/9516
2020-01-11T18:04:57.0677045Z .................................................................................................... 5800/9516
2020-01-11T18:05:07.6612347Z .................................................................................................... 5900/9516
2020-01-11T18:05:17.6321747Z ...............................ii...i..ii...........i............................................... 6000/9516
2020-01-11T18:05:35.6243088Z .................................................................................................... 6200/9516
2020-01-11T18:05:43.5974285Z .................................................................................................... 6300/9516
2020-01-11T18:05:43.5974285Z .................................................................................................... 6300/9516
2020-01-11T18:05:55.8164940Z ..........................................................i..ii..................................... 6400/9516
2020-01-11T18:06:22.6238540Z .................................................................................................... 6600/9516
2020-01-11T18:06:24.5427705Z .................................i.................................................................. 6700/9516
2020-01-11T18:06:26.6068859Z .................................................................................................... 6800/9516
2020-01-11T18:06:28.9777598Z .................................i.................................................................. 6900/9516
---
2020-01-11T18:08:01.7311899Z .................................................................................................... 7500/9516
2020-01-11T18:08:05.9110123Z .................................................................................................... 7600/9516
2020-01-11T18:08:11.5621227Z .................................................................................................... 7700/9516
2020-01-11T18:08:18.6888871Z .................................................................................................... 7800/9516
2020-01-11T18:08:28.1009490Z ..................................................................................iiii.............. 7900/9516
2020-01-11T18:08:43.8501346Z ................i......i............................................................................ 8100/9516
2020-01-11T18:08:48.8298843Z .................................................................................................... 8200/9516
2020-01-11T18:09:01.9275715Z .................................................................................................... 8300/9516
2020-01-11T18:09:11.6600860Z .................................................................................................... 8400/9516
---
2020-01-11T18:11:31.0119871Z  finished in 6.663
2020-01-11T18:11:31.0301998Z Check compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
2020-01-11T18:11:31.1878313Z 
2020-01-11T18:11:31.1878426Z running 166 tests
2020-01-11T18:11:34.1280163Z iiii......i........ii..iiii...i....i...........i............i..i..................i....i............ 100/166
2020-01-11T18:11:36.4417049Z i.i.i...iii..iiiiiii.......................iii............ii......
2020-01-11T18:11:36.4420229Z 
2020-01-11T18:11:36.4422487Z  finished in 5.412
2020-01-11T18:11:36.4642774Z Check compiletest suite=codegen-units mode=codegen-units (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
2020-01-11T18:11:36.6210276Z 
---
2020-01-11T18:11:39.1172439Z  finished in 2.069
2020-01-11T18:11:39.1173189Z Check compiletest suite=assembly mode=assembly (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
2020-01-11T18:11:39.1173461Z 
2020-01-11T18:11:39.1173621Z running 9 tests
2020-01-11T18:11:39.1174395Z iiiiiiiii
2020-01-11T18:11:39.1175615Z 
2020-01-11T18:11:39.1175756Z  finished in 0.153
2020-01-11T18:11:39.1176227Z Check compiletest suite=incremental mode=incremental (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
2020-01-11T18:11:39.1176392Z 
---
2020-01-11T18:11:58.2920542Z  finished in 19.568
2020-01-11T18:11:58.3113061Z Check compiletest suite=debuginfo mode=debuginfo-gdb+lldb (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
2020-01-11T18:11:58.4702970Z 
2020-01-11T18:11:59.1253417Z running 124 tests
2020-01-11T18:12:22.1230585Z .iiiii..ii.....i..i...i..i.i.i..i..i..iii....ii.ii....ii..........iiii..........i.....i..ii.......ii 100/124
2020-01-11T18:12:26.0608504Z .i.iii.....iiiiii.....ii
2020-01-11T18:12:26.0609662Z 
2020-01-11T18:12:26.0609888Z  finished in 27.749
2020-01-11T18:12:26.0616449Z Uplifting stage1 rustc (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
2020-01-11T18:12:26.0616950Z Copying stage2 rustc from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
---
2020-01-11T18:24:52.9599246Z 
2020-01-11T18:24:52.9601800Z    Doc-tests core
2020-01-11T18:24:57.3985067Z 
2020-01-11T18:24:57.3986182Z running 2442 tests
2020-01-11T18:25:06.4007083Z ......iiiii......................................................................................... 100/2442
2020-01-11T18:25:15.1091795Z ..................................................................................ii................ 200/2442
2020-01-11T18:25:36.5624826Z ................i................................................................................... 400/2442
2020-01-11T18:25:36.5624826Z ................i................................................................................... 400/2442
2020-01-11T18:25:46.4336733Z .................................................................i..i..................iiii......... 500/2442
2020-01-11T18:26:03.0261973Z .................................................................................................... 700/2442
2020-01-11T18:26:11.5627032Z .................................................................................................... 800/2442
2020-01-11T18:26:20.2680167Z .................................................................................................... 900/2442
2020-01-11T18:26:28.8489678Z .................................................................................................... 1000/2442
---
2020-01-11T18:30:00.6539405Z 
2020-01-11T18:30:00.6540923Z running 1003 tests
2020-01-11T18:30:18.6087733Z i................................................................................................... 100/1003
2020-01-11T18:30:28.4604119Z .................................................................................................... 200/1003
2020-01-11T18:30:35.3509231Z ..................iii......i......i...i......i...................................................... 300/1003
2020-01-11T18:30:40.3186859Z .................................................................................................... 400/1003
2020-01-11T18:30:47.0151382Z ..........................................i..i.....................................ii............... 500/1003
2020-01-11T18:30:59.4372172Z .................................................................................................... 700/1003
2020-01-11T18:30:59.4372172Z .................................................................................................... 700/1003
2020-01-11T18:31:05.8473903Z .............................iiii................................................................... 800/1003
2020-01-11T18:31:19.6151899Z .................................................................................................... 900/1003
2020-01-11T18:31:26.4625820Z ...................................................iiii............................................. 1000/1003
2020-01-11T18:31:26.5578204Z test result: ok. 983 passed; 0 failed; 20 ignored; 0 measured; 0 filtered out
2020-01-11T18:31:26.5578471Z 
2020-01-11T18:31:26.5687545Z  finished in 167.619
2020-01-11T18:31:26.5701526Z Testing term stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
---
2020-01-11T18:48:29.1381698Z Rustbook (x86_64-unknown-linux-gnu) - edition-guide
2020-01-11T18:48:29.5401682Z Building stage0 tool linkchecker (x86_64-unknown-linux-gnu)
2020-01-11T18:48:29.6975223Z    Compiling linkchecker v0.1.0 (/checkout/src/tools/linkchecker)
2020-01-11T18:48:31.1317550Z     Finished release [optimized] target(s) in 1.58s
2020-01-11T18:48:36.8856359Z std/net/enum.IpAddr.html:35: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.8857767Z std/net/enum.IpAddr.html:47: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.8858711Z std/net/enum.IpAddr.html:59: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.8859438Z std/net/enum.IpAddr.html:71: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.8860023Z std/net/enum.IpAddr.html:86: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.8860545Z std/net/enum.IpAddr.html:96: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.8861300Z std/net/enum.IpAddr.html:106: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9118851Z std/net/struct.Ipv4Addr.html:53: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9122802Z std/net/struct.Ipv4Addr.html:73: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9124847Z std/net/struct.Ipv4Addr.html:94: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9125753Z std/net/struct.Ipv4Addr.html:106: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9126411Z std/net/struct.Ipv4Addr.html:171: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9126953Z std/net/struct.Ipv4Addr.html:183: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9127532Z std/net/struct.Ipv4Addr.html:204: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9128060Z std/net/struct.Ipv4Addr.html:218: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9129136Z std/net/struct.Ipv4Addr.html:240: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9129736Z std/net/struct.Ipv4Addr.html:253: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9130244Z std/net/struct.Ipv4Addr.html:264: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9130712Z std/net/struct.Ipv4Addr.html:282: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9131203Z std/net/struct.Ipv4Addr.html:295: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9131667Z std/net/struct.Ipv4Addr.html:306: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9161690Z std/net/struct.Ipv6Addr.html:48: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9167121Z std/net/struct.Ipv6Addr.html:59: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9168251Z std/net/struct.Ipv6Addr.html:70: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9168958Z std/net/struct.Ipv6Addr.html:87: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9170901Z std/net/struct.Ipv6Addr.html:98: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9172410Z std/net/struct.Ipv6Addr.html:136: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9173085Z std/net/struct.Ipv6Addr.html:174: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9173641Z std/net/struct.Ipv6Addr.html:198: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9174162Z std/net/struct.Ipv6Addr.html:210: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9174676Z std/net/struct.Ipv6Addr.html:233: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9175322Z std/net/struct.Ipv6Addr.html:246: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9176091Z std/net/struct.Ipv6Addr.html:257: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:36.9176558Z std/net/struct.Ipv6Addr.html:272: broken link fragment `#ip-addresses-helpers-stability-guarantees` pointing to `std/net/index.html`
2020-01-11T18:48:39.4459819Z thread 'main' panicked at 'found some broken links', src/tools/linkchecker/main.rs:43:9
2020-01-11T18:48:39.4505418Z 
2020-01-11T18:48:39.4505922Z 
2020-01-11T18:48:39.4506724Z command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/linkchecker" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/linkchecker" "/checkout/obj/build/x86_64-unknown-linux-gnu/doc"
2020-01-11T18:48:39.4507028Z expected success, got: exit code: 101
---
2020-01-11T18:48:39.4586051Z   local time: Sat Jan 11 18:48:39 UTC 2020
2020-01-11T18:48:39.7500817Z   network time: Sat, 11 Jan 2020 18:48:39 GMT
2020-01-11T18:48:39.7504636Z == end clock drift check ==
2020-01-11T18:48:41.4090344Z 
2020-01-11T18:48:41.4200104Z ##[error]Bash exited with code '1'.
2020-01-11T18:48:41.4268386Z ##[section]Starting: Checkout
2020-01-11T18:48:41.4269750Z ==============================================================================
2020-01-11T18:48:41.4269795Z Task         : Get sources
2020-01-11T18:48:41.4269845Z Description  : Get sources from a repository. Supports Git, TfsVC, and SVN repositories.

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

@the8472
Copy link
Member

the8472 commented Mar 8, 2020

#69772 raises the question how these helper methods should behave if the ipv6 address is actually an ipv4-compatible or ipv4-mapped address. Maybe that should be discussed before stabilization.

@Centril Centril modified the milestones: 1.43, 1.44 Mar 10, 2020
@KodrAus
Copy link
Contributor

KodrAus commented Mar 11, 2020

@rfcbot concern ipv4 in ipv6

Not identifying ::ffff:127.0.0.1 (the ipv4 loopback address mapped to ipv6) as loopback is an example of where we're not currently considering ipv4 mapped to ipv6 addresses in the helpers. We should try build a list of other helpers that should consider ipv4 in ipv6.

@TyPR124
Copy link
Contributor

TyPR124 commented Mar 17, 2020

Re Ipv6Addr::is_unicast_link_local vs Ipv6Addr::is_unicast_link_local_strict, I personally don't see the value in the strict version, for a few reasons.

  1. Both RFC4291 and RFC5156 specify the entirety of fe80/10 as link-local

  2. In RFC4291, section 2.5 specifies about unicast addresses that "Additional address types or subtypes can be defined in the future" so what is "strict" may change in the future

  3. In the same section, it specifies that "Except for the knowledge of the subnet boundary discussed in the previous paragraphs [referring to fe80/10], nodes should not make any assumptions about the structure of an IPv6 address." This implementation of strict makes the assumption that all fe80/10 addresses must adhere to the structure shown in RFC4291, however the same RFC specifies that nodes should not make this assumption.

Given point 3, I don't see any situation where I would want to check anything but the /10 prefix.

@dillona
Copy link
Contributor

dillona commented Apr 1, 2020

@little-dude do you have a plan for resolving the existing concerns? Could you use a hand?

@Dylan-DPC-zz Dylan-DPC-zz modified the milestones: 1.44, 1.45 Apr 21, 2020
@crlf0710
Copy link
Member

crlf0710 commented May 2, 2020

@little-dude Ping from triage, any updates here?

@crlf0710
Copy link
Member

@little-dude Closing due to inactivity. Free free to reopen or create another PR to address the mentioned concerns above. You might also create a topic on Zulip for discussions. Thanks!

@crlf0710 crlf0710 closed this May 15, 2020
@rfcbot rfcbot removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. disposition-merge This issue / PR is in PFCP or FCP with a disposition to merge it. labels May 15, 2020
@crlf0710 crlf0710 added S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. relnotes Marks issues that should be documented in the release notes of the next release. labels Jul 8, 2020
@crlf0710 crlf0710 removed this from the 1.45 milestone Jul 8, 2020
@caass
Copy link
Contributor

caass commented Aug 29, 2020

Hello! I'd really love to use is_global. I'd be willing to pick up the reigns for this if @little-dude is unavailable. If I understand correctly, the blockers currently are:

  1. There should be some checking for IPv4 addresses mapped it IPv6 space (comment)

From the RFC:

Two types of IPv6 addresses are defined that carry an IPv4 address in the low-order 32 bits of the address. These are the "IPv4-Compatible IPv6 address" and the "IPv4-mapped 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 bits 32 bits
0000..............................0000 0000 IPv4 address

[...]

A second type of IPv6 address that holds an embedded IPv4 address is defined. This address type is used to represent the addresses of IPv4 nodes as IPv6 addresses. The format of the "IPv4-mapped IPv6 address" is as follows:

80 bits 16 bits 32 bits
0000..............................0000 FFFF IPv4 address

If we already have capability to check IPv4 addresses, I feel like it's almost trivial to implement these rules for IPv6 as well if we just need to pad it with some extra bytes? Famous last words, I know...

  1. There's some concern over the need for both is_unicast_link_local_strict and is_unicast_link_local (comment)

From the commit that introduced the change:

RFC 4291 is a little unclear about what is a unicast link local address.
According to section 2.4, the entire fe80::/10 range is reserved for
these addresses, but section 2.5.3 defines a stricter format for such
addresses.

After a discussion is has been decided to add a different method for
each definition, so this commit:

  • renames is_unicast_link_local() into is_unicast_link_local_strict()
  • relaxed the check in is_unicast_link_local()

From section 2.4:

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)

Section section 2.5.3 seems...unrelated? It has to do with the loopback address. Section 2.5.6 however, is where the problem lies:

Link-Local addresses are for use on a single link. Link-Local addresses have the following format:

10 bits 16 bits 64 bits
1111111010 0 interface ID

So the difference in the spec is this:

Spec CIDR Start End Available
2.4 FE80::/10 fe80:0:0:0:0:0:0:0 febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff 2^118
2.5.6 FE80::/64 fe80:0:0:0:0:0:0:0 fe80:0:0:0:ffff:ffff:ffff:ffff 2^64

This does seem like an issue, so I did some more digging to figure out what's going on. I found this draft, which appears to have died. It does however point us in the right direction:

The RFC "IPv6 Address Archi" illustrates the format of the link-local addresses. From the illustration it MAY be understood that the length of the link-local prefix is 10 bits of value 1111111010 and 54 0 bits.

IANA lists the "IPv6 prefix", and "Address Block", to be "fe80::/10" on its website. It is possible that in the future the IETF could decide to use the bits 11-53.

The RFC 2464 "IPv6-over-Ethernet" states that the prefix for link-local addresses is "fe80::/64".

RFC 6874, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers" specifies the link-local addresses to be under prefix "fe80::/10".

I'm not an expert in reading IETF material -- far from it -- but I am vaguely aware of the passage of time. Every document that has been linked here that specifies /64 is more recent than those specifying /10, unless I've missed one. Additionally, there are countless secondhand sources (blogs, stackoverflow, etc) online all talking about how /64 is the spec.

Again, not an expert. I posted all this info here so someone more versed than me can evaluate and decide what the best course of action is. Without further input, I'd personally go ahead with just the one is_unicast_link_local that validates against /64.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Oct 15, 2023
Stabilize `{IpAddr, Ipv6Addr}::to_canonical`

Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable (+const), as well as const stabilize `Ipv6Addr::to_ipv4_mapped`.

Newly stable API:

```rust
impl IpAddr {
    // Newly stable under `ip_to_canonical`
    const fn to_canonical(&self) -> IpAddr;
}

impl Ipv6Addr {
    // Newly stable under `ip_to_canonical`
    const fn to_canonical(&self) -> IpAddr;

    // Already stable, this makes it const stable under
    // `const_ipv6_to_ipv4_mapped`
    const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr>
}
```

These stabilize a subset of the following tracking issues:

- rust-lang#27709
- rust-lang#76205

Stabilization of all methods under the `ip` gate was attempted once at rust-lang#66584 then again at rust-lang#76098. These were not successful because there are still unknowns about `is_documentation` `is_benchmarking` and similar; `to_canonical` is much more straightforward.

I have looked and could not find any known issues with `to_canonical`. These were added in 2021 in rust-lang#87708

cc implementor `@the8472`

r? libs-api
`@rustbot` label +T-libs-api +needs-fcp
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Oct 16, 2023
Stabilize `{IpAddr, Ipv6Addr}::to_canonical`

Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable (+const), as well as const stabilize `Ipv6Addr::to_ipv4_mapped`.

Newly stable API:

```rust
impl IpAddr {
    // Newly stable under `ip_to_canonical`
    const fn to_canonical(&self) -> IpAddr;
}

impl Ipv6Addr {
    // Newly stable under `ip_to_canonical`
    const fn to_canonical(&self) -> IpAddr;

    // Already stable, this makes it const stable under
    // `const_ipv6_to_ipv4_mapped`
    const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr>
}
```

These stabilize a subset of the following tracking issues:

- rust-lang#27709
- rust-lang#76205

Stabilization of all methods under the `ip` gate was attempted once at rust-lang#66584 then again at rust-lang#76098. These were not successful because there are still unknowns about `is_documentation` `is_benchmarking` and similar; `to_canonical` is much more straightforward.

I have looked and could not find any known issues with `to_canonical`. These were added in 2021 in rust-lang#87708

cc implementor ``@the8472``

r? libs-api
``@rustbot`` label +T-libs-api +needs-fcp
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Oct 16, 2023
Rollup merge of rust-lang#115955 - tgross35:ip-to-canonical, r=dtolnay

Stabilize `{IpAddr, Ipv6Addr}::to_canonical`

Make `IpAddr::to_canonical` and `IpV6Addr::to_canonical` stable (+const), as well as const stabilize `Ipv6Addr::to_ipv4_mapped`.

Newly stable API:

```rust
impl IpAddr {
    // Newly stable under `ip_to_canonical`
    const fn to_canonical(&self) -> IpAddr;
}

impl Ipv6Addr {
    // Newly stable under `ip_to_canonical`
    const fn to_canonical(&self) -> IpAddr;

    // Already stable, this makes it const stable under
    // `const_ipv6_to_ipv4_mapped`
    const fn to_ipv4_mapped(&self) -> Option<Ipv4Addr>
}
```

These stabilize a subset of the following tracking issues:

- rust-lang#27709
- rust-lang#76205

Stabilization of all methods under the `ip` gate was attempted once at rust-lang#66584 then again at rust-lang#76098. These were not successful because there are still unknowns about `is_documentation` `is_benchmarking` and similar; `to_canonical` is much more straightforward.

I have looked and could not find any known issues with `to_canonical`. These were added in 2021 in rust-lang#87708

cc implementor ``@the8472``

r? libs-api
``@rustbot`` label +T-libs-api +needs-fcp
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-fcp This change is insta-stable, so needs a completed FCP to proceed. S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet