Hi all,
I noticed a behavior in IPv6 Neighbor Discovery processing that
I wanted to ask about.
In ip6_nd.c, the NS/NA receive path appears to learn a neighbor entry from a
received Neighbor Solicitation before checking whether the NS target address
belongs to the receiving interface, is covered by proxy ND, or is otherwise a
valid local/tentative target.
As a result, if VPP receives an NS whose target address is not one of its own
addresses and not a proxy-ND target, but the packet has a valid non-unspecified
source address and a Source Link-Layer Address option, VPP may still learn the
source IPv6-to-MAC mapping before ultimately dropping/not replying to the NS.
My reading of RFC 4861 section 7.2.3 is that a valid NS which does not meet one
of these requirements must be silently discarded first:
* the Target Address is a valid unicast/anycast address assigned to the
receiving interface;
* the Target Address is a unicast/anycast address for which the node is
offering proxy service;
* the Target Address is a tentative address on which DAD is being performed.
Only after that does the RFC say the receiver should create or update the
Neighbor Cache entry from the Source Address and SLLAO.
So this VPP behavior looks like it may be learning from an NS that RFC 4861
would otherwise require to be silently discarded.
Is this ordering intentional in VPP, for example as a dataplane optimization or
to support some operational scenario, or should the neighbor learning be moved
after the target-address validation for NS packets?
Thanks,
Kevin
________________________________
This e-mail message may contain confidential or proprietary information of
Mavenir Systems, Inc. or its affiliates and is intended solely for the use of
the intended recipient(s). If you are not the intended recipient of this
message, you are hereby notified that any review, use or distribution of this
information is absolutely prohibited and we request that you delete all copies
in your control and contact us by e-mailing to [email protected]. This
message contains the views of its author and may not necessarily reflect the
views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor
email messages, but make no representation that such messages are authorized,
secure, uncompromised, or free from computer viruses, malware, or other
defects. Thank You
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#27205): https://lists.fd.io/g/vpp-dev/message/27205
Mute This Topic: https://lists.fd.io/mt/121404913/21656
Group Owner: [email protected]
Unsubscribe: https://lists.fd.io/g/vpp-dev/leave/14379924/21656/631435203/xyzzy
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
