Re: RFC8064 implemented in linux ?

[Martin Hunek <[e-mail]>]

Hi Erik,

I'm not quite sure. I thought that EUI-64 is a stable Interface Identifier (IID), so RFC8064 would apply for a router.

After all, that was in original e-mail, which set me off.

Martin

Dne pátek 28. června 2019 18:59:48 CEST, Erik Kline napsal(a):
> 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
> > --------------------------------------------------------------------
> >