pim6d: Don't process multicast packet with global IPv6 source address #12167
Conversation
As per rfc7761 section 4.9, PIM messages are either unicast (e.g., Registers and Register-Stop) or multicast with TTL 1 to the 'ALL-PIM-ROUTERS' group (e.g., Join/Prune, Asserts). The source address used for unicast messages is a domain-wide reachable address; the source address used for multicast messages is the link-local address of the interface on which the message is being sent. So, here I am avoiding the hello, assert, join-prune with source ip global address. As per rfc5059 section 4, The IP source address used for Bootstrap messages (regardless of whether they are being originated or forwarded) is the link-local address of the interface on which the message is being sent. So, here I am avoiding the Bootstrap with source ip global address. Signed-off-by: Sarita Patra <saritap@vmware.com>
patrasar
force-pushed
the
pimv6_packet_global
branch
from
1eaef3e to
e904703
Compare
Continuous Integration Result: FAILEDContinuous Integration Result: FAILEDTest incomplete. See below for issues. This is a comment from an automated CI system. Get source / Pull Request: SuccessfulBuilding Stage: SuccessfulBasic Tests: IncompleteTopotests Ubuntu 18.04 arm8 part 4: Incomplete(check logs for details)Addresssanitizer topotests part 1: Incomplete(check logs for details)Successful on other platforms/tests
|
Continuous Integration Result: SUCCESSFULContinuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-7999/ This is a comment from an automated CI system. |
Continuous Integration Result: SUCCESSFULCongratulations, this patch passed basic tests Tested-by: NetDEF / OpenSourceRouting.org CI System CI System Testrun URL: https://ci1.netdef.org/browse/FRR-PULLREQ2-7998/ This is a comment from an automated CI system. |
|
I think this change may not be required. The RFC section mentioned here is talking about the sending of the messages. So while sending we need to ensure this part but while receiving it we should not discard the packet. This may not work with other vendors who might be using global address. Unless RFC does not say discard it or use must keyword, we should not discard it. Let's find out more on this before proceeding with this change. |
|
For now, we are planning to allow multicast PIMV6 packet with source global ipV6 address while sending we are sending multicast packet with link-local address only. |
|
(discussion in #12008, this should be reopened I think.) |
|
This PR is stale because it has been open 180 days with no activity. Comment or remove the |
5 participants
As per rfc7761 section 4.9,
PIM messages are either unicast (e.g., Registers and Register-Stop)
or multicast with TTL 1 to the 'ALL-PIM-ROUTERS' group (e.g.,
Join/Prune, Asserts). The source address used for unicast messages
is a domain-wide reachable address; the source address used for
multicast messages is the link-local address of the interface on
which the message is being sent.
As per rfc5059 section 4,
The IP source address used for Bootstrap messages
(regardless of whether they are being originated
or forwarded) is the link-local address of the
interface on which the message is being sent.
we should process or drop multicast packet with global address. So closed the PR as of now.
PIMV6 hello packet should be accepted from LL address.
PIMV6 Join/Prune, Assert and BSM packets should be accepted from primary LL address. (Source address of the PIMV6 hello packet)
Only Register and Candidate-RP messages use Global address , so these are excluded from the check.
Signed-off-by: Sarita Patra saritap@vmware.com