[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Address collisions on a single interface via multiple configuration methods
Hi Ken
Burden, Ken wrote:
>
>
> 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.
>
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.
>
>
> What happens if a system/device attempts to assign the same IPv6 global
> address to an interface
>
> more than once through the various methodologies?
It should fail. The first method of assignment should win the race.
-vlad
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>