You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The address 0:0:0:0:0:0:0:0 is called the unspecified address. It
must never be assigned to any node. It indicates the absence of an
address. One example of its use is in the Source Address field of
any IPv6 packets sent by an initializing host before it has learned
its own address.
The unspecified address must not be used as the destination address
of IPv6 packets or in IPv6 Routing headers. An IPv6 packet with a
source address of unspecified must never be forwarded by an IPv6
router.
Nowhere in that section does it say that packets with a SOURCE address of :: are not allowed on the network and should be discarded. The text actually gives us a vague example of a use case. At the same time, RFC3810 section 5.2.13 reads:
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](https://www.rfc-editor.org/rfc/rfc2461)]. For
stateless autoconfiguration, as defined in [[RFC2462](https://www.rfc-editor.org/rfc/rfc2462)], a node is
required to join several IPv6 multicast groups, in order to perform
Duplicate Address Detection (DAD). Prior to DAD, the only address
the reporting node has for the sending interface is a tentative one,
which cannot be used for communication. Thus, the unspecified
address must be used.
On the other hand, routers MUST silently discard a message that is
not sent with a valid link-local address, without taking any action
on the contents of the packet. Thus, a Report is discarded if the
router cannot identify the source address of the packet as belonging
...
#1019 actually generates these reports that RFC3810 talks about and my code there does set the source address to :: if there is no valid link-local address. I plan on eventually removing the source address check above and just leaving the destination address check. Does anyone see any issues with that proposal?
The text was updated successfully, but these errors were encountered:
IPv6 packets sent by an initializing host and MLD reports sent from hosts without link local addresses seem like valid examples of why we shouldn't drop packets with source addresses as ::.
To me, removing that source address check seems reasonable.
@tony-josi-aws Thanks for your input. I don't have immediate plans for a PR that fixes this issue. I will probably eventually get to it in #1019 but it doesn't look like this will be happen any time soon. I also don't want to rush any changes so for now, I'll just leave this issue open.
If you or someone else gets to it before me, so be it. If not, I'll get to it eventually.
vishwamartur
added a commit
to vishwamartur/FreeRTOS-Plus-TCP
that referenced
this issue
Nov 3, 2024
Related to FreeRTOS#1124
Remove the check for the source address being `::` in `prvAllowIPPacketIPv6` function.
* Update the comment to reflect that only the destination address is checked.
* Allow IPv6 packets with a source address of `::` to be processed further.
FreeRTOS-Plus-TCP/source/FreeRTOS_IPv6.c
Lines 501 to 507 in 9f4ebd5
The comment above references RFC4291 section 2.5.2 which reads:
Nowhere in that section does it say that packets with a SOURCE address of :: are not allowed on the network and should be discarded. The text actually gives us a vague example of a use case. At the same time,
RFC3810 section 5.2.13 reads:
#1019 actually generates these reports that RFC3810 talks about and my code there does set the source address to :: if there is no valid link-local address. I plan on eventually removing the source address check above and just leaving the destination address check. Does anyone see any issues with that proposal?
The text was updated successfully, but these errors were encountered: