Subject: Comments on <draft-ietf-6man-default-iids-07>

From: Bob Hinden <[email-masked]>
Date: Thu, 1 Oct 2015 08:22:27 -0700

Fernando, Alissa, Dave,

The first question I have is it appropriate to essentially deprecate the use of IEEE Mac address in the manner described in this document.  This would make most running IPv6 code non-compliant.  I agree with the recommendation that we should move away from IEEE MAC based IIDs, but I think if the w.g. is to go forward with this, then there needs to be guidance for existing implementations.  I think it would be very disruptive to the installed base of running IPv6 code the way this document is currently written.

This draft proposes to update 15 RFCs, but other than some high level guidance, it is not specific as what the changes should be to each RFC.  Since, I am now in the middle of doing the RFC2460bis and RFC4291bis updates, I have learned this style of update is very difficult to process when a bis document is produced. My current take is that new documents that updates an existing RFC, needs to have specific language as to what the update is.  Section 5 of RFC7136 is a good example of how to do this. I think this draft needs to do that for each RFC it is updating.

The document says it is updating RFC4291, but I didn’t see any mention of what the update is.

The document does say what the updates to RFC2464, RC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4338, RFC4391, RFC4944, RFC5121, and RFC5072 should accomplish, but as I mention above it does not include the specific changes to each document.

Section 3."Generation of IPv6 Interface Identifiers with SLAAC" says "By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed the underlying link-layer address in the IID.”, but then in the next paragraph is describes some exceptions to this statement.  I can’t tell which of the RFCs being updated have this property in the second paragraph.  The document needs to be much more specific.

In the same section, it says:

  “in some cases, embedding the link-layer address in the IID may reduce
  resource requirements such as energy, bandwidth and number of frames
  to carry a given IPv6 packet by facilitating header compression in
  constrained devices.”

I don’t understand how this relates to the earlier parts of this Section.  This needs additional explanation, and is another case it is hard to understand what an actual update to an IPv6 over <foo> document would be.

In Section 4. "Generation of IPv6 Interface Identifiers with DHCPv6” the document says an "DHCPV6 server SHOULD NOT generate predictable IPv6 addresses".  I agree with the recommendation, but note it does not update DHCPv6.  I would think it should.

Section 6. "Future Work”, I am not sure I understand the purpose of this section.  Why are these RFCs different from the ones listed in Section 3.  This needs more explanation.

A few editorial comments below.

Hope this is helpful.

Thanks,
Bob

> 
> 
> 
> 
> 
> IPv6 maintenance Working Group (6man)                            F. Gont
> Internet-Draft                                    SI6 Networks / UTN-FRH
> Updates: 2464, 2467, 2470,  2491, 2492,                        A. Cooper
>         2497, 2590, 3146, 3572, 4291,                             Cisco
>         4338, 4391, 4944, 5072, 5121                          D. Thaler
>         (if approved)                                         Microsoft
> Intended status: Standards Track                                  W. Liu
> Expires: February 20, 2016                           Huawei Technologies
>                                                         August 19, 2015
> 
> 
>          Recommendation on Stable IPv6 Interface Identifiers
>                    draft-ietf-6man-default-iids-07
> 
> Abstract
> 
>   The IPv6 addressing architecture defines Modified EUI-64 format
>   Interface Identifiers, and the existing IPv6 over various link-layers
>   specify how such identifiers are derived from the underlying link-
>   layer address (e.g., an IEEE LAN MAC address) when employing IPv6
>   Stateless Address Autoconfiguration (SLAAC).  The security and
>   privacy implications of embedding link-layer addresses in the
>   Interface Identifier have been known and understood for some time
>   now, and some popular IPv6 implementations have already deviated from
>   such schemes to mitigate these issues.  This document changes the
>   recommended default Interface Identifier generation scheme for SLAAC
>   to that specified in RFC7217, and recommends against embedding link-
>   layer addresses in IPv6 Interface Identifiers.  It formally updates
>   RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590,
>   RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC4944, RFC5072, and
>   RFC5121, which require IPv6 Interface Identifiers to be derived from
>   the underlying link-layer address.  Additionally, this document
>   provides advice about the generation of Interface Identifiers with
>   other address configuration mechanisms, such as Dynamic Host
>   Configuration Protocol version 6 (DHCPv6) and manual configuration.

This is too long for an abstract.  See:
https://www.rfc-editor.org/policy.html#policy.abstract

   "Every RFC must have an Abstract section following the Title of the
    document. An Abstract will typically be 5-10 lines. An Abstract of
    more than 20 lines is generally not acceptable."

> 
> 1.  Introduction
> 
>   [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for
>   IPv6 [RFC2460], which typically results in hosts configuring one or
>   more "stable" addresses composed of a network prefix advertised by a
>   local router, and an Interface Identifier (IID) [RFC4291] that
>   typically embeds a link-layer address (e.g., an IEEE LAN MAC
>   address).
> 

…...

> 
> 6.  Future Work
> 
>   At the time of this writing, the mechanisms specified in the
>   following documents might require updates to be fully compatible with
>   the recommendations in this document:
> 
>   o  RFC 6282 [RFC6282]
> 
>   o  RFC 4944 [RFC4944]
> 
>   o  RFC 6775 [RFC6775]

The document would be clearer is you used the title of these RFCs, not just the RFC number twice.

> 
>   Future revisions or updates of these documents should take the issues
>   of privacy and security mentioned in Section 1 and explain any design
>   and engineering considerations that lead to the use of IIDs based on
>   a node's link-layer address.
> 
> 7.  IANA Considerations
> 
>   There are no IANA registries within this document.  The RFC-Editor
>   can remove this section before publication of this document as an
>   RFC.
> 
> 8.  Security Considerations
> 
>   This document recommends [RFC7217] as the default scheme for
>   generating IPv6 stable addresses with SLAAC, such that the security
>   and privacy issues of IIDs that embed link-layer addresses are
>   mitigated.

The document also describes DHCPv6 and Manual configuration.  This should be included in the Security Considerations.

> 9.  Acknowledgements

….

---

From: Fernando Gont <[email-masked]>
Date: Thu, 1 Oct 2015 14:57:10 -0500

Hi, Bob,

Thanks so much for your detailed feedback! Please find my comments
in-line....

On 10/01/2015 10:22 AM, Bob Hinden wrote:
> Fernando, Alissa, Dave,
> 
> The first question I have is it appropriate to essentially deprecate
> the use of IEEE Mac address in the manner described in this document.

I think this is the most "lightweight" way in which this can possibly be
done: we don't really deprecate them, but just require the default to be
something else.

> This would make most running IPv6 code non-compliant.  I agree with
> the recommendation that we should move away from IEEE MAC based IIDs,
> but I think if the w.g. is to go forward with this, then there needs
> to be guidance for existing implementations.

mm.. not sure what you mean. Essentially, there's always a window of
time between the moment a spec gets published and the code is updated.
But that's intrinsic in any update: otherwise, the spec update would be
a no-op. (in any case please see below).

> I think it would be
> very disruptive to the installed base of running IPv6 code the way
> this document is currently written.

This is not really the case in practice: *

* Windows has moved away from  IEEE MAC based IIDs for ages now.

* I was notified last week that RedHat will already default to RFC7217
as soon as a new release starts employing the updated
NetworkManager/systemd.

* My understanding is that other Linux variants is moving in the
direction, too. For instance, the android folks were among the ones
pushing for an implementation of RFC7217 in Linux.

* I'm aware of an ongoing implementation of RFC7217 for OpenBSD and NetBSD.

So you could even argue that it's probably the other way around:
publishing this document would get more implementations (particularly
those with the biggest market share) on the "compliant" boat.

> This draft proposes to update 15 RFCs, but other than some high level
> guidance, it is not specific as what the changes should be to each
> RFC.  Since, I am now in the middle of doing the RFC2460bis and
> RFC4291bis updates, I have learned this style of update is very
> difficult to process when a bis document is produced. My current take
> is that new documents that updates an existing RFC, needs to have
> specific language as to what the update is.  Section 5 of RFC7136 is
> a good example of how to do this. I think this draft needs to do that
> for each RFC it is updating.

Based on personal experience, there are two different ways to write
update documents, each having pros and cons:

* What we did in this document. The document is clean. It sends a clear
signal of "when you read any of this updated documents, please remember
that IIDs must be generated according to this I-D". But yes, if you were
to produce bis documents of the updated documents, there is no
clearly-defined set of copy&paste edits.

* Do a "Please replace this XXXX, with YYYYY" (what we had done in a
previous version of the deprecate-atomfrag-generation I-D). This makes
it easy to produce subsequent bis documents (if needed), but the
document becomes hard to read, and in order to understand the spec you
have to mentally patch stuff as appropriate.

I personally think that for this document, they way we have written it
is the best approach. The documents is pretty easy to read, and the
metadata conveys the "please remember that when it comes to generating
IIDs, you should do it as in tis I-D as opposed to what the updated RFCs
say).

> mention of what the update is.

With a quick glance through RFC4291, I'd say: remove most of Section
2.5.1 and make that section point to default-iids.

> The document does say what the updates to RFC2464, RC2467, RFC2470,
> RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4338,
> RFC4391, RFC4944, RFC5121, and RFC5072 should accomplish, but as I
> mention above it does not include the specific changes to each
> document.

Each of this documents has a section (such as Section 2.5.1 in RFC4291
which specifies that IIDs are generated by embedding some sort of
link-layer address or the like in the IID).

> Section 3."Generation of IPv6 Interface Identifiers with SLAAC" says
> "By default, nodes SHOULD NOT employ IPv6 address generation schemes
> that embed the underlying link-layer address in the IID.”, but then
> in the next paragraph is describes some exceptions to this statement.
> I can’t tell which of the RFCs being updated have this property in
> the second paragraph.

None. The only reason for which we included the "exceptions" was the 6lo
folks.

>  The document needs to be much more specific.

Would a two-liner such as:

"In any instance where the updated RFCs discuss the generation of
Interface IDs, the recommendations regarding generation of IIDS should
apply".

do?

> “in some cases, embedding the link-layer address in the IID may
> reduce resource requirements such as energy, bandwidth and number of
> frames to carry a given IPv6 packet by facilitating header
> compression in constrained devices.”
> 
> I don’t understand how this relates to the earlier parts of this
> Section.  This needs additional explanation, and is another case it
> is hard to understand what an actual update to an IPv6 over <foo>
> document would be.

This is essentially leaving some gap from where you could get away with
using MAC-based IID -- i.e., reasons for going against our "SHOULD".
6lo, for example, can do their thing based on this paragraph.

> In Section 4. "Generation of IPv6 Interface Identifiers with DHCPv6”
> the document says an "DHCPV6 server SHOULD NOT generate predictable
> IPv6 addresses".  I agree with the recommendation, but note it does
> not update DHCPv6.  I would think it should.

Fine with me. Dave? Alissa?

> Section 6. "Future Work”, I am not sure I understand the purpose of
> this section.  Why are these RFCs different from the ones listed in
> Section 3.  This needs more explanation.

These RFCs fall into the "for performance, energy, blah blah, reasons,
you can do IEEE MAC based IIDs". For example, they need that for header
compression... and since they do not yet have a standardized
alternative, this is left as "future work".

>> Interface Identifiers, and the existing IPv6 over various
>> link-layers specify how such identifiers are derived from the
>> underlying link- layer address (e.g., an IEEE LAN MAC address) when
>> employing IPv6 Stateless Address Autoconfiguration (SLAAC).  The
>> security and privacy implications of embedding link-layer addresses
>> in the Interface Identifier have been known and understood for some
>> time now, and some popular IPv6 implementations have already
>> deviated from such schemes to mitigate these issues.  This document
>> changes the recommended default Interface Identifier generation
>> scheme for SLAAC to that specified in RFC7217, and recommends
>> against embedding link- layer addresses in IPv6 Interface
>> Identifiers.  It formally updates RFC2464, RFC2467, RFC2470,
>> RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291,
>> RFC4338, RFC4391, RFC4944, RFC5072, and RFC5121, which require IPv6
>> Interface Identifiers to be derived from the underlying link-layer
>> address.  Additionally, this document provides advice about the
>> generation of Interface Identifiers with other address
>> configuration mechanisms, such as Dynamic Host Configuration
>> Protocol version 6 (DHCPv6) and manual configuration.
> 

If really necessary (i..e., I think this is not really a hard-limit
regarding the number of lines in an Absract), I'd say we can remove most
of the first few sentences and leave the abstract as:

 This document
 changes the recommended default Interface Identifier generation
 scheme for SLAAC to that specified in RFC7217, and recommends
 against embedding link- layer addresses in IPv6 Interface
 Identifiers.  It formally updates RFC2464, RFC2467, RFC2470,
 RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291,
 RFC4338, RFC4391, RFC4944, RFC5072, and RFC5121, which require IPv6
 Interface Identifiers to be derived from the underlying link-layer
 address.  Additionally, this document provides advice about the
  generation of Interface Identifiers with other address
 configuration mechanisms, such as Dynamic Host Configuration
 Protocol version 6 (DHCPv6) and manual configuration.

>> following documents might require updates to be fully compatible
>> with the recommendations in this document:
>> 
>> o  RFC 6282 [RFC6282]
>> 
>> o  RFC 4944 [RFC4944]
>> 
>> o  RFC 6775 [RFC6775]
> 

Agreed. Will fix this.

>> generating IPv6 stable addresses with SLAAC, such that the
>> security and privacy issues of IIDs that embed link-layer addresses
>> are mitigated.
> 
> The document also describes DHCPv6 and Manual configuration.  This
> should be included in the Security Considerations.

How about if we replace the current text of the security considerations
with this:

 This recommends against the (default) use of predictable Interface
 Identifiers in IPv6 addresses. It recommends [RFC7217] as the default
 scheme for generating IPv6 stable addresses with SLAAC, such that the
 security and privacy issues of IIDs that embed link-layer addresses
 are mitigated, and recommends against predictable IIDs in DHCPv6 and
 manual configuration.

(proposed tweaks are welcome ;-) ).

Thanks a lot!

Cheers,

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

---

From: [email-masked]
Date: Wed, 14 Oct 2015 10:59:25 +0200

[Reusing this thread]

How, if at all, does this document affect interface-id generation on routers?

While it updates all the IPv6 over Foo documents, it seems to restrict itself to SLAAC generated addresses. That seems to leave interface-id generation on router's in an undefined state?

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Oct 2015 18:34:16 -0300

Hi, Ole,

Thanks for your comments. Please find mine in-line....

> How, if at all, does this document affect interface-id generation on

What makes them special?

> While it updates all the IPv6 over Foo documents, it seems to
> restrict itself to SLAAC generated addresses. That seems to leave
> interface-id generation on router's in an undefined state?

The document doesn't talk about client vs server vs router addresses,
but about mechanisms. And we don't need to talk about all of them, anyway.

The original goal of this I-D was to address SLAAC. Some folks noted
that commenting on manually-configured addresses and DHCPv6 was a good
thing -- hence we added comments on them.

So essentially this doc generally says that using MAC-based or
predictable IIDs is undesirable, and points fingers where possible.

I personally believe that this one is ready to go. We essentially
handcrafted every detail of this document, even with other wgs, to make
wveryone happy. At this point, I'd progress the document.

I don't think there's anything missing. But if there is, I'd do that in
a separate document, or simply fall back to having this doc only talk
about SLAAC, which was the original goal and motivation for this document.

If you remove boilerplate and intro, the spec is less than two pages. I
think it's time to ship the doc...

Thanks!

Cheers,

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: [email-masked]
Date: Thu, 15 Oct 2015 09:52:32 +0200

Fernando,

>> How, if at all, does this document affect interface-id generation on

<router implementor hat on>
routers don't do SLAAC. is this specification only for hosts?
you don't mention link-locals, how am I expected to generate those?

I'm sure you have answers. make it clear in the document.

> predictable IIDs is undesirable, and points fingers where possible.

then please define what you mean by SLAAC. in general SLAAC is the mechanism hosts use to create an addresses based on a received PIO and a self-generated interface-id. as in section 5 of 4862. that does not apply to routers.

cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Thu, 15 Oct 2015 05:16:19 -0300

Hi, Ole,

On 10/15/2015 04:52 AM, [email-masked] wrote:
> <router implementor hat on> routers don't do SLAAC. is this 
> specification only for hosts? you don't mention link-locals, how am
> I expected to generate those?
> 

Which RFC are you currently complying with to generate such addresses?

Unless I'm missing something, RFC4291 says that you must put an IID, and
then the IPv6-over-foo documents currently say e.g. for Ethernet you'd
put the MAC address in there.

So there's nothing special about router addresses vs. host addresses.

When it comes to link-locals, please see this text in RFC4862:

5.  Protocol Specification

   Autoconfiguration is performed on a per-interface basis on multicast-
   capable interfaces.  For multihomed hosts, autoconfiguration is
   performed independently on each interface.  Autoconfiguration applies
   primarily to hosts, with two exceptions.  Routers are expected to
   generate a link-local address using the procedure outlined below.  In
   addition, routers perform Duplicate Address Detection on all
   addresses prior to assigning them to an interface.

So, while odd, I guess one can say that routers do SLAAC for the
link-local addreses (albeit with no packet exchange other than that
required by DAD)

>> The document doesn't talk about client vs server vs router 
>> addresses, but about mechanisms. And we don't need to talk about 
>> all of them, anyway.
>> 
>> The original goal of this I-D was to address SLAAC. Some folks 
>> noted that commenting on manually-configured addresses and DHCPv6 
>> was a good thing -- hence we added comments on them.
>> 
> then please define what you mean by SLAAC. in general SLAAC is the 
> mechanism hosts use to create an addresses based on a received PIO 
> and a self-generated interface-id. as in section 5 of 4862. that
> does not apply to routers.

Section 5 (quoted above) explicitly says that Section 5.3 does pply to
routers. Or am I missing something?

Thanks!

Cheers,

---

From: [email-masked]
Date: Thu, 15 Oct 2015 10:29:32 +0200

Fernando,

> routers. Or am I missing something?

that's correct, but default-iids have no mention of link-local addresses, host vs routers and is not explicit on what is updated in the IPv6 over foo documents. I believe we're leaving a lot up to the implementors to stitch together here.

again with my router implementor hat on. another issue is of course if these defaults make sense for my 1495 lb (678 kg) router. it clearly isn't going to be mobile. it's not hard to guess what vendor it is regardless of IID. I'm worried that this document would now suddenly trigger compliance tests to change, and require this type of IID generation for e.g. link-locals. to cut a long story short, I'm not convinced that this change is worth doing in these particular implementations. nor am I convinced that 7217 would be the _correct_ change to make.

Best regards,
Ole

---

From: Mark Smith <[email-masked]>
Date: Thu, 15 Oct 2015 19:44:44 +1100

> link-local addreses (albeit with no packet exchange other than that

The IPv6 Node Requirements RFC6434 specifically calls that out too,

"5.9.2.  IPv6 Stateless Address Autoconfiguration - RFC 4862

   Hosts MUST support IPv6 Stateless Address Autoconfiguration as
   defined in [RFC4862].  Configuration of static address(es) may be
   supported as well.

   Nodes that are routers MUST be able to generate link-local addresses
   as described in [RFC4862]."

I'm not sure if the choice of "generate" is significant - I read that
statement as a router is required to support generating link-local
addresses via SLAAC, but it isn't required to use them, so it is
probably more of a default recommendation for how to automatically
create link-local addresses on routers' interfaces.

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 15 Oct 2015 05:45:18 -0300

Hi, Ole,

On 10/15/2015 05:29 AM, [email-masked] wrote:
>> Section 5 (quoted above) explicitly says that Section 5.3 does pply
>> to routers. Or am I missing something?
> 
> that's correct, but default-iids have no mention of link-local
> addresses, host vs routers 

Why should it?

> and is not explicit on what is updated in
> the IPv6 over foo documents. I believe we're leaving a lot up to the
> implementors to stitch together here.

What is, specifically, the stuff that implementors need to stich? The
idea is simple: whenever you have to generate the IID, you don't put the
MAC address there, but rather generate the IID with RFC7217.

> again with my router implementor hat on. another issue is of course
> if these defaults make sense for my 1495 lb (678 kg) router. it
> clearly isn't going to be mobile. it's not hard to guess what vendor
> it is regardless of IID.

That's only two of the issues discussed in address-generation-privacy.

> I'm worried that this document would now
> suddenly trigger compliance tests to change, and require this type of
> IID generation for e.g. link-locals. to cut a long story short, I'm
> not convinced that this change is worth doing in these particular
> implementations. nor am I convinced that 7217 would be the _correct_
> change to make.

To cut the long story short on my side:
I personally think that we should get rid off MAC addresses in IIDs.
That said, I can personally live with your 678 kg router doing something
else (even if that is sticking the MAC addresses in there) -- (albeit
not for the reasons you state, though :-) ).

If you can think of some magic that can make us all happy, I'm all ears...

Thanks!

Cheers,

---

From: Mark Smith <[email-masked]>
Date: Thu, 15 Oct 2015 20:09:26 +1100

> MAC address there, but rather generate the IID with RFC7217.

I see a lot of value in RFC7217's for router link-local addresses, as
it (with the right inputs for the Net_Iface parameter e.g., ifIndex,
or line card/module number) overcomes the common criticism of the use
of link-local addresses as routing protocol next-hops - that if you
swap out an interface, the link-local address changes because the MAC
address changed.

While packets with link-local addresses shouldn't leak off-link and to
outside the network, system log entries listing them might, so there
is also a small security benefit of using RFC7217s for link-locals for
routers because they obscure your chosen router vendor(s).

Another possibly minor benefit is that it is likely that all of your
routers' interface link-local IIDs within your network will be unique
across your whole network (and probably globally as well). That may
assist with something like auditing or troubleshooting e.g., if you
have a central record of all of your routers' link-local IIDs, if an
end-user reports a problem and you ask them to ping their default
router, you can verify things like they're attached to the right link
in the network. I've also thought if you put these now network unique
link-local addresses in DNS, it can make troubleshooting a little
easier, because although you'll still have to specify an outbound
interface, you can use names rather than having to enter/copy&paste
link-local addresses e.g.

router-a>ping -I eth0 eth1.router-b

where eth1.router-b resolves to fe80::<network unique RFC7217 IID>

Trivial in some regards, however it is consistent with the view that
it is better to use useful DNS names than IPv6 addresses.

Regards,
Mark.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 15 Oct 2015 11:13:49 +0200

>If you can think of some magic that can make us all happy, I'm all ears...

My personal preference who be to strongly recommend against using stable
MAC addresses for IIDs in a context where it would cause privacy problems
(i.e. mobile devices)

Mandate implementing both schemes (i.e. MAC based and stable identifiers)
in all cases. I.e. drop the requirement that new link layer specifications
ommit standards for MAC based IIDs.

And allow the implementor to choose a suitable default where it does
not violate privacy. I.e. the security issues are best left to the 
implementor. No need to specify that here.

Ideally the draft should be explicit that any mobile device that generates a
new MAC whenever it connects to a link for privacy reasons should not use
RFC-7217. This way RFC-7217 can be left to provide stable IIDs. And a
future RFC can discuss maintaining device anonymity.

---

From: [email-masked]
Date: Thu, 15 Oct 2015 11:29:32 +0200 (CEST)

> not for the reasons you state, though :-) ).

I'm with Ole here - I see no reason whatsoever why link-local addresses
for *routers* should have to change. As mentioned, there are plenty of
other ways to figure out what kind of box/vendor is at the other end of
a link (e.g. IPv4 ARP gives a reasonable hint).

Steinar Haug, AS 2116

---

From: Mark Smith <[email-masked]>
Date: Thu, 15 Oct 2015 20:50:35 +1100

> routers because they obscure your chosen router vendor(s).

Actually, they can more easily leak than that. They're source
addresses for RAs, so they're announced to hosts periodically or in
response to hosts' solicitations. They're also used as source
addresses for MLD queries from routers.

Another advantage of stable RFC7217 IIDs for link-locals on routers is
that the outcome of the MLD querier election will be consistent across
router reboots, as that uses link-local addresses to choose which
router will be the querier for the link.

Regards,
Mark.