Subject: Address collisions on a single interface via multiple configuration methods

From: "Burden, Ken" <[email-masked]>
Date: Wed, 26 Sep 2007 20:41:30 +0000

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.

Other questions or issues:

      Should multiple entries for the same IPv6 address be permitted?

            If so how will this be handled?

      If only 1 entry should be permitted, how should collisions be handled?

      Order of completion can also play a significant role in the resulting behavior.

      Should race conditions be removed e.g. SLAAC vs. DHCPv6 with renewal?

            Make one finish/timeout before starting the other?

      If DHCPv6 completes prior to the SLAAC process and the DHCPv6 lease expires, what

       happens to the address?

      Will device/system configuration tools show both entries for the same IPv6 address?

      Some devices hide the fact of there being more than one entry from the user.

        (Secret developer mode shows > 1 address in reality)

      Can existing tools permit the user to delete the "correct" entry if there is more

       than one for the same address?

      Additional information is typically maintained along with the IPv6 address e.g.

       configuration method used, lease time (DHCPv6), etc.

            How is this handled if there is a collision?

      There may be other permutations/issues for duplicate entries for an address.

Just a few observations and thoughts for your consideration and comment.

Regards,

Ken Burden

HP IT Network Architect

HP IPv6 Test Bed

---

From: Vlad Yasevich <[email-masked]>
Date: Thu, 27 Sep 2007 09:23:39 -0400

Hi Ken

>  function for an interface.

Sort of.  The IPv6 Scoped Address Architecture defines global scope as

  o  Global scope, for uniquely identifying interfaces anywhere in the
      Internet.

Which essentially means that no 2 interfaces on the internet may have the
same global address.  That's really a lofty goal and one would say is
impossible to verify.

However, DAD handles verifications on a specific link, and implementations
should take care not to assign the same address on different interfaces.

>  more than once through the various methodologies?

It should fail.  The first method of assignment should win the race.

-vlad

>       Manually configure an IPv6 address to match the SLAAC process.  Or
> enable DHCPv6 – in this
> 
>       Only enable one configuration method – manual, SLAAC or DHCPv6 for
> an interface/link
> 
>  
> 
>       Possibly make SLAAC and DHCPv6 use different methods for
> generating an address – same
> 
>       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
> 
>        entry may or may not be entered in the IP address table in this
> scenario the DHCPv6 lease’s
> 
>       Manually configure an IPv6 address to match the DHCPv6 process. 
> Or enable SLAAC – in
> 
>       Only enable one configuration method – manual, SLAAC or DHCPv6 for
> an interface/link
> 
>  
> 
>       Possibly make SLAAC and DHCPv6 use different methods for
> generating an address – same
> 
>       Can existing tools permit the user to delete the “correct” entry
> if there is more
>