cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
295
Views
5
Helpful
4
Replies

ipv6 nd prefix "no-autoconfig" vs "no-advertise"

DomTurchi
Level 1
Level 1

Hello All,

I'm a bit confused on the use cases for this and whether they can be used interchangeably or not. My current configuration is legacy to me for Stateful IPv6 DHCP and includes the following configuration:

ipv6 nd prefix default no-autoconfig
ipv6 nd managed-config-flag
ipv6 nd other-config-flag

The white papers I'm reading are recommending a no-advertise flag instead of the no-autoconfig flag, and I'm confused on what is best practice. Would one or the other prevent RA gateway advertisements to the end user or are they effectively the same?

Also, I'm assuming both would disable SLAAC. Is it possible to have a configuration allow both SLAAC or DHCP based on need?

1 Accepted Solution

Accepted Solutions

Harold Ritter
Spotlight
Spotlight

Hi @DomTurchi ,

Yes, both "no-advertise" and "no-autoconfig" in effect disable the SLAAC functionality.

The first knob causes the RA not to include the prefix(es) at all.

The second one includes the prefix in the RA, but clears the A bit, meaning that nodes receiving the prefix(es) via the RA should not use it to auto configure themselves (as per RFC4861).

Bear in mind that since "no-advertise" knob does not advertise the prefix in the RA, the receiving node will not be able to install the prefix (/64) in its local IPv6 table. Therefore, if a node needs to send a packet to another node on that same link, it forwards the packet to the router, which then forwards it to the other node. In other words, node to node communication does not happen directly, even though the two nodes are technically on the same link.

Regards,

 

View solution in original post

4 Replies 4

Harold Ritter
Spotlight
Spotlight

Hi @DomTurchi ,

Yes, both "no-advertise" and "no-autoconfig" in effect disable the SLAAC functionality.

The first knob causes the RA not to include the prefix(es) at all.

The second one includes the prefix in the RA, but clears the A bit, meaning that nodes receiving the prefix(es) via the RA should not use it to auto configure themselves (as per RFC4861).

Bear in mind that since "no-advertise" knob does not advertise the prefix in the RA, the receiving node will not be able to install the prefix (/64) in its local IPv6 table. Therefore, if a node needs to send a packet to another node on that same link, it forwards the packet to the router, which then forwards it to the other node. In other words, node to node communication does not happen directly, even though the two nodes are technically on the same link.

Regards,

 

Ah interesting. So it sounds like with both tags the receiving node would learn its gateway through the RA, but "no-autoconfig" would allow direct node to node communication while "no-advertise" does not. 

Would removing either tag and leaving only "managed-config-flag" and "other-config-flag" effectively allow both SLAAC and DHCP?

Hi @DomTurchi ,

Would removing either tag and leaving only "managed-config-flag" and "other-config-flag" effectively allow both SLAAC and        > DHCP?

That is correct. The nodes would get both (assuming they are configured to get a DHCP address). The DHCPv6 learnt address would be a /128 (host address) and the SLAAC learnt address would be from a /64 prefix.

Regards,

Awesome, thanks a bunch!

Review Cisco Networking for a $25 gift card