This is a proposal for Go 1.7.

CL https://golang.org/cl/19946 mentions this issue.

Hi Mikio,

Can you explain to me why this makes sense? The type is called IPNet and it used to be an IP address plus a network mask. Now it is really an IPNetZone but still called IPNet. This is confusing to me, and adding the field is going to break a TON of composite literals that assumed the thing called IPNet would only ever contain two fields: an IP and a net. That code shouldn't do that, but it will break nonetheless.

Furthermore, the main reason IPNet exists is to provide the Contains method, and of course the Zone has no bearing there. That's also confusing.

It looks like IPNet is being extended only because it was already in use in certain data structures. Maybe that use is the real mistake and this change should be reverted. I know we've already reverted this change once, in 2013 (#4501), but I still don't understand the rationale. Can you help me understand?

Thanks.

Hi Russ,

My understanding of IPNet is that it represents an IP network. That was my intention of adding the type to net package and is the reason of existence.

The type can be used for conveying the information of IP network. For example, APIs surveying network interfaces in net package use the type to represent on-link address prefixes that designate connected networks and addresses on the node. The information is necessary for applications discovering and making some association between on-link neighbors.

Applications using only global-scope addresses never suffer with the lack of Zone, but applications using link-local addresses may suffer. What if the returned list of IPNet from InterfaceAddrs contains a few address prefixes which are the same, such as "fe80::1/64". The applications need some information to distinguish IP links.

Now it is really an IPNetZone but still called IPNet.

Interesting, I've never thought that it would be confusing. My understanding is that IP of IPNet would be the entire address space, a functional address, or address blocks. Mask of IPNet helps to cut certain address blocks, and Zone of IPNet helps to identify the required link. IPNet just represents a network at IP layer not only for network-to-network communication but node-to-network (or node-to-node) communication.

@pmarks-net, do you have any insights into this? I have basically no experience with link-scoped addresses in IPv6. Thanks.

I would bet that the vast majority of IPNet users just want to represent a CIDR prefix (e.g. 2607:f8b0::/32). Adding a zone gives you something conceptually different, because an interface name is only relevant to the machine that created it.

Whatever change is made, a primary goal should be to be as unobtrusive as possible to the "normal" users; if people need to start adding nils to their IP geolocation and spam filtering libraries, then it's a lost cause.

My inclination would be to make IPNet and IPNetZone distinct types, so that the type system can highlight the cases where a zone is actually relevant.

I'm fine to have a new type and make InterfaceAddrs and Addrs method of Interface return the new type instead of IPNet. I'd like to prefer IPPrefix or IPAddrPrefix than IPNetZone, because I have no good answer to "why not TCPAddrZone instead of TCPAddr?"

Of course I meant make InterfacePrefixes and Prefixes method of Interface return the new type not to break existing applications.

CL https://golang.org/cl/22794 mentions this issue.

I changed my mind. We can use the combination of Interfaces function and Addrs method of Interface instead of InterfaceAddrs function. Also it returns more useful information than InterfaceAddrs. So just updating the documentation on InterfaceAddrs is enough.

CL https://golang.org/cl/31371 mentions this issue.