Re: RFC8064 implemented in linux ?

[Martin Hunek <[e-mail]>]

Hi Fernando,

see in-line.

Regards,
Martin

Dne úterý 2. července 2019 14:39:34 CEST jste napsal(a):
> 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 hope that RFC8064 would never be implemented on any router. As
> > would be operational nightmare.
> > 
> > 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
> 
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...
> 
> 
> > 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.
> 
> 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.
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.