Re: RFC8064 implemented in linux ?

[Erik Kline <[e-mail]>]

Does the last paragraph of section 1 address your concerns?

   The recommendations in this document apply only in cases where
   implementations otherwise would have configured a stable IPv6 IID
   containing a link-layer address.

and so on.

On Fri, 28 Jun 2019 at 09:35, Martin Hunek <[e-mail]> 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. 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
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>