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

proposal: net: add functions for building an IPv6 Solicited-Node Address #25257

richard-jp-leguen opened this issue May 4, 2018 · 5 comments


Copy link

@richard-jp-leguen richard-jp-leguen commented May 4, 2018

The net library has variables for well-known IPv6 addresses like the All Routers Addresses and All Nodes Addresses multicast addresses:

However it doesn't offer any convenience functions for converting an IPv6 address into a Solicited-Node Address multicast address.

Solicited-Node multicast address are computed as a function of a
node's unicast and anycast addresses. A Solicited-Node multicast
address is formed by taking the low-order 24 bits of an address
(unicast or anycast) and appending those bits to the prefix
FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the

Equally, when sending an ICMPv6 Neighbor Discovery request, the MAC address is also built by manipulating IPv6 address:

An IPv6 packet with a multicast destination address DST, consisting
of the sixteen octets DST[1] through DST[16], is transmitted to the
Ethernet multicast address whose first two octets are the value 3333
hexadecimal and whose last four octets are the last four octets of

It would be nice if there was a a function which accepted a argument of type net.IP, checked that the argument was IPv6, and returned the corresponding Ethernet multicast address as a net.HardwareAddr.

@ALTree ALTree changed the title Functions for building an IPv6 `Solicited-Node Address` function proposal: net: add functions for building an IPv6 Solicited-Node Address May 4, 2018
@gopherbot gopherbot added this to the Proposal milestone May 4, 2018
@gopherbot gopherbot added the Proposal label May 4, 2018
Copy link

@ianlancetaylor ianlancetaylor commented May 4, 2018

The place for such functions is likely the repo.

CC @mikioh

Copy link

@mdlayher mdlayher commented May 5, 2018

For what it's worth, I considered filing an issue for this when building my IPv6 NDP package, but wasn't sure it was a common enough need even for x/net.

Copy link

@mikioh mikioh commented May 7, 2018

I think that the best place for those functions should be an external package, for example, the IPv6 neighbor discovery package mentioned above.

FWIW, I guess that you perhaps might be amused longstanding discussions on IPv6 addressing architecture such as "64-bit IID vs. addressing on non-/64 networks" at IETF, RFC 7136, RFC 7217 and RFC 8064. I personally hope that the net package of the standard library and a few packages in x/net repository keep staying away from such amusement.

Copy link

@rsc rsc commented May 7, 2018

Agree that this does not belong in standard net.
@mikioh seems to be saying it doesn't even belong in x/net,
that possibly there's enough question about the general utility
even for that lower bar.

What kind of program would need this functionality?
How often does that happen?

Copy link

@rsc rsc commented Jun 5, 2018

Sounds like this is OK to leave to external packages.

@rsc rsc closed this Jun 5, 2018
@golang golang locked and limited conversation to collaborators Jun 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.