Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/net/ipv6: missing Header.Marshal method #18633

Closed
mdlayher opened this issue Jan 12, 2017 · 6 comments
Closed

x/net/ipv6: missing Header.Marshal method #18633

mdlayher opened this issue Jan 12, 2017 · 6 comments

Comments

@mdlayher
Copy link
Member

In x/net/ipv4, Header.Marshal can be used to marshal the IPv4 header into binary form.

There is no such method in x/net/ipv6.

I'd be happy to implement it, unless there is a specific reason it wasn't implemented in the first place.

/cc @mikioh

@bradfitz bradfitz added this to the Unreleased milestone Jan 12, 2017
@mikioh
Copy link
Contributor

mikioh commented Jan 13, 2017

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.

@neilalexander
Copy link
Contributor

neilalexander commented Feb 13, 2018

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.

@mikioh
Copy link
Contributor

mikioh commented Feb 13, 2018

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

@neilalexander
Copy link
Contributor

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.

@mikioh
Copy link
Contributor

mikioh commented Feb 14, 2018

@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.

@mdlayher
Copy link
Member Author

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

@golang golang locked and limited conversation to collaborators Mar 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants