Subject: RFC8064 implemented in linux ?

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 28 Jun 2019 13:49:29 +0200

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

---

From: Martin Hunek <[email-masked]>
Date: Fri, 28 Jun 2019 18:35:32 +0200

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. :-)

---

From: Erik Kline <[email-masked]>
Date: Fri, 28 Jun 2019 09:59:48 -0700

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 <[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 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...
>
> 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.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Martin Hunek <[email-masked]>
Date: Fri, 28 Jun 2019 20:04:15 +0200

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

---

From: Mark Smith <[email-masked]>
Date: Sat, 29 Jun 2019 10:37:32 +1000

> I hope that RFC8064 would never be implemented on any router. As would be

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.

> 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.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Jun 2019 14:13:24 +1200

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,
> 
> It's intended to be implemented on all SLAAC implementations, not just hosts.
> 
> 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.)

    Brian

> 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.
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Sat, 29 Jun 2019 13:48:27 +1000

On Sat., 29 Jun. 2019, 12:13 Brian E Carpenter, <[email-masked]>
wrote:

> >     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'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.

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.

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".

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.)

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.

> do so, as they do for IPv4. It just isn't arp -a any more.

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.

> (In Windows it's netsh int ipv6 show neigh, but I don't know how to

ip -6 neigh show

or

ip -6 neigh ls

Regards,
Mark.

> >     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...
> >
> >     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
> >     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
> >     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.
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Jun 2019 16:12:29 +1200

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'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.

> 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.

> 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.
> 
> 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".

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.
 
> 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.)
> 
> 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.
> 
> 
> 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.

   Brian

>     >     > 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
>     >     >
>     >     >
>     >
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Mark Smith <[email-masked]>
Date: Sat, 29 Jun 2019 15:07:23 +1000

On Sat., 29 Jun. 2019, 14:12 Brian E Carpenter, <[email-masked]>
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 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.
>
> > 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.
>
> > 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. 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.

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.

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.

> > 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
> > 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.
> >
> >
> 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.)

Regards,
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.
> >     >
> >     >     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
> >     >     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.
> >     >
> >     >     Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> >     >
> >     > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> >     >