Comment 1:

While having that function would be handy, it's trivial to check if it's IPv4 or not:
func IsIPv4(ip net.IP) bool {
    return ip.To4() != nil
}

Comment 2:

Labels changed: added repo-main, release-go1.5.

Comment 4 by cserveny.tamas:

Just out of curiosity, in case I would not use such a handy function, would it grow my
output binary? Why Go does not want to have an API which is easy to use?
Go is lacking many such handy methods and the reason is always the same: it is easy to
implement for yourself.
What is the rationale behind this?

Comment 5:

A function that is not used does not increase the size of the output binary.  (A method
that is not used does increase it in some cases.)
People using a package need to be able to understand and use all the functions in the
package.  When considering whether to add a new function, we need to consider not only
whether the function is handy, but also how much extra cognitive load it imposes on
every user of the package.  Adding a bunch of trivial but handy functions is not free;
it means that every user of the package needs to know about those functions and
understand what they do.  In many cases we prefer to lean in the direction of providing
the minimum set of functions required so that you can do whatever you need.  A minimum
set of functions can be fully understood.

Marking this issue as working as intended. There still are various address family transition stuff: http://en.wikipedia.org/wiki/IPv6_transition_mechanism, and we need a type that can grab any IP address for supporting such transition features. Also we cannot provide such IsIPv4, IsIPv6 methods without application context. For example, what happens when an application treats IPv4-embedded IPv6 addresses as IPv4 addresses.

FWIW, this IETF v6ops thread, http://www.ietf.org/mail-archive/web/v6ops/current/msg22039.html, might be interesting for some people.