Address collisions on a single interface via multiple configuration methods

Hi,

IPv6 standards define multiple methods of assigning IPv6 addresses to an interface - RFC 2462

IPv6 Stateless Address Autoconfiguration, RFC 3315 Dynamic Host Configuration Protocol for

IPv6 (DHCPv6), and manual address configuration. Having more than one of these methods used

simultaneously is not only permitted but common. Though RFC 2462 defines Duplicate Address

Detection for a link, no RFC currently defines, or at least is not clear about, a similar

function for an interface.

What happens if a system/device attempts to assign the same IPv6 global address to an interface

more than once through the various methodologies?

Given three configuration methods, seven combinations of address assignment are possible.

1. Manual No collision possible

2. SLAAC No collision possible

3. DHCPv6 No collision possible

4. Manual & SLAAC Collision possible

5. Manual & DHCPv6 Collision possible

6. SLAAC & DHCPv6 Collision possible

7. Manual & SLAAC & DHCPv6 Collision possible

The order of the combinations has been seen to be significant as well.

Some of the possible collision scenarios are less likely than others but some are not only

highly likely, they occur in implementations available today.

Issue/problem

Manual and/or DHCPv6 configuration succeeds prior to SLAAC

Depending on the specific implementation, one or more entries may be made into the IP

address table for the same address. If only one entry is made for the address then

information associated with the address, such as configuration method used, will not

include SLAAC.

For one common OS implementation the generation of a Temporary address [RFC3041] did

not occur. It appears the logic involved in generating a Temporary address is dependent

on the SLAAC address being successfully added to the address table for the interface.

Another common OS generated a Temporary address for each Router Advertisement received

with a matching prefix. It appears the logic involved in generating Temporary addresses

was not dependent on the SLAAC address being successfully added to the address table for

the interface. But as the SLAAC address is never added the IPv6 stack, due to the collision,

it continues to add Temporary addresses. The logic appears to be looking for additional

information associated with the IPv6 address which indicates SLAAC was used to generate

the address. As this entry is never made the Temporary addresses are added again and again.

Over time the OS became unusable and required rebooting.

How to reproduce

Manually configure an IPv6 address to match the SLAAC process. Or enable DHCPv6 – in this

case there appears to be a race condition. The initial DHCPv6 lease did not complete

prior to the SLAAC process. But, rebooting the OS resulted in a renewal of the DHCPv6

lease which completed prior to the SLAAC process.

Use the appropriate command to list the IP addresses assigned to the host interfaces.

Either generate Router Solicitations which will cause the router(s) to generate Router

Advertisements or wait for the periodic RAs from the routers. Then check for how many

Temporary addresses have been assigned.

Work around

Only enable one configuration method – manual, SLAAC or DHCPv6 for an interface/link

Avoid manually assigning IPv6 addresses which are identical to those generated by the

SLAAC process

Lengthen the prefix, equivalent to IPv4 scope, to ensure the DHCPv6 generated address

cannot collide with the SLAAC process

Possibly make SLAAC and DHCPv6 use different methods for generating an address – same

process results in the same address

Issue/problem

Manual and/or SLAAC configuration succeeds prior to DHCPv6

Depending on the specific implementation, one or more entries may be made into the IP

address table for the same address. If only one entry is made for the address then information

associated with the address, such as configuration method used, will not include DHCPv6.

Unused, wasted DHCPv6 leases – the DHCPv6 server shows a valid/active lease which the

client obtained – but the client in reality may or may not behave as if it did depending

on if an entry was made for the DHCPv6 method of configuration. Though the DHCPv6 specific

entry may or may not be entered in the IP address table in this scenario the DHCPv6 lease’s

value is questionable. Why have simultaneous SLAAC and DHCPv6 at all? Why have the same

address for both methods?

How to reproduce

Manually configure an IPv6 address to match the DHCPv6 process. Or enable SLAAC – in

this case there appears to be a race condition. The initial DHCPv6 lease did not complete

prior to the SLAAC process. But, rebooting the OS resulted in a renewal of the DHCPv6

lease which completed prior to the SLAAC process.

Use the appropriate command to list the IP addresses assigned to the host interfaces.

Work around

Only enable one configuration method – manual, SLAAC or DHCPv6 for an interface/link

Avoid using DHCPv6 to assign IPv6 addresses which are identical to those generated by

the SLAAC process or manual configuration.

Lengthen the prefix, equivalent to IPv4 scope, to ensure the DHCPv6 generated address

cannot collide with the SLAAC process.

Possibly make SLAAC and DHCPv6 use different methods for generating an address – same

process results in the same address

Only a few OSes and embedded systems were looked at. Most appear to have some form of issue

when address assignments result in a collision.