Subject: Re: RFC8064 implemented in linux ?

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 1 Jul 2019 11:27:27 +0200

Le 29/06/2019 à 04:13, Brian E Carpenter a écrit :
> On 29-Jun-19 12:37, Mark Smith wrote:
>>
>>
>> On Sat., 29 Jun. 2019, 02:36 Martin Hunek, <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>      Hi Alex, hi all,
>>
>>      I hope that this mail would not be breach to Code of Conduct, but this is straight from network's operator heart. :-)
>>
>>      I hope that RFC8064 would never be implemented on any router. As would be operational nightmare.
>>
>>
>> It's intended to be implemented on all SLAAC implementations, not just hosts.
>>
>> That includes routers, and it explicitly includes Link Local addresses.
>>
>> That is so that Link Local addresses of routers are both auto-generated and stable across interface module swaps.
> 
> Right, but nowhere is it said that you MUST NOT assign static addresses,
> including static LL addresses, if that's what you want to do.
> Nor does RFC8064 say that you MUST assign RFC7217 identifiers to all
> interfaces; even its title says "recommendation".
> 
> So it seems to me that Martin can do what he wants, even if it means
> changing an implementation default.
> 
> Sites that need to correlate IP addresses with MAC addresses can still
> do so, as they do for IPv4. It just isn't arp -a any more.
> 
> (In Windows it's netsh int ipv6 show neigh, but I don't know how to
> spell that in Linuxese.)

could be something like 'ip -6 show nc'

Alex

> 
>      Brian
> 
> 
>>
>>
>>
>>
>>      I can see need for privacy with global addresses
>>
>>
>> RFC8064 (indirectly RFC 7217) is not about privacy addresses.
>>
>> They're the opposite use case - persistent, stable addresses, entirely independent of or only loosely coupled to hardware e.g. device backplane slot.
>>
>>
>>      as it is clear that individuals could be easily tracked over the internet when using EUI-64 suffixes. It is not so obvious with stationary servers, but OK - you could remotely detect vendor and model of hardware, so yes if you really need to hide that it is reasonable.
>>
>>      When client need to generate LL address with other method then EUI-64, that is for me hard to grasp. Reactions to reasons from RFC8064:
>>      As network operator, I can still correlate network activity by accounting in RADIUS or just mirror access port and track it based on L2 addresses. There is no location tracking possible with LL address as prefix fe80:: would not tell any more or less about location with or without randomized suffix. Address scanning is still not needed as all I need is ask at all nodes multicast address and I get a list of addresses in local segment. Only real reason why I would like to hide device vendor+model is so called "device-specific vulnerability exploitation". But still I can just listen on the line waiting for traffic and then just connect to port 80 or 443 and it would just happily tell. But OK, if someone thinks that it is really needed and that it would be beneficial to cover vendor+model instead of doing proper firewall...
>>
>>      Lastly the case of router (OpenWRT):
>>      Why would I need to use anything else than EUI-64? As network operator I need address that is static (on WAN interface at least), so I can do reliable static leases if customer wants them. You could argue that there is DUID for that and you would be right - in theory. But I have seen routers which generated random DUID on every boot (UBNT), that of course was major problem so only static thing left was LL address, which was EUI64. Other thing I seen were custom DHCPv6-PD hooks, which extracted MAC from some DUID types, made LL address from that and placed record for delegated prefix paired with computed LL address as destination. And I've seen clients which hides DUID so well that easiest way how to get it is packet snooping and manual link reset.
>>
>>      So when there would not be predictable LL address on WAN interface, I would not be able to make static routing records in routing table based on value written on customer CPE - the MAC address. So no more prefix reservation based on phone customer support, we would have to go trough provisioning of CPE prior installation.
>>
>>      Another "solution" would be to make dynamic routing table and when I'm giving customer /56, I can reduce it to /120 so I can encode 64b of random ID into prefix. Hopefully just an idea for April fool's RFC:
>>
>>      Address scheme would than look like:
>>      /29 from RIR -> 3b for MANs
>>      /32 for my MAN -> 8b for POPs
>>      /40 for POP -> 8b for interface+VLAN
>>      /48 for interface/VLAN -> 64b left for client LL suffix to provide static pool
>>      /112 would be max prefix length for customer or /120 when "legacy" devices on segment.
>>
>>      All that because router could get tracked on local link? By whom? Network operator would still be able to track every connection and they often must by law. By the way network operator still must be able to deliver packets to router so it needs to keep track of router's addresses/prefixes. Only real "benefit" RFC8064 brings to network operators would be a headache.
>>
>>      Because similar privacy related solution we are actually forced to go from SLAAC to DHCPv6 for server addresses because we cannot tell what IPv6 address server would have, so either no AAAA+PTR records (DDNS is not an option) or we would have to provision every server to use EUI64.
>>
>>      Long story short, RFC8064 needs a bis that it MUST NOT be used on routers. Otherwise it could bring real problems to real networks. All for purely theoretical issue router could have with its privacy.
>>
>>      I hope that I didn't offend anyone, I couldn't help myself.
>>
>>      Regards,
>>      Martin
>>
>>      PS: If you read it up to this point, than you are real good. :-)
>>
>>      Dne pátek 28. června 2019 13:49:29 CEST, Alexandre Petrescu napsal(a):
>>      > Is RFC8064 implemented in linux, with kernels 4.x, on openwrt? (in
>>      > addition to BSD).
>>      >
>>      > I am asking because the IPWAVE WG IPv6-over-OCB document is not
>>      > implemented in BSD. IPv6-over-OCB is implemented extensively on linux.
>>      >
>>      > The IPv6-over-OCB document suggests a 'transition time' to migrate from
>>      > current embedded platforms that do LL addresses formed from hardwired
>>      > MAC addresses (linux kernel 4.x openwrt) to future software where the LL
>>      > addresses are formed from more random IID (RFC8064).
>>      >
>>      > The Transport Area review of this document demands a value for this
>>      > 'transition time'.  My speculation, without knowing the current
>>      > implementation status of RFC8064 on openwrt with kernels 4.x, is that
>>      > the value of 'transition time' nears 5 years.
>>      >
>>      > Alex
>>      >
>>      >
>>
>>      --------------------------------------------------------------------
>>      IETF IPv6 working group mailing list
>>      [email-masked] <mailto:[email-masked]>
>>      Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>      --------------------------------------------------------------------
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Fernando Gont <[email-masked]>
Date: Tue, 2 Jul 2019 13:39:34 +0100

On 28/6/19 17:35, Martin Hunek wrote:
> Hi Alex, hi all,
> 
> I hope that this mail would not be breach to Code of Conduct, but
> this is straight from network's operator heart. :-)
> 
> I can see need for privacy with global addresses as it is clear that
> individuals could be easily tracked over the internet when using
> EUI-64 suffixes. It is not so obvious with stationary servers, but OK
> - you could remotely detect vendor and model of hardware, so yes if
> you really need to hide that it is reasonable.
> 
> When client need to generate LL address with other method then
> EUI-64, that is for me hard to grasp.

Using predictable numeric identifiers is bad practice. See e.g.:
https://tools.ietf.org/html/draft-gont-predictable-numeric-ids-03

> Lastly the case of router (OpenWRT): Why would I need to use anything
> else than EUI-64? As network operator I need address that is static
> (on WAN interface at least), so I can do reliable static leases if
> customer wants them. 

Not sure what you are referring to. LLs are not leased. RFC8064 is about
*autoconfigured* addresses.

Besides, RFC7217 addresses are meant to be stable. Depending on the
implementation, they may even be stale across NIC swaps/replacement.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Martin Hunek <[email-masked]>
Date: Tue, 02 Jul 2019 16:53:55 +0200

Hi Fernando,

see in-line.

Regards,
Martin

> https://tools.ietf.org/html/draft-gont-predictable-numeric-ids-03
Sorry, but this is your opinion not a fact. What is the thread of predictable IID used in *Link-Local* address?

I can see reasons behind not using EUI-64 together with global addresses but not with LLs. There is no point of hiding LL address from your operator. I can still get both MAC and LL address, but instead of just taking picture of MAC sticker on your CPE (or from DHCPv4), I would need to eavesdrop on your line. I can imagine that it would be more of the privacy breach, than knowing your CPE LL address from your MAC...
> *autoconfigured* addresses.
Sure the LL addresses are not leased, but network prefix is leased to them. At least that is a result of either DHCPv6-PD or manual lease in the routing table.
> implementation, they may even be stale across NIC swaps/replacement.
If every device on link would use a same method, which would allow to predict with absolute probability, LL address based on MAC address and maybe some other variables known to operator (as in EUI-64 case), I would have nothing against that.

But in case of RFC7217 there is:
F(): Unknown to operator because every implementation can use different hash function.
Prefix: Known to operator.
Net_Iface: Unknown to operator.
Network_ID: Known for WAN link to operator.
DAD_Counter: Known to be initially 0.
secret_key: Pseudorandom - unknown to operator.

F(), Net_Iface could be somehow guested when you know MAC address so you know vendor + model if you also know software version. But there is still secret_key. So as network operator I'm not capable to say which LL address device would have just by looking on the box and reading MAC address from it. I would need to unbox it, connect it to network and read its address from wireshark.

Long story short, back in days prior any privacy addresses where all IIDs fould be generated by EUI-64, I would be able to tell which address would be used by which device. This makes process of doing manual entries to routing table easy. When you know which prefix you want to assign to CPE and you know CPE's MAC you know also CPE's LL address and it is all you need to make record in routing table. With RFC8064 and BYOD policy you are screwed.

---

From: Martin Hunek <[email-masked]>
Date: Tue, 02 Jul 2019 18:00:35 +0200

Hi, Brian, hi Mark,

Thank you for replies, see in-line.

Regards,
Martin

Dne sobota 29. června 2019 7:07:23 CEST, Mark Smith napsal(a):
> On Sat., 29 Jun. 2019, 14:12 Brian E Carpenter, <[email-masked]>
> wrote:
> 
> > On 29-Jun-19 15:48, Mark Smith wrote:
> > >
> > >
> > > On Sat., 29 Jun. 2019, 12:13 Brian E Carpenter, <
> > [email-masked] <mailto:[email-masked]>> wrote:
> > >
> > >     > On Sat., 29 Jun. 2019, 02:36 Martin Hunek, <[email-masked]
> > <mailto:[email-masked]> <mailto:[email-masked] <mailto:
> > [email-masked]>>> wrote:
> > >     >
> > >     >     Hi Alex, hi all,
> > >     >
> > >     >     I hope that this mail would not be breach to Code of Conduct,
> > but this is straight from network's operator heart. :-)
> > >     >
> > >     > That is so that Link Local addresses of routers are both
> > auto-generated and stable across interface module swaps.
> > >
> > > I've never said people can't use static default router addresses if they
> > wanted to.
> > >
> > > He's saying that RFC 8064/RFC 7217 is so operationally terrible
> > ("operational nightmare") that it should never be implemented on any router
> > at all.
> >
> > I got that. But that's a choice an operator can make, and therefore it
> > isn't an IETF issue, is it? That's exactly why RFC2119 SHOULD is defined
> > the way it is.

There is no choice for operator to make. When client's router start using RFC8064, the operator have just one choice adapt to new situation or stop providing IPv6 service to such clients. It is simply making IPv6 deployment harder as you can no longer use information you have from IPv4 deployment - the MAC address. You cannot change defaults of CPE vendor when you have no means of provisioning over CPE (BYOD policy).
> >
> > > I'm pointing out that a specific use case for RFC 7217 is routers
> > because one justification I've heard for setting static LL addresses on
> > routers was because changing the interface module changed the MAC address,
> > which meant the router's EUI-64 based LL address IID also changed.

Not if you are using link aggregation techniques. Then you would have virtual MAC.
> >
> > > That's why I suggested explicitly saying that RFC 7217 applied to LLs
> > too when it was being developed, and why there are a number of options for
> > the Net_Iface parameter in the RFC 7217 appendix, some of which won't
> > change even when an interface module swap results in an interface
> > link-layer address change.

Sure, but when having large router with changeable interface cards, than you are typically using dynamic routing protocols. So it is unlikely to be affected. However with small CPE you are not having this option (either to swap interface or dynamic routing).
> > >
> > > Another motivation for static LLs on routers might be to help with
> > troubleshooting, through ease of an end-user typing the address  e.g. "ping
> > -I eth0 fe80::1".

I've seen that on one router. Doesn't work well if you have two of those in one network. Interesting thing was that this router maintained that fe80::1 address even when it was switched into bridge mode. So having same fe80::1 address on real gateway and also on some bridge inside network resulted in IPv6 not working as gateway couldn't be reached.
> >
> > Sure. And in a largish network, router 3 in sector 7 could be fe80::7:3 .
> > But "ping fritz.box" works nicely too, chez moi; there are many tricks you
> > could play.
> >
> 
> If you have globally unique LL addresses for your routers, which is what
> RFC 7217 should produce, then you can put them in DNS AAAA/PTR records
> without conflict.
> 
> You could hide those records from the Internet using split DNS, although
> they don't really disclose all that much, other than the number of router
> interfaces in your network.
> 
> Of course, even after a successful DNS resolution, they're not reachable
> addresses to anybody except for those on the link on which they're present.
> 
> I haven't tried, however it's probably possible to have an AAAA record for
> ff02::2.

Not that I would like to put LL address to DNS. It is just one more problem caused by that privacy related methods of generating IIDs. This is the reason why at university we do have split namespace of IPv4 and IPv6. We have <hostname>.<unit>.tul.cz for IPv4 and <hostname>.<unit>.ip6.tul.cz for EUI-64 generated addresses. If every device would use predictable IID, there would not be a problem to have same DNS namespace for both protocols. This way every host outside of essential services prefer IPv4 as they are known to network administration and IPv6 addresses are just guested.

So if we want to really know host's IPv6 address we would need to use DHCPv6 instead of SLAAC. So no IPv6 for Android.
> 
> Ultimately, if you want to be really end-user friendly you could hide a lot
> of this detail by wrapping it in a script that does checks like is there a
> default route, is the next hop address pingable or checks ND entires for
> NUD state etc.
> 
> One of the more common faults with IP addresses I've seen is typos, and
> annoyingly we humans seem to have a complexity bias, so we tend skip over
> what should be the first and the simplest check of "are the settings
> correct" (I've seen weeks of troubleshooting take place because that was
> skipped, and then the fault resolved in seconds once that check finally
> took place.)
> 
> Automation of address generation such as RFC 7217 limits opportunity for
> typo errors to mostly during software development. If an address doesn't
> need to be typed in, then there cannot be a typo at that time.

No dispute about typos. But RFC7217 is not providing predictable IID even for operator. When used on LL addresses, operator is loosing one of a few identifiers guaranteed to work across multiple vendors.
> 
> Address typos were much less of an issue in IPX and Appletalk networks
> because it was quite rare to manually type any address information in in
> comparison to IPv4.

Sure, but what would you put into DNS when you are not provided with IID used together with prefix. When you are not provided with address and you are not willing to allow clients to update your zone via DDNS, what is left for SLAAC only client?
> 
> 
> 
> > > However, I think asking the end user to "ping -I eth0 ff02::2" (link
> > scope all routers multicast address) and then having them read out the last
> > couple of digits of the address or addresses that respond is just as easy
> > and equivalent for default router troubleshooting. (A test on this Linux
> > box shows that specifying an interface on the ping to ff02::2 command can
> > also be optional.)

Most of users are capable of making screen shots or at least take a photo of their screen, so it is not a unsolvable problem for remote support, even that it is not an ideal.
> > >
> > > Martin also talks about no need for privacy addresses on
> > servers/routers, which makes me wonder if he has RFC 8064/7217 confused
> > with RFC 4941.

Actually I know the difference between those two. :-) And yes, RFC7217 is quite better from operational point of view than RFC4941 was. However the RFC8064 is bringing privacy addresses according to RFC7217 to LL addresses, when there was no privacy related issue to start with. I'm stating that EUI-64 is better IID for router's WAN interface LL address than RFC7217 (at least from operational point of view). And that reasoning of RFC8064 doesn't apply for router's WAN LL address.

As such, it doesn't bring benefits for routers and it is introducing operational nightmares for networks which are expecting to see EUI-64 in LL addresses. And when you not gain anything and just loose something, it is simply not good bargain.
> > >     changing an implementation default.

You cannot do that on CPE with BYOD policy.

> > > I wonder what they're fundamentally trying to achieve when they do this,
> > and if it is based on a false assumption that MAC addresses can't or can't
> > easily be changed, and therefore MAC addresses are a good and reliable
> > end-user identifier.
> >
> > Yes, I've noticed that site security people hate mutable MAC addresses
> > ;-). But on a large BYOD network, they aren't much help anyway.
> >
> 
> Yes.
> 
> If you want to attribute things to an end user, then indentify the end user
> by authenticating the end user themselves, rather than trying to use
> machine identifiers as proxies for them.
> 
> (I like to imagine a proposal of people being handcuffed to their devices
> to better bind machine identifiers to people. Pretty much unrealistic and
> ridiculous in most scenarios, and that's why machine identifiers aren't a
> good proxy for people identifiers. The binding isn't very strong.)

MAC is not providing security, it is used for clients IPv4 reservations and by using EUI-64 it could be also used to handle IPv6 prefix reservations inside of routing table. Sure, client is free to change its MAC. But if they do so, they will break just their own connection by loosing their address reservations.

I would be happy to use DUID instead, but not all IPv4 clients supports DUIDs, DUID is really hard to find inside of device and it is also changeable by user.

Also RADIUS integration with DHCPv6 could be improved in implementations. Some DHCPv6 servers like Kea can do that but only in payed version, some DHCPv6 servers doesn't support that at all.

From rather small network point of view, the easiest way was to use IPv4 reservation database to generate IPv6 prefix reservations to clients EUI-64 based LL addresses as easiest solution. But with RFC8064 applied on router's WAN LL address, that would be no longer be an option. And yes, in one small community ISP I'm working for, we have BYOD policy as well as connect yourself policy... :-(
> Mark.
> > > ip -6 neigh show
> > > or
> > > ip -6 neigh ls
> > > Mark.
> > >     > They're the opposite use case - persistent, stable addresses,
> > entirely independent of or only loosely coupled to hardware e.g. device
> > backplane slot.
> > >     >
> > >     >
> > >     >     as it is clear that individuals could be easily tracked over
> > the internet when using EUI-64 suffixes. It is not so obvious with
> > stationary servers, but OK - you could remotely detect vendor and model of
> > hardware, so yes if you really need to hide that it is reasonable.
> > >     >
> > EUI-64, that is for me hard to grasp. Reactions to reasons from RFC8064:
> > >     >     As network operator, I can still correlate network activity by
> > accounting in RADIUS or just mirror access port and track it based on L2
> > addresses. There is no location tracking possible with LL address as prefix
> > fe80:: would not tell any more or less about location with or without
> > randomized suffix. Address scanning is still not needed as all I need is
> > ask at all nodes multicast address and I get a list of addresses in local
> > segment. Only real reason why I would like to hide device vendor+model is
> > so called "device-specific vulnerability exploitation". But still I can
> > just listen on the line waiting for traffic and then just connect to port
> > 80 or 443 and it would just happily tell. But OK, if someone thinks that it
> > is really needed and that it would be beneficial to cover vendor+model
> > instead of doing proper firewall...
> > >     >
> > >     >     Why would I need to use anything else than EUI-64? As network
> > operator I need address that is static (on WAN interface at least), so I
> > can do reliable static leases if customer wants them. You could argue that
> > there is DUID for that and you would be right - in theory. But I have seen
> > routers which generated random DUID on every boot (UBNT), that of course
> > was major problem so only static thing left was LL address, which was
> > EUI64. Other thing I seen were custom DHCPv6-PD hooks, which extracted MAC
> > from some DUID types, made LL address from that and placed record for
> > delegated prefix paired with computed LL address as destination. And I've
> > seen clients which hides DUID so well that easiest way how to get it is
> > packet snooping and manual link reset.
> > >     >
> > >     >     So when there would not be predictable LL address on WAN
> > interface, I would not be able to make static routing records in routing
> > table based on value written on customer CPE - the MAC address. So no more
> > prefix reservation based on phone customer support, we would have to go
> > trough provisioning of CPE prior installation.
> > >     >
> > >     >     Another "solution" would be to make dynamic routing table and
> > when I'm giving customer /56, I can reduce it to /120 so I can encode 64b
> > of random ID into prefix. Hopefully just an idea for April fool's RFC:
> > >     >
> > >     >     All that because router could get tracked on local link? By
> > whom? Network operator would still be able to track every connection and
> > they often must by law. By the way network operator still must be able to
> > deliver packets to router so it needs to keep track of router's
> > addresses/prefixes. Only real "benefit" RFC8064 brings to network operators
> > would be a headache.
> > >     >
> > >     >     Because similar privacy related solution we are actually
> > forced to go from SLAAC to DHCPv6 for server addresses because we cannot
> > tell what IPv6 address server would have, so either no AAAA+PTR records
> > (DDNS is not an option) or we would have to provision every server to use
> > EUI64.
> > >     >
> > >     >     Long story short, RFC8064 needs a bis that it MUST NOT be used
> > on routers. Otherwise it could bring real problems to real networks. All
> > for purely theoretical issue router could have with its privacy.
> > >     >
> > >     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
> > <mailto:[email-masked]>>
> > >     >     Administrative Requests:
> > https://www.ietf.org/mailman/listinfo/ipv6
> > >     >
> > >     > Administrative Requests:
> > https://www.ietf.org/mailman/listinfo/ipv6
> > >     >

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 Jul 2019 11:24:07 +1200

On 03-Jul-19 04:00, Martin Hunek wrote:

> When client's router start using RFC8064, the operator have just one choice adapt to new situation or stop providing IPv6 service to such clients. It is simply making IPv6 deployment harder as you can no longer use information you have from IPv4 deployment - the MAC address.

Since the client is in any case free to manually configure any static address they want, you really can't assume that Modified EUI-64 is used anyway. So I think the only safe solution is to extract the MAC address from the neighbor cache.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 5 Jul 2019 23:36:58 +0100

Hello, Martin,

On 2/7/19 15:53, Martin Hunek wrote:
>>> I can see need for privacy with global addresses as it is clear
>>> that individuals could be easily tracked over the internet when
>>> using EUI-64 suffixes. It is not so obvious with stationary
>>> servers, but OK - you could remotely detect vendor and model of
> Sorry, but this is your opinion not a fact. What is the thread of
> predictable IID used in *Link-Local* address?

What the referenced I-D shows is that whenever we have employed
predictable IDs, that has led to problems. That is a fact, not opinion.

And the fact that we have had to fix each numeric ID in each protocol
piecemeal is a sad story we should learn from, rather than something we
want to repeat.

> I can see reasons behind not using EUI-64 together with global
> addresses but not with LLs. There is no point of hiding LL address
> from your operator. I can still get both MAC and LL address, but
> instead of just taking picture of MAC sticker on your CPE (or from
> DHCPv4), I would need to eavesdrop on your line. I can imagine that
> it would be more of the privacy breach, than knowing your CPE LL
> address from your MAC...

I assume you are referring only to routers, right? -- Because Windows
has not employed the traditional SLAAC scheme (embedding mac addresses
in the IID) for a long time.

>>> Lastly the case of router (OpenWRT): Why would I need to use
>>> anything else than EUI-64? As network operator I need address
>>> that is static (on WAN interface at least), so I can do reliable
>>> static leases if customer wants them.
>> 
>> Not sure what you are referring to. LLs are not leased. RFC8064 is
>> about *autoconfigured* addresses.
>> 
> Sure the LL addresses are not leased, but network prefix is leased to
> them. At least that is a result of either DHCPv6-PD or manual lease
> in the routing table.

If the DUID is based on the MAC address, why would you care about the LL
address, anyway?

>> Besides, RFC7217 addresses are meant to be stable. Depending on
>> the implementation, they may even be stale across NIC
>> swaps/replacement.
>> 
> If every device on link would use a same method, which would allow to
> predict with absolute probability, LL address based on MAC address
> and maybe some other variables known to operator (as in EUI-64 case),
> I would have nothing against that.
> 
> But in case of RFC7217 there is: F(): Unknown to operator because
> every implementation can use different hash function. Prefix: Known
> to operator. Net_Iface: Unknown to operator. Network_ID: Known for
> WAN link to operator. DAD_Counter: Known to be initially 0. 
> F(), Net_Iface could be somehow guested when you know MAC address so
> you know vendor + model if you also know software version. But there
> is still secret_key. So as network operator I'm not capable to say
> which LL address device would have just by looking on the box and
> reading MAC address from it. I would need to unbox it, connect it to
> network and read its address from wireshark.

If for some reason you use some other algorithm (e.g., the traditional
one) to generate addresses, override the default.

> Long story short, back in days prior any privacy addresses where all
> IIDs fould be generated by EUI-64, I would be able to tell which
> address would be used by which device. This makes process of doing
> manual entries to routing table easy. When you know which prefix you
> want to assign to CPE and you know CPE's MAC you know also CPE's LL
> address and it is all you need to make record in routing table. With
> RFC8064 and BYOD policy you are screwed.

You might consider this a feature. The goal is indeed to improve privacy
by default.