Comment 1:

Try to demistify SOCK_RAW with AF_INET/AF_INET6 world...
[SOCK_RAW with AF_INET]
at syscall:
- both Send,  SendTo prepend an IPv4 header automatically by default.
  sockopt IP_HDRINCL disables IPv4 header prepending.
- both Recv, Recvfrom return an incoming packet with an IPv4 header and options intact.
at net:
- both Write,  WriteTo prepend an IPv4 header automatically by default.
  sockopt IP_HDRINCL disables IPv4 header prepending.
- Read returns an incoming packet with an IPv4 header and options intact.
- ReadFrom returns an incoming packet without an IPv4 header and options.
[SOCK_RAW with AF_INET6]
at syscall:
- both Send,  SendTo prepend an IPv6 header automatically.
- both Recv, Recvfrom return an incoming packet without an IPv6 header and extension
headers.
at net:
- both Write,  WriteTo prepend an IPv6 header automatically.
- both Read, RedFrom return an incoming packet without an IPv6 header and extension
headers.

Comment 2:

Looks like removing an IPv4 header in net.ReadFrom might be pointless for 
the applications that use SOCK_RAW with AF_INET.
For example, an app such as OSPF requires:
- IP multicast packet exchange for neighboring,
- IP unicast packet exchange btw DR/BDR and DROTHER nodes.
That means that the app needs to identify a pair of source and destination 
IPv4 addresses for OSPF message processing but net.ReadFrom bothers us 
by dropping IPv4 header.
In the case of OSPF for IPv6 we usually use recvmsg/sendmsg with ancillary 
data instead.

Comment 3:

Labels changed: added go1.1maybe.

Comment 4:

Status changed to Started.

Comment 5:

[The time for maybe has passed.]

Labels changed: removed go1.1maybe.

Comment 6:

Since we didn't accept the change in https://golang.org/cl/6445105/ as being
too risky (or an API change), what about an alternate fix:
Can there be an API addition to let users opt-in to the correct ("new") behavior
per-IPConn? Some new method on IPConn that returns a new IPConn with a "wantGoodBehavior
bool" set true?
Gross, but I don't see how else to fix this safely, without breaking old users.
Or are old users completely busted anyway?  That's what nobody understood before, and
why this didn't go into 1.1.

Comment 7:

> Or are old users completely busted anyway?
How did you read my mind? ;) Yup, will take Plan B Russ suggested; mark something like
"we would not recommend to use ReadFrom, ReadFromIP of IPConn because of this bug,
breaking traditional, portable old BSD school API behavior, ouch. Please use ReadMsgIP
instead until Go 2." at BUG section.

Comment 8:

Labels changed: added go1.2maybe.

Comment 9:

Labels changed: added feature.

Comment 10:

Mikio, are you planning to make the documentation change?

Comment 11:

Yes, just sent: https://golang.org/cl/13263043/

Comment 12:

This issue was closed by revision a8b4a1e.

Status changed to Fixed.