(Incomplete) Implement join_multicast_group() for IPv6
#602
Conversation
| @@ -2417,7 +2510,6 @@ impl<'a> InterfaceInner<'a> { | |||
|
|
|||
| fn dispatch_ip<Tx: TxToken>(&mut self, tx_token: Tx, packet: IpPacket) -> Result<()> { | |||
| let ip_repr = packet.ip_repr(); | |||
| assert!(!ip_repr.src_addr().is_unspecified()); | |||
There was a problem hiding this comment.
Removing this assertion also feels a little dicey, but as noted in the comment when crafting the mldv2 report packet, RFC 3810 instructs that the source address can be set to the unspecified address:
An MLDv2 Report MUST be sent with a valid IPv6 link-local source
address, or the unspecified address (::), if the sending interface
has not acquired a valid link-local address yet. Sending reports
with the unspecified address is allowed to support the use of IP
multicast in the Neighbor Discovery Protocol [RFC2461].
There was a problem hiding this comment.
It seems #600 suggests to remove this assert as well?
|
re the difficulties: Yes, From a quick look, the PR looks OK. Could you rebase+squash? |
|
friendly ping @jgallagher :) |
This patch rebases @jgallagher's to the tip of the main branch, adding support for IPv6 multicast groups. As in the original PR, it is only possible to join groups by sending an initial MLDv2 Report packet. It is not yet possible to resend the change report, leave groups, respond to queries, etc.
This patch rebases @jgallagher's to the tip of the main branch, adding support for IPv6 multicast groups. As in the original PR, it is only possible to join groups by sending an initial MLDv2 Report packet. It is not yet possible to resend the change report, leave groups, respond to queries, etc.
This patch rebases @jgallagher's to the tip of the main branch, adding support for IPv6 multicast groups. As in the original PR, it is only possible to join groups by sending an initial MLDv2 Report packet. It is not yet possible to resend the change report, leave groups, respond to queries, etc.
This patch rebases @jgallagher's to the tip of the main branch, adding support for IPv6 multicast groups. As in the original PR, it is only possible to join groups by sending an initial MLDv2 Report packet. It is not yet possible to resend the change report, leave groups, respond to queries, etc.
|
This is implemented and merged in #914, which is based on this PR. |
This is a preliminary and incomplete start to adding support for IPv6 multicast groups. This PR only adds joining groups via sending an initial MLDv2 report packet; it doesn't support resending the change report, leaving groups, responding to queries, etc. I wanted to open this PR first both to keep the review burden lighter and to get any feedback on the implementation that could affect implementing the remaining features.
On that last point, there are a few things in this PR that I'm not thrilled with and would be happy for any suggestions. I think all of them derive from difficulty crafting a fully-formed
IpPacketto pass todispatch_ip(). For the MLDv2 report, the specific difficulties and paths I took to deal with them were:IpPacket(IpPacket::HopByHopIcmpv6), but that doesn't feel quite right.Ipv6HopByHopRepr'soptionsfield requires a borrowed slice. I couldn't see an easy way to get from a pair ofIpv6OptionReprs to a borrowed slice, so I punted on this and definedIpv6HopByHopRepr::MLDV2_ROUTER_ALERTas a constant.MldRepr::Reportrequires a borrowed slice for its data (the address records); I couldn't see an easy way to get from anMldAddressRecordReprto that borrowed data, so I added anMldRepr::ReportRecordReprscase which holds a slice ofMldAddressRecordRepr. This definitely seems wrong. It also might be still have similar problems as the borrowed byte slice when we need to craft packets with multiple address records in them.In addition to the unit tests present, I've tested this locally on a microcontroller running smoltcp, and I've confirmed I can communicate with it via a multicast address through the switch it's connected to, so I'm reasonably confident that what's here is correct (albeit incomplete and a little hacky, as noted above).