Can you please point to the specific definitions of "temporary" and "deprecated" IP addresses in an RFC? I skimmed RFC4941 very quickly and do not see how to tell, given an IP, whether it is one of those.

@rsc To be honest, I don't know exactly either. There should be an API for it, since ifconfig is able to determine them:

en8: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=40b<RXCSUM,TXCSUM,VLAN_HWTAGGING,CHANNEL_IO>
	ether 58:ef:68:e7:31:1a
	inet6 fe80::d2:46b6:623a:b72d%en8 prefixlen 64 secured scopeid 0xa
	inet6 xxxx:1810:3e1e:8b31:149b:e16e:63de:3eeb prefixlen 64 autoconf secured
	inet6 xxxx:1810:3e1e:8b31:f43a:7ed8:5927:bec3 prefixlen 64 deprecated autoconf temporary
	inet 192.168.10.100 netmask 0xffffff00 broadcast 192.168.10.255
	inet6 xxxx:1810:3e1e:8b31:6ca3:1414:97d5:f184 prefixlen 64 deprecated autoconf temporary
	inet6 xxxx:1810:3e1e:8b31:89fb:df56:c110:7cab prefixlen 64 autoconf temporary
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect (1000baseT <full-duplex>)
	status: active

So, we need to look into the ifconfig sourcecode, I guess? Not sure how this works on Windows, but it supports temp. ipv6 addresses as well.

@jeroenjacobs79 What version of ifconfig are you running? What operating system?

To the best of my knowledge, there is no way to identify an IPv6 temporary address by examining the address bits.

RFC 8981 suggests generating temporary IIDs (interface identifiers) by simply generating the necessary number of random bits, and emphasizes, "Note: there are no special bits in an IID".

RFC 7136 states that the 'u' and 'g' bits in IPv6 IIDs have no meaning for IIDs not generated from IEEE EUI-64 addresses, and that no conclusions can be drawn from the state of these bits.

There is definitely no way to identify a deprecated address by examining its bits: A deprecated address is a temporary which has expired and will be used for existing connections, but not new ones.

Presumably, ifconfig can display the temporary and deprecated state of addresses associated with an interface because these are properties of the interface, not the address.

I think I already mentioned that in the "possible solutions" section of my post.

It's probably an interface thing, not sure how hard it is to add this information to the net.Interface type. I assume that code in the standard library is already OS-specific, as the way to get network interface information is already different for Unix-like operating systems vs Windows.

It's not clear that it fits into net.Interface either.
Interface describes an interface like "eth0", which can have many IP addresses,
and only some of them might be temporary or deprecated.
Interface has an Addrs method that returns addresses but only addresses, not extra bits.
We have some other things in x/net but I don't see any more detailed enumeration of addresses.

This may be below the bar for being worth adding special API to a standard library for.

/cc @mikioh

If we want to do this, something like this might work:

type InterfaceAddrFlags int

const (
  FlagTemporary InterfaceAddrFlags = 1 << iota
  FlagDeprecated
  FlagMulticast
)

type InterfaceAddr struct {
  Addr Addr
  Flags AddrFlags
}

func (*Interface) InterfaceAddrs() ([]InterfaceAddr, error) { ... }

There's probably other per-address information that could go in there.

What's the use-case for detecting temporary and deprecated addresses? (Aside from implementing "ifconfig", of course.) The OS should generally manage address selection for you.

My use-case for detecting IPv6 deprecated addresses is for a server which enumerates all local IP addresses via net.Interfaces() and be able to skip over deprecated addresses so they won't be used by the service.

Concretely, I have a FreeBSD system with several jails. Each jail gets an IPv6 address allocated but these are on the same network interface as the host. To ensure the host doesn't use a jail IP address, they're marked as deprecated; the jail can still use it (as it's its only address) but the kernel won't use any jail IPs for outgoing connections from the host. I have noticed, though, that some services (such as Tailscale) are using jail IPv6 addresses even though they're marked as deprecated.

@neild:

The OS should generally manage address selection for you.

You're right, for when the OS is performing address selection - e.g. a client application tells the kernel "give me a socket so I can make an outbound connection" - but sometimes a service may do this selection on its own and it may use addresses which are not appropriate, as above.

@rsc also said:

This may be below the bar for being worth adding special API to a standard library for.

This is possibly true, although the syscall package already includes many IFF_ link flags for each platform. In FreeBSD, the IPv6 flags used by ifconfig are define in /usr/include/netinet6/in6_var.h: https://github.com/freebsd/freebsd-src/blob/main/sys/netinet6/in6_var.h#L492-L502. I'm afraid I don't know how Linux/netlink implements it.

Naively (I'm not sure I understand the Go internals well enough) I wonder if these can be added to the syscall package to be used by the net package.

This does demonstrate the problem that the current net.IP type (being a []byte) makes things awkward as we can't add these per-IP flags. #46518 might help with that.

This does demonstrate the problem that the current net.IP type (being a []byte) makes things awkward as we can't add these per-IP flags. #46518 might help with that.

No, this has nothing to do with the net.IP type. A net.IP is an IP address. The temporary and deprecated statuses are not properties of an IP address, but of an (interface, IP) tuple. Perhaps we should add a type (as I suggest above) that describes an IP address plus additional interface-specific information, but net.IP is not the right place for this and #46518 doesn't change that.

Or instead of a type, a net.Interface method?

Or instead of a type, a net.Interface method?

We'd need a new net.Interface method either way, but a single method returning a type with information about an address (as here) means we'd have a simple way to add new per-address information in the future.

Retitling proposal: New methods on net.IP are not the right way to provide this information, but some mechanism to identify temporary/deprecated addresses on an interface seems reasonable.

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

It is unclear what the new API should be. Any ideas?

net.Interfaces.Addrs and net.InterfaceAddrs return []net.Addr, so if we were going to expose the temporary/deprecated bit it would have to be an optional interface on that, but probably the concrete type of the net.Addr is net.IPNet, which has no room for bits.

It is unclear what the new API should be. Any ideas?

What do you think of this earlier suggestion?
#42694 (comment)

Add a new method to net.Interface returning a []InterfaceAddr where InterfaceAddr is a struct containing an address plus additional information.

It is unclear what the new API should be. Any ideas?

What do you think of this earlier suggestion?
#42694 (comment)

Add a new method to net.Interface returning a []InterfaceAddr where InterfaceAddr is a struct containing an address plus additional information.

This makes sense to me.

@neild, the new method returning []InterfaceAddr seems fine, but maybe InterfaceAddr should be an opaque struct to make it easier to add more information (and keep it read-only)? Especially with the potential netaddr changes.

Ping @neild about interface vs struct.

I think a struct makes the most sense here.

The net.Interface type is a struct. Perhaps if we were redesigning the package it would make sense to make net.Interface an interface, but given that it is a struct I think it's best to remain consistent and use a struct for net.InterfaceAddr as well.

We can add new fields to a struct, so I don't think expansion is a concern. And we can copy any information that needs to be read-only when returning a []InterfaceAddr, since listing interfaces isn't an operation that needs to be so optimized that we worry about every allocation.

That said, I don't feel terribly strongly about this.

Retitled to match current proposal (#42694 (comment))

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group