Workaround for macOS and iOS devices

[puppe]

Thanks for your great work. ip6neigh makes IPv6 so much nicer to deal with. 🙂

As you mention in the README, macOS and iOS devices do not use the EUI-64 to generate a stable IPv6 address. ip6neigh cannot differentiate the stable addresses that they use from their temporary addresses. And the interface identifiers of these "stable" addresses do change if the prefix changes, so it is also often not possible to predefine these hosts.

I just wanted to report, that I have found a nice workaround, that accomplishes the following:

• Make these devices addressable with only their hostname, i.e. I do not have to remember that I have to type ping6 hostname1 for some devices and ping6 hostname2.tmp for others.
• Still keep the distinction between stable and temporary addresses for other devices. (Note the contrast to setting option tmp_label '0'.)

I simply define a CNAME record for these devices in /etc/config/dhcp:

config cname
    option cname 'host.your.local.domain'
    option target 'host.TMP.your.local.domain'

I realize this is not really an earth-shattering revelation, but it works well enough for me. Maybe having it here for reference will be useful to others. Feel free to close this issue.

[AndreBL]

Hi Puppe,

Thanks for the contribution. How about the Example #2 in ip6neigh/etc/config/dhcp? Do you think it would work for at least the ULA and link-local addresses of Apple devices? See below.

# Example 2: Windows machines or other hosts that do not use EUI-64 IIDs, but
# use other static IIDs instead:
config host
    option name     'Laptop-Paul'
    #Copy the MAC address of the device.
    option mac      '2e:36:e7:85:d3:3b'
    #Copy the interface identifier from the link-local address of
    #of the device.
    option slaac    'daa1:4554:747b:1f50'

If the stable IID is not the same for all address scopes, the options below might help to complete the setup, allowing the user to specify the stable IID for each scope.

If your GUA prefix is dynamic and this makes the GUA IID dynamic too, then the CNAME solution you proposed could be applied to make host.GUA.your.local.domain point to host.TMP.GUA.your.local.domain.

# New options for host sections:
# slaac     0=disabled, 1=enabled with standard EUI-64 IID. Other value means
#           "use this custom IID". See the example configs below.
# lla_iid   Override 'slaac' IID for link-local address
# ula_iid Override 'slaac' IID for ULA address
# wula_iid  Override 'slaac' IID for WULA address
# gua_iid   Override 'slaac' IID for GUA address

[AndreBL]

I forgot to mention that I do not currently own any devices from Apple. So I'm unable to investigate the particularities of their IPv6 implementation. But since you're experimenting with it, any feedback you provide will be helpful to prepare a workaround to be included in the program.

[cvmiller]

André,

I believe Apple is now using Sematically Opaque Identifiers with SLAAC (RFC 7217). https://www.rfc-editor.org/rfc/rfc7217.txt

-- IPv6 is the future! http://ipv6-net.blogspot.ca/

On Sat, Jun 23, 2018 at 4:03 AM, André notifications@github.com wrote:

I forgot to mention that I do not currently own any devices from Apple. So I'm unable to investigate the particularities of their IPv6 implementation. But since you're experimenting with it, any feedback you provide will be helpful to prepare a workaround to be included in the program.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/AndreBL/ip6neigh/issues/3#issuecomment-399666057, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVbk8ZKCbctqNZ4VMpijutevH1zMSg3ks5t_iB2gaJpZM4Ukghk .

[AndreBL]

Hi Craig,

I believe that too. Still they can have some specific design decisions. From the RFC:

Compute a random (but stable) identifier with the expression:

       RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)
.......
Net_Iface:
          An implementation-dependent stable identifier associated with
          the network interface for which the RID is being generated.
          An implementation MAY provide a configuration option to select
          the source of the identifier to be used for the Net_Iface
          parameter.  A discussion of possible sources for this value
          (along with the corresponding trade-offs) can be found in
          Appendix A.

Once I read that Apple operating systems were using randomized MAC addresses for WiFi interfaces, which could in theory make the stable IIDs less stable.

When my relatives come with iPhones I see a large number of link-local addresses being attributed to their devices.

[cvmiller]

André,

I believe the "randomized" MACs are only used for Wireless probes, not after a Mac connects to the wireless network. It is an effort to prevent silent tracking of your phone/Mac while passing through public wifi spots.

Craig...

On 06/23/2018 09:24 AM, André wrote:

Hi Craig,

I believe that too. Still they can have some specific design decisions. From the RFC:

|Compute a random (but stable) identifier with the expression: RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) ....... Net_Iface: An implementation-dependent stable identifier associated with the network interface for which the RID is being generated. An implementation MAY provide a configuration option to select the source of the identifier to be used for the Net_Iface parameter. A discussion of possible sources for this value (along with the corresponding trade-offs) can be found in Appendix A. |

Once I read that Apple operating systems were using randomized MAC addresses for WiFi interfaces, which could in theory make the stable IIDs less stable.

When my relatives come with iPhones I see a large number of link-local addresses being attributed to their devices.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/AndreBL/ip6neigh/issues/3#issuecomment-399690558, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVbk_KXGYxnsidux3xFAnnrP7nFQHvpks5t_mvKgaJpZM4Ukghk.

-- IPv6 is the future ipv6-net.blogspot.ca