https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.56.0 2021-08-22T13:35:11+00:00 2021-08-22T13:35:11+00:00 Frank Steffahn frank.steffahn@stu.uni-kiel.de 2021-08-22T12:46:15+00:00 urn:sha1:bf88b113eab9c36e63f8461f5849138cb60d810a 2021-08-03T10:07:48+00:00 Yuki Okushi jtitor@2k36.org 2021-08-03T10:07:48+00:00 urn:sha1:423a930c9a60ffd365f4766080d662d66f18f996 Add convenience method for handling ipv4-mapped addresses by canonicalizing them This simplifies checking common properties in an address-family-agnostic way since #86335 commits to not checking IPv4 semantics of IPv4-mapped addresses in the `Ipv6Addr` property methods. 2021-08-03T02:18:24+00:00 bors bors@rust-lang.org 2021-08-03T02:18:24+00:00 urn:sha1:810b9267f38a398c28dd213bad4acc58dce0199a Commit to not supporting IPv4-in-IPv6 addresses Stabilization of the `ip` feature has for a long time been blocked on the question of whether Rust should support handling "IPv4-in-IPv6" addresses: should the various `Ipv6Address` property methods take IPv4-mapped or IPv4-compatible addresses into account. See also the IPv4-in-IPv6 Address Support issue #85609 and #69772 which originally asked the question. # Overview In the recent PR #85655 I proposed changing `is_loopback` to take IPv4-mapped addresses into account, so `::ffff:127.0.0.1` would be recognized as a looback address. However, due to the points that came up in that PR, I alternatively propose the following: Keeping the current behaviour and commit to not assigning any special meaning for IPv4-in-IPv6 addresses, other than what the standards prescribe. This would apply to the stable method `is_loopback`, but also to currently unstable methods like `is_global` and `is_documentation` and any future methods. This is implemented in this PR as a change in documentation, specifically the following section: > Both types of addresses are not assigned any special meaning by this implementation, other than what the relevant standards prescribe. This means that an address like `::ffff:127.0.0.1`, while representing an IPv4 loopback address, is not itself an IPv6 loopback address; only `::1` is. To handle these so called "IPv4-in-IPv6" addresses, they have to first be converted to their canonical IPv4 address. # Discussion In the discussion for or against supporting IPv4-in-IPv6 addresses the question what would be least surprising for users of other languages has come up several times. At first it seemed most big other languages supported IPv4-in-IPv6 addresses (or at least considered `::ffff:127.0.0.1` a loopback address). However after further investigation it appears that supporting IPv4-in-IPv6 addresses comes down to how a language represents addresses. .Net and Go do not have a separate type for IPv4 or IPv6 addresses, and do consider `::ffff:127.0.0.1` a loopback address. Java and Python, which do have separate types, do not consider `::ffff:127.0.0.1` a loopback address. Seeing as Rust has the separate `Ipv6Addr` type, it would make sense to also not support IPv4-in-IPv6 addresses. Note that this focuses on IPv4-mapped addresses, no other language handles IPv4-compatible addresses. Another issue that was raised is how useful supporting these IPv4-in-IPv6 addresses would be in practice. Again with the example of `::ffff:127.0.0.1`, considering it a loopback address isn't too useful as to use it with most of the socket APIs it has to be converted to an IPv4 address anyway. From that perspective it would be better to instead provide better ways for doing this conversion like stabilizing `to_ipv4_mapped` or introducing a `to_canonical` method. A point in favour of not supporting IPv4-in-IPv6 addresses is that that is the behaviour Rust has always had, and that supporting it would require changing already stable functions like `is_loopback`. This also keeps the documentation of these functions simpler, as we only have to refer to the relevant definitions in the IPv6 specification. # Decision To make progress on the `ip` feature, a decision needs to be made on whether or not to support IPv4-in-IPv6 addresses. There are several options: - Keep the current implementation and commit to never supporting IPv4-in-IPv6 addresses (accept this PR). - Support IPv4-in-IPv6 addresses in some/all `IPv6Addr` methods (accept PR #85655). - Keep the current implementation and but not commit to anything yet (reject both this PR and PR #85655), this entire issue will however come up again in the stabilization of several methods under the `ip` feature. There are more options, like supporting IPv4-in-IPv6 addresses in `IpAddr` methods instead, but to my knowledge those haven't been seriously argued for by anyone. There is currently an FCP ongoing on PR #85655. I would ask the libs team for an alternative FCP on this PR as well, which if completed means the rejection of PR #85655, and the decision to commit to not supporting IPv4-in-IPv6 addresses. If anyone feels there is not enough evidence yet to make the decision for or against supporting IPv4-in-IPv6 addresses, let me know and I'll do whatever I can to resolve it. 2021-08-02T18:28:31+00:00 The8472 git@infinite-source.de 2021-08-02T18:28:31+00:00 urn:sha1:a5cdff3bd42e82f58de45dd49d468a6d4c54b54b This simplifies checking common properties in an address-family-agnostic way since since #86335 commits to not checking IPv4 semantics of IPv4-mapped addresses in the `Ipv6Addr` property methods. 2021-08-02T02:03:22+00:00 Yuki Okushi jtitor@2k36.org 2021-08-02T02:03:22+00:00 urn:sha1:f386ae3533798b75122bbbf659d1ed10fc3aeff4 Add documentation for `Ipv6MulticastScope` Adds basic documentation to the unstable `Ipv6MulticastScope`, as well as marking it `#[non_exhaustive]` because future IETF RFCs may introduce additional scopes. The documentation mentions this in a section "Stability Guarantees": > /// Not all possible values for a multicast scope have been assigned. /// Future RFCs may introduce new scopes, which will be added as variants to this enum; /// because of this the enum is marked as `#[non_exhaustive]`. 2021-08-02T02:03:19+00:00 Yuki Okushi jtitor@2k36.org 2021-08-02T02:03:19+00:00 urn:sha1:a03d6da3ef7852cbcfcf98b7639b529b96587ca3 Remove `Ipv4Addr::is_ietf_protocol_assignment` This PR removes the unstable method `Ipv4Addr::is_ietf_protocol_assignment`, as I suggested in https://github.com/rust-lang/rust/issues/85612#issuecomment-847863404. The method was added in #60145, as far as I can tell primarily for the implementation of `Ipv4Addr::is_global` (addresses reserved for IETF protocol assignment are not globally reachable unless otherwise specified). The method was added in 2019, but I haven't been able to find any open-source code using this method so far. I'm also having a hard time coming up with a usecase for specifically this method; knowing that an address is reserved for future protocols doesn't allow you to do much with it, especially since now some of those addresses are indeed assigned to a protocol and have their own behaviour (and might even be defined to be globally reachable, so if that is what you care about it is always more accurate to call `!is_global()`, instead of `is_ietf_protocol_assignment()`). Because of these reasons, I propose removing the method (or alternatively make it a private helper for `is_global`) and also not introduce `Ipv6Addr::is_ietf_protocol_assignment` and `IpAddr::is_ietf_protocol_assignment` in the future. 2021-07-27T20:03:09+00:00 Jacob Pratt jacob@jhpratt.dev 2021-06-03T06:11:14+00:00 urn:sha1:36f02f352392f216d778808818d0e4ed56714f3c 2021-07-07T12:41:06+00:00 Christiaan Dirkx christiaan@dirkx.email 2021-07-07T12:41:06+00:00 urn:sha1:a674ae6f7640c6e04a983022c778b0827798ac3d 2021-06-23T20:26:46+00:00 Smitty me@smitop.com 2021-06-23T20:26:46+00:00 urn:sha1:bdfcb88e8b6203ccb46a2fb6649979b773efc8ac 2021-06-19T13:03:02+00:00 Christiaan Dirkx christiaan@dirkx.email 2021-06-18T16:02:56+00:00 urn:sha1:a26237e634be7f94dbd40cc1204514f2b4c380d2