Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

IPV6 DAD NS packets are not received by the RE

0

0

Article ID: KB13095 KB Last Updated: 10 Jun 2009Version: 1.0
Summary:
IPV6 DAD (Duplicate Address Detection) NS (Neighbor Solicitation) packets are not received by the RE when the connected interface comes up if duplicate address is not configured on the interface
Symptoms:
  • IPV6 DAD NS packets are not received by the RE
  • Duplicate address is not configured on the interface
Solution:
Reason:

The DAD packets are not being missed. They are deliberately not being forwarded to the routing engine as there is no address on this link matching the NS target address.

In IPv6, DAD NS packets are multicast at ethernet level (the actual mac being based on the lower order bytes of the v6 address). For the RE to receive these packets a mac-filter for this multicast mac needs to be programmed. This is done by default when a v6 address is configured.

In this case since the interface does not have a duplicate address configured, the mac-filters would be absent, so the RE (rightly) does not receive these DAD NS packets.

The destination IPv6 multicast address to ethernet mac address mapping is done as below:
Ethernet dest mac = 33:33:00:00:00:00 OR'ed with the four lower order bytes of the IPv6 multicast address. So for an IPv6 multicast destination of ff02:abcd:dcba::2:1, the destination ethernet mac would be 33:33:00:00:02:01.

Neighbor Solicitations are multicast to the solicited-node multicast address of the target address. So while sending an NS for doing DAD for IPv6 address 2002::2:1, the multicast IPv6 destination address and the ethernet mac address would be ff02::1:ff:00:02:01 and 33:33:ff:00:02:01

Now there is no reason for the RE to receive an ethernet packet destined to mac 33:33:ff:00:02:01 *unless* it has an IPv6 address configured on this interface having the lower order bytes as 02:01. Since such an address is not configured the RE does not receive the NS packet (with obvious benefits).

As far as DAD operations were concerned, the above behavior is consistent with what is required. i.e. if the address were really duplicated then the RE would have this address configured on it, hence would receive packets addressed to mac 33:33:ff:00:02:01 and consequently would respond with an NA, resulting in the address being marked as DUPLICATE at the sender.

In this case, the NS packets do not reach the RE. But with a wire level packet capture you would see the packet
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search