Subject: RFC7217

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Sep 2018 11:59:54 +0200

> Network_ID:
>            Some network-specific data that identifies the subnet to which
>            this interface is attached -- for example, the IEEE 802.11
>            Service Set Identifier (SSID) corresponding to the network to
>            which this interface is associated.  Additionally, Simple DNA
>            [RFC6059 <https://tools.ietf.org/html/rfc6059>] describes ideas that could be leveraged to generate
>            a Network_ID parameter.  This parameter is OPTIONAL.

What to use for cellular links?  The Access Point Name (APN)?

>   This document does not require the use of any specific PRF for the
>     function F() above,

YEt, F is a PRF and the text does say: SHA-1 [FIPS-SHS 
<https://tools.ietf.org/html/rfc7217#ref-FIPS-SHS>] and SHA-256  are two 
possible options for F().

The text describing the secret_key should say that its value MUST be 
saved for future use.  One must make sure to use the same secret_key 
(and other params) for the same prefix, so the generated Interface ID is 
stable.

>   However, the method discussed in
>            this document could be employed for generating Interface IDs
>            of any arbitrary length, albeit at the expense of reduced
>            entropy (when employing Interface IDs smaller than 64 bits).

It should also say "and with the advantage of increased entropy (when 
emplying Interface IDs longer than 64 bits)."

>        The resulting Interface Identifier SHOULD be compared against the
>         reserved IPv6 Interface Identifiers [RFC5453 <https://tools.ietf.org/html/rfc5453>] [IANA-RESERVED-IID 
> <https://tools.ietf.org/html/rfc7217#ref-IANA-RESERVED-IID>]

What is the algorithm of comparison?

I dont think we have such an algorithm.

An exact match algorithm may not work sufficiently well when comparing 
Interface IDs of different lengths.

>     Including the SLAAC prefix in the PRF computation causes the
>     Interface Identifier to vary across each prefix (link-local, global,
>     etc.) employed by the host and, consequently, also across networks.

I think the IID for the link-local prefix (if such a thing exists) will 
stay stable across networks because the prefix itself is stable.  As 
such I think this phrase should be reformulated.

>     Including the optional Network_ID parameter when computing the RID
>     value above causes the algorithm to produce a different Interface
>     Identifier when connecting to different networks, even when
>     configuring addresses belonging to the same prefix.  This means that
>     a host would employ a different Interface Identifier as it moves from
>     one network to another even for IPv6 link-local addresses or Unique
>     Local Addresses (ULAs) [RFC4193 <https://tools.ietf.org/html/rfc4193>].

I do not understand the LL part.  For LL prefix, when changing networks 
all parameters of F() will stay same - why the generated IID changes?

In many deployments the Network_ID in WiFi (ESSID) stays the same across 
many subnets.

Alex