• Thomas Haller's avatar
    core: avoid generating reserved IPv6 interface identifiers · f15c4961
    Thomas Haller authored
    https://tools.ietf.org/html/rfc7217 says:
      The resulting Interface Identifier SHOULD be compared against the
      reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
      and against those Interface Identifiers already employed in an
      address of the same network interface and the same network
      prefix.  In the event that an unacceptable identifier has been
      generated, this situation SHOULD be handled in the same way as
      the case of duplicate addresses (see Section 6).
    In case of conflict, this suggests to create a new address incrementing
    the DAD counter, etc. Don't do that. If we generate an address of the
    reserved region, just rehash it right away. Note that the actual address
    anyway appears random, so this re-hashing is just as good as incrementing
    the DAD counter and going through the entire process again.
    Note that now we no longer generate certain addresses like we did
    previously. But realize that we now merely reject (1 + 16777216 + 128)
    addresses out of 2^64. So, the likelyhood of of a user accidentally
    generating an address that is suddenly rejected is in the order of
    10e-13 (1 / 1,099,503,173,697). Which is not astronomically, but still
    extreeeemely unlikely.
    Also, the whole process is anyway build on the idea that somebody else
    might generate conflicting addresses (DAD). It means, there was always
    the extremely tiny chance that the address you generated last time is
    suddenly taken by somebody else. So, this change appears to a user
    like these reserved addresses are now claimed by another (non existing)
    host and a different address gets generated -- business as usual, as
    far as SLAAC is concerned.
nm-core-utils.c 129 KB