I think that the method is unnecessary for ipv6 package. Unlike system calls and primitives for IPv4 facilities, tweaking IPv6 headers on outgoing packets from userspace must use per-packet basis ancillary data and a very few sticky socket options, and that's the reason why ipv6.RawConn doesn't exist; see RFC 3542.

FWIW, I added the ipv6.Header type and ipv6.ParseHeader for parsing IPv6 header in ICMP error message bodies.

I'd like to second the addition of marshaling an ipv6.Header in x/net/ipv6.

When working with IPv6 headers directly (in particular, when reading/writing packets from a TUN/TAP device or from packet capture interfaces) it is possible to parse the read []byte into a usable ipv6.Header struct, but it is not possible to do the reverse.

To generate a response packet to write back to TUN/TAP, we would expect to modify or create an ipv6.Header and then marshal it back into []byte so that it can be written to the adapter. Currently this is not possible, which leads to unnecessary (and possibly unsafe) boilerplate code.

Fro TUN/TAP case, https://godoc.org/github.com/google/gopacket looks promising.

It does look promising, but it also looks like a very heavy solution to a very simple problem. The IPv4 package has marshalling, it makes sense that the IPv6 package should too.

@neilalexander,

The purpose of IPv4 header marshaling and unmarshaling in the ipv4 package is just to avoid a few pitfalls for non-experienced users. For some historical reason, classical IPv4 host stack implementations (mostly on BSD variants) may tweak host reception and transmission IPv4 packets. Therefore the existing API surface in the ipv4, ipv6 and icmp packages recalculates data from/to the kernel and provides native-endian access for the exposed types as the host-stack friendly API surface.

I think that your use case, a bundle of light-weight wire-format friendly marshalers and unmarshalers, makes sense but it's better to put such functionality in another package, not to mix host-stack friendly API and wire-format friendly API.

Closing this out as I no longer have a need for this.