IPv6

[awelkie]

Is IPv6 something this library will support, may support, or will never support?

[whitequark]

IPv6 will be definitely supported, and I expect this to happen soon.

[whitequark]

cc @edef1c

[dlrobertson]

I am definitely interested in working on this post #50

[sbourdeauducq]

Does anyone want to contribute funds to this?

[whitequark]

I know @edef1c had some code they wanted to contribute to smoltcp. That would actually go a long way towards IPv6 support.

[edef1c]

Yeah, I need to find some spare time and probably go over some more details with you, but I've got a packet parser and stuff going, I don't think there's all that much work involved in integrating this — I'm mostly worried about testing it sufficiently exhaustively

[dlrobertson]

@edef1c Do you have a fork and branch you're working on?

Two days ago I started working on an implementation of ipv6 for the wire module, just for kicks. My current work is here. If you're farther along and have a fork, I'd be more than happy to ditch my current efforts and help out with your work. Or if it helps, feel free to steal some of the tests I wrote.

[edef1c]

@dlrobertson looks like you're on par with me, I'm not sure I'll have time before next week or so, have fun I guess?

[dlrobertson]

@edef1c I'll be largely unavailable for two weeks as well. While I am pumped to help with this issue, I'd hate to push you out of contributing to this.

Perhaps a upstream/ipv6 feature branch would be helpful so that multiple people could work on this? I have a feeling its going to take multiple contributors quite some time to fully implement ipv6. If we plan to incrementally submit PRs to master I guess there is no need for a separate ipv6 feature branch as long as we feature the ipv6 specific stuff.

@whitequark thoughts on a separate ipv6 "feature branch" until the work is somewhat complete vs feature gating?

[whitequark]

No go on "feature branch". Just submit it in chunks however small you want, down to and including single-enum PRs (we use rebase-and-merge so this doesn't add any junk to history).

[dlrobertson]

Sounds good. Shouldn't be too hard to feature gate it

[whitequark]

What do you mean by "feature gate"? We're in the 0.x.y version series, I do not provide compatibility guarantees (though I rarely break code), and I'll only accept PRs that I consider of reasonable quality, so there's no harm in exporting those APIs right away.

[dlrobertson]

At least in the initial PR is only adding the packed parsers etc. So I just put everything behind #[cfg(feature = "ipv6")] and I didn't add it to the default. See #72 for details.

[dlrobertson]

I set #196 as the PR that "Fixes" this issue due to the basic server example working after the PRs changes. I'm okay with changing that if the consensus is otherwise.

[dlrobertson]

Basic on-link IPv6 support is added in #196. Any subsequent bugs or feature requrests for IPv6 should be filed as separate issues.