generated from amazon-archives/__template_MIT-0
-
Notifications
You must be signed in to change notification settings - Fork 205
Closed
Labels
bugSomething isn't workingSomething isn't working
Description
FreeRTOS-Plus-TCP/source/FreeRTOS_IPv6.c
Lines 501 to 507 in 9f4ebd5
| /* Drop if packet has unspecified IPv6 address (defined in RFC4291 - sec 2.5.2) | |
| * either in source or destination address. */ | |
| if( ( memcmp( pxDestinationIPAddress->ucBytes, FreeRTOS_in6addr_any.ucBytes, sizeof( IPv6_Address_t ) ) == 0 ) || | |
| ( memcmp( pxSourceIPAddress->ucBytes, FreeRTOS_in6addr_any.ucBytes, sizeof( IPv6_Address_t ) ) == 0 ) ) | |
| { | |
| xHasUnspecifiedAddress = pdTRUE; | |
| } |
The comment above references RFC4291 section 2.5.2 which reads:
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?
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't working