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

RFC: Add std::net::MacAddr48 to std::net #2082

Closed
wants to merge 6 commits into from
Closed
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
72 changes: 72 additions & 0 deletions 0000-net-mac-address.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,72 @@
- Feature Name: `net_address_mac`
- Start Date: 2017-07-26
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)

# Summary
[summary]: #summary

Add a media access control address (MAC) address datatype, `std::net::MacAddr48` to `std::net`.

# Motivation
[motivation]: #motivation

Currently there is no standard way to communicate physical (or ethernet) addresses when doing network related development in rust, even though `std::net::IpAddrV4` and `std::net::IpAddrV6` exist. The MAC address is, however, a regularly occurring data-structure when doing any type of network related development.

There is also a proliferation of implementations which are not compatible with each other, forcing developers to manually implement the data type again and again, reducing the opportunity for code re-use and convenience. `nom`[1], `libpnet`[2] and `diesel`[3] being a couple of examples.
Copy link
Member

Choose a reason for hiding this comment

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

This exact argument applies equally to dozens if not hundreds of types. If I took this this RFC and find/replaced MacAddr48 with Uuid or Path or Polygon or Rgb or Rgba or Netmask or Quaternion or Matrix or Vector or TraceId and what would change? Libstd should not be the dumping ground for every possible type that could exist.

The IpAddr types are defined in the standard library because they're used in networking APIs. MacAddr48 on the other hand would be an orphaned type which interacts with nothing.

Copy link
Member

@eddyb eddyb Jul 28, 2017

Choose a reason for hiding this comment

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

The best (IMO) language design solution here is to support some subset of "cubical type-checking" (an implementation of Homotopy Type Theory), and allow users of multiple libraries to specify equivalences (bidirectional conversion functions, more or less) between the libraries' definitions of the same type, to allow them to be used interchangeably.

Although that might as well be a pipe dream, or there'd need to be some compromise and the compiler wouldn't check conversion preserves information, but trust the user instead.

Copy link
Author

Choose a reason for hiding this comment

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

@sfackler fair enough, is this a criteria for all types in the std lib? Perhaps there is an argument for the inclusion of that list of types you mentioned? As said in the RFC, I don't believe in exploding the std lib and creating a massive maintenance burden (although a bunch of those are kind of settled and should not need much maintenance/tweaking going forward), but I can also see an argument for more types in the std lib as a part of the whole rust usability drive this year.
To me, extended, standardized, type support could be seen as an enabler for:
Standardized, solid, types helps with integration into other languages (rust-lang/rust-roadmap-2017#14), definitely helps with writing robust (and scalable) servers (
rust-lang/rust-roadmap-2017#9) and pushes the quality of crates up through interoperability (rust-lang/rust-roadmap-2017#10).
There is no real reason to believe that each crate using the types you mentioned (and MacAddr48) would go to the trouble of implementing all the idiomatic conversion functions and Traits that can be expected/found in the current std lib.
I understand your argument, but perhaps a bit more consideration around the topic in general would be a good idea?

Copy link
Author

Choose a reason for hiding this comment

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

Based on this news: https://github.com/carllerche/http I would like to withdraw this RFC, perhaps the answer here is to rather get a quality network types library together and then rally around it's by lobbying authors of other crates. Thanks for considering it though!
Can I just go ahead and close it?

Copy link
Author

Choose a reason for hiding this comment

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

Having polled a couple of developers there is one concern about 'non-complex type' crates as an alternative. the http crate has immense value, and is packed full of consts and enums that would take any developer a lot of time to bootstrap.
Would people opt-in to 'bloating' their Cargo.toml files (and imports) just to have a re-usable simple type? MacAddr48 is just a [u8; 6] - as a coder it might just be simpler to do the latter than go to the trouble of finding a crate. To me this is an argument for inclusion in some sort of larger, standardized library, even if it isn't std itself?

Copy link
Member

Choose a reason for hiding this comment

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

@stephanbuys I'd want to use the common type if one of my dependencies did, or if I was aware of the common crate and it had useful functionality (e.g. helpful instances for comparison and pretty-printing).


[1] https://github.com/moosingin3space/pktparse-rs/blob/master/src/ethernet.rs

[2] https://github.com/libpnet/libpnet/blob/master/src/util.rs

[3] http://docs.diesel.rs/diesel/pg/types/sql_types/struct.MacAddr.html


# Detailed design
[design]: #detailed-design

It is proposed that the existing `crate` `eui48` be used (http://crate.io/eui48) as a basis for this RFC, thus the code below is copied directly from that implementation.
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Author

Choose a reason for hiding this comment

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

Fixed, thanks for pointing it out.


The following struct would be added to `std::net`:


```

/// A 48-bit (6 byte) buffer containing the EUI address
/// See: https://en.wikipedia.org/wiki/MAC_address
pub const EUI48LEN: usize = 6;
pub type Eui48 = [u8; EUI48LEN];

/// A MAC address (EUI-48)
#[derive(Copy, Clone)]
pub struct MacAddr48 {
/// The 48-bit number stored in 6 bytes
eui: Eui48,
}

```

It is proposed that most of the functions and `impl` from the `eui48` crate be included in `std::net::MacAddr48`, although there are open questions as to the need to support the `eui48` and `eui64` datatypes as those are trademarked by the IEEE, and MAC addresses are most commonly encountered in the ecosystem as well as the functions depending on Serde.

# How We Teach This
[how-we-teach-this]: #how-we-teach-this

Networking related code is not directly addressed in any of the official rust books, that said, an effort could be made to contact some of the larger crates to encourage them to adopt the `std::net` structs.

It might be a good idea to investigate adding some examples to the rust cookbook, at https://brson.github.io/rust-cookbook/net.html#ex-random-port-tcp, altough the authors there would need to approve the topics and at this point no items in the standard library expose or use MAC addresses (based on a brief search), the target audience for this extension would primarily be other crate authors.

# Drawbacks
[drawbacks]: #drawbacks

Extending the standard library is something that should be very carefully considered before undertaking any changes, it increases the maintenance load on the relevant teams.

# Alternatives
[alternatives]: #alternatives

Promote or "bless" a standard crate for MAC addresses and spread the word to the large crates (such as diesel, libpnet, etc) and attempt to convince them to use it.

# Unresolved questions
[unresolved]: #unresolved-questions

Should we stop at MAC addresses? There are other networking datatypes to be included?
Should we add the `Serde` dependent serialization and deserialization `fn`'s?