Router Advertisements

Router Advertisement (RA) messages begin immediately after the subscriber host is instantiated and unsolicited messages are sent in the interval defined in the configuration. Apart from unsolicited RAs, the client may also send a router solicitation (RS) to explicitly request the information. RAs are throttled so that they are not sent more than once every three seconds.

The Router Advertisement Policy feature overrides the group interface RA configuration for hosts on a specific MAC on a specified SAP. The policy is applied directly to the sending instance where it sends periodic RAs. The policy can be applied at authentication or by CoA during the subscriber session. The RA policy can be used in the following ways.

• When applied to an IPoE session or a PPPoE session, the RA policy is applied to all IPv6 hosts within the session.

• When applied to a subscriber (regardless of whether it is session-based), the RA policy is applied to all IPv6 hosts within the subscriber.

• When applied to a host within a subscriber, the RA policy is applied only to the IPv6 hosts for the particular MAC (for IPoE session) or the particular MAC and PPP session (for PPPoE session).

The prefix option inside the RA policy allows independent prefix options for subscribers that use bridge hosts. The bridge hosts can consist of both DHCPv6 and SLAAC, and are represented as stateful and stateless within the policy respectively. Within the policy, the autoconfig flag is not configurable and is disabled by default for the DHCPv6 address and enabled by default for SLAAC. For SLAAC hosts, if the autoconfig flag is enabled inside the RA policy along with the SLAAC prefix, the autoconfig flag for the DHCPv6 address or prefix is not enabled as a result. The timers for either SLAAC and DHCPv6 prefixes can also be configured independently.

The router advertisement policy has a separate configuration for stateless and stateful operations. The general recommendation is to configure the valid and preferred lifetimes for longer than the minimum RA interval to ensure the subscriber has a valid address to use between each RA interval. If this general rule is not followed, the subscriber can deprecate the SLAAC prefix between each RA interval and experience service interruptions. As the minimum RA interval is approximately 15 minutes, the valid and preferred lifetime values should be at least 15 minutes. Shorter valid and preferred lifetime values can impact the system’s scalability. The stateful RA has a static option and a dynamic option when configuring the valid and preferred lifetime values. If the static option is used, the valid and preferred lifetime values should be greater than the RA interval. For the dynamic option, the auto-lifetimes feature derives the valid and preferred lifetime values from the DHCPv6 lease. Therefore, the RA and DHCPv6 have the same valid and preferred lifetime values.

SLAAC hosts are assigned prefixes, where the full Global Unicast Address (GUA) is not known. Regardless of the force-mcast configuration, the destination IP address for an RA to an SLAAC host is always be a multicast IP address, with one exception. If the feature allow-multiple-wan-address is enabled and the same host (same MAC on the same SAP and same device) has a DHCPv6 NA address, the NA address is used for the unicast RA. The MAC address can either be a multicast or unicast address, depending on the configuration of force-mcast.

Table: RA policy behavior describes the behavior of the system when the RA policy VSA is included in authentication, CoA, and re-authentication. The RA policy that is sent from RADIUS may not yet be provisioned in CLI, and therefore may not exist in the system.