Subject: FW: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt

From: Ing-Wher Chen <[email-masked]>
Date: Mon, 13 Jan 2014 22:36:43 +0000

Hello,

The informational draft below documents Ericsson's solution, deployed since early 2013, regarding Mikael's concern in the recent discussion about ND denial-of-service attacks.  The draft also elaborates on Lorenzo's point regarding discovering neighbors based on DAD-NS packets.

Thanks,
Helen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 10, 2014 4:44 PM
To: Joel Halpern; Ing-Wher Chen; Joel Halpern; Ing-Wher Chen
Subject: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt

A new version of I-D, draft-halpern-6man-nd-pre-resolve-addr-00.txt
has been successfully submitted by I. Chen and posted to the IETF repository.

Name:		draft-halpern-6man-nd-pre-resolve-addr
Revision:	00
Title:		Triggering ND Address Resolution on Receiving DAD-NS
Document date:	2014-01-10
Group:		Individual Submission
Pages:		7
URL:            http://www.ietf.org/internet-drafts/draft-halpern-6man-nd-pre-resolve-addr-00.txt
Status:         https://datatracker.ietf.org/doc/draft-halpern-6man-nd-pre-resolve-addr/
Htmlized:       http://tools.ietf.org/html/draft-halpern-6man-nd-pre-resolve-addr-00

Abstract:
   This draft proposes a new optional event to trigger address
   resolution using IPv6 Neighbor Discovery.  This helps optimize router
   performance, and can help mitigate certain potential ND-related
   denial-of-service attacks.  Upon receiving a DAD-NS message, the
   neighbor solicitation message used to detect duplicate addresses, if
   the target address encoded in the DAD-NS is not a duplicate address,
   the receiving device responds by triggering address resolution for
   the target address in the DAD-NS, in preparation for expectant future
   communication with the sending device.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ing-Wher Chen <[email-masked]>
Date: Mon, 13 Jan 2014 22:52:40 +0000

Please note that we're actively working with Ericsson's legal department on an IPR disclosure regarding the draft.

Thanks,
Helen

-----Original Message-----
From: Ing-Wher Chen 
Sent: Monday, January 13, 2014 2:37 PM
To: [email-masked]'
Subject: FW: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt

Hello,

Thanks,
Helen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 10, 2014 4:44 PM
To: Joel Halpern; Ing-Wher Chen; Joel Halpern; Ing-Wher Chen
Subject: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt

Abstract:

The IETF Secretariat

---

From: Greg Daley <[email-masked]>
Date: Fri, 17 Jan 2014 02:14:01 +0000

Hi Helen,

I've got a couple of issues with the draft apart from IPR.

It seems that principal assumption is that off-link flooding can occur due to sending packets to unknown host destinations on a subnet, and reuses the mandatory DAD-NS transmission as a proof-of-life for an address to avoid packets being transmitted on the link.

Firstly, I think there could be simpler mitigation techniques for this:
1/ Mandate DHCP for global prefixes - which ensures that the devices send packets to routers on the link to keep their address (and limit unregistered address lookups)
2/ Treat on-link generated ND Cache entries (or entries which have previously been REACHABLE) as different to off-link generated (rate limit).

In that case, the ND resolution behaviour for incomplete off-link is reduced and live communications cannot be impacted. There is still a potential DoS issue for initiating communications to quiet servers, but if the on-link server has ever talked to the router it could still have a STALE NCE.

Secondly, the proposal assumes that DAD-NS packets are visible to all devices on the link, whereas they aren't in a Multicast-snooped environment.

This implicitly requires that the router is assigned to an all-multi interface on the switch infrastructure, which it may be (but this isn't stated).  It also negates the general applicability of this to hosts (rather than routers).

Neighbour Solicitation messages for incomplete entries (per RFC 4861 S7.2.2) will be dropped by the snooping switches if there is no Multicast subscriber for the solicited nodes' multicast address.  Not only is this a mitigation of the potential attack, but also indicates an alternative for non-snooping networks:

3/ Monitor the solicited nodes' addresses in the MLD querier router, and do not transmit an NS from off-link for an incomplete address unless someone is listening.

So I guess my comment is that we have two other potential solutions for mitigating transmission of off-link initiated NS's ( 1- Use DHCP bindings and 3 - MLD Solicited Nodes'), and some fair ideas for mitigating resource challenges in the ND engine (2), and decreased applicability in multicast snoop environments.

Can you tell us why we should use this encumbered solution?

Sincerely, 

Greg Daley
[email-masked] 

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Ing-Wher Chen
Sent: Tuesday, 14 January 2014 9:53 AM
To: [email-masked]
Subject: RE: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt

Thanks,
Helen

-----Original Message-----
From: Ing-Wher Chen 
Sent: Monday, January 13, 2014 2:37 PM
To: [email-masked]'
Subject: FW: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt

Hello,

Thanks,
Helen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 10, 2014 4:44 PM
To: Joel Halpern; Ing-Wher Chen; Joel Halpern; Ing-Wher Chen
Subject: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt

Abstract:

The IETF Secretariat

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

---

From: Ole Troan <[email-masked]>
Date: Fri, 17 Jan 2014 10:43:50 +0100

Greg, sorry to divert your thread.

> Neighbour Solicitation messages for incomplete entries (per RFC 4861 S7.2.2) will be dropped by the snooping switches if there is no Multicast subscriber for the solicited nodes' multicast address.…

I hear that MLD snooping for the solicited-node multicast groups isn't supported in most (if not all) switches.
partly because MLD snooping doesn't work well, but also because it becomes very costly to support state for this many multicast groups.

anyone with differing experience?

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 17 Jan 2014 01:48:39 -0800

On Fri, Jan 17, 2014 at 1:43 AM, Ole Troan <[email-masked]> wrote:

> partly because MLD snooping doesn't work well, but also because it becomes
> very costly to support state for this many multicast groups.
>

On wifi networks, I don't see why that would be. There are basically two
solicited-node groups per host, and wifi access points already track lots
of state on a per-MAC address basis.

---

From: Tim Chown <[email-masked]>
Date: Fri, 17 Jan 2014 13:38:06 +0000

> anyone with differing experience?

Well, MLD snooping seems very prone to bugs.  We have an open case currently with a particular vendor which means if we enable MLD snooping (which is beneficial given we have several multicast IPv6 TV channels) the devices will get a little 'enthusiastic' and filter all RAs.  We have had at least one similar case in the past.  I guess use of MLD snooping in enterprise networks is relatively rare though.

Tim

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 17 Jan 2014 10:43:02 -0500

Let me see if I can help a bit.

Firstly, we are trying for something that works with the existing 
specified Ipv6 deployments.  So mandating DHCP, and DHCP-guard, was not 
a choice we felt we could take.   Using DHCP, dhcp-guard, and dhcp 
derived mechanisms to fill the router table is indeed a viable 
alternative for operators who wish to run their networks that way.

Secondly, we are specifically concerned with the off-link based denial 
of service attack.  Where the attack attempts to fill either the link 
(hard) or the router cache in such a way as to interfere with legitimate 
address resolution and communication.  The use of multicast by IPv6 ND 
is understood and assumed.  It does not help when the router is the 
target of the external attack.

Yours,
Joel

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 17 Jan 2014 09:22:05 -0800

> Well, MLD snooping seems very prone to bugs.  We have an open case currently with a particular vendor which means if we enable MLD snooping (which is beneficial given we have several multicast IPv6…

Tim,

was that for WiFi APs or wireless controllers doing MLD snooping? Or 
good ol' Ethernet switches?

The more data we have on this the better.

Thanks,
    Erik

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 17 Jan 2014 18:39:15 +0000

>> There are basically two solicited-node groups per host

Does this assume that typically there are only 2 non link-local IPv6 addresses  per host? (since different addresses are unlikely to fall in the same group, as long as they have different interface identifiers)

From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Friday, January 17, 2014 1:49 AM
To: Ole Troan
Cc: Ing-Wher Chen; 6man WG
Subject: Re: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt

On Fri, Jan 17, 2014 at 1:43 AM, Ole Troan <[email-masked]<mailto:[email-masked]>> wrote:
I hear that MLD snooping for the solicited-node multicast groups isn't supported in most (if not all) switches.
partly because MLD snooping doesn't work well, but also because it becomes very costly to support state for this many multicast groups.

On wifi networks, I don't see why that would be. There are basically two solicited-node groups per host, and wifi access points already track lots of state on a per-MAC address basis.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 17 Jan 2014 11:01:42 -0800

On Fri, Jan 17, 2014 at 10:39 AM, Dmitry Anipko <[email-masked]
> wrote:

> Does this assume that typically there are only 2 non link-local IPv6
> addresses  per host? (since different addresses are unlikely to fall in the
> same group, as long as they have different interface identifiers)
>

A more precise statement would be that the number of solicited-node groups
scales linearly with the number of IPv6 addresses assigned to hosts, which
is something that people don't usually seem to worry about.

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 17 Jan 2014 19:14:35 +0000

>>A more precise statement would be that the number of solicited-node groups scales linearly with the number of IPv6 addresses assigned to hosts,

Agreed. And generally, number of addresses can be more than 2-3 (because of multiple prefixes, and because of multiple suffixes due to privacy extensions).

>>which is something that people don't usually seem to worry about.

We have recently seen issues in some APs, where they were not able to handle multiple addresses per host, because of some state maintained per host (that's not a justification that host should not have multiple addresses, but I just wanted to note that today there are issues in some cases related to that).

________________________________
From: Lorenzo Colitti <[email-masked]>
Sent: Friday, January 17, 2014 11:01 AM
To: Dmitry Anipko
Cc: Ole Troan; Ing-Wher Chen; 6man WG
Subject: Re: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt

A more precise statement would be that the number of solicited-node groups scales linearly with the number of IPv6 addresses assigned to hosts, which is something that people don't usually seem to worry about.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 17 Jan 2014 11:36:44 -0800

On Fri, Jan 17, 2014 at 11:14 AM, Dmitry Anipko <[email-masked]

>  >>A more precise statement would be that the number of solicited-node
> groups scales linearly with the number of IPv6 addresses assigned to hosts,
>
> Agreed. And generally, number of addresses can be more than 2-3 (because
> of multiple prefixes, and because of multiple suffixes due to privacy
> extensions).
>
Indeed. But in the common case of a wifi network where devices come and go
frequently, you'll typically have only a link-local, a global, and one
temporary address. If you use EUI-64 the link-local and the global will be
on the same group.

>  We have recently seen issues in some APs, where they were not able to
> handle multiple addresses per host, because of some state maintained per
> host (that's not a justification that host should not have multiple
> addresses, but I just wanted to note that today there are issues in some
> cases related to that).
>
We should clarify that such behaviour is broken and that saying, "it works
in IPv4, so we should just use DHCPv6 for address assignment so that we can
force the host to have only one address" is not a solution.

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 17 Jan 2014 19:40:56 +0000

>> We should clarify that such behaviour is broken and that saying, "it works in IPv4, so we should just use DHCPv6 for address assignment so that we can force the host to have only one address" is not a solution.

Agree with you.

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Friday, January 17, 2014 11:37 AM
To: Dmitry Anipko
Cc: Ole Troan; Ing-Wher Chen; 6man WG
Subject: Re: MLD snooping of solicted-node multicast (Was: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt

Agreed. And generally, number of addresses can be more than 2-3 (because of multiple prefixes, and because of multiple suffixes due to privacy extensions).
Indeed. But in the common case of a wifi network where devices come and go frequently, you'll typically have only a link-local, a global, and one temporary address. If you use EUI-64 the link-local and the global will be on the same group.

We have recently seen issues in some APs, where they were not able to handle multiple addresses per host, because of some state maintained per host (that's not a justification that host should not have multiple addresses, but I just wanted to note that today there are issues in some cases related to that).
We should clarify that such behaviour is broken and that saying, "it works in IPv4, so we should just use DHCPv6 for address assignment so that we can force the host to have only one address" is not a solution.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 17 Jan 2014 16:13:51 -0800 (PST)

>To: Dmitry Anipko <[email-masked]> 
>Cc: 6man WG <[email-masked]>; Ing-Wher Chen <[email-masked]> 
>Sent: Saturday, 18 January 2014 6:36 AM
>On Fri, Jan 17, 2014 at 11:14 AM, Dmitry Anipko <[email-masked]> wrote:
>

And remind them that all interfaces are to also have link-local addresses (RFC4291), and link-local addresses are candidates for use by applications (RFC4007, RFC6724).

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 17 Jan 2014 21:01:55 -0800

Greg,

In addition to your concern about multicast snooping environments, the 
DAD packets are not reliably delivered. If e.g. there is a short WiFi 
drop, the spanning tree is reconverging, etc then the single transmitted 
DAD packet will not be received.

Thus as best this will collect some entries in the neighbor cache.

It isn't at all clear when a node should discard entries from its 
neighbor cache. That is potentially problematic when there are lots of 
devices that pick new temporary IPv6 addresses each time they power on 
since that will force routers to sooner or later discard entries from 
the neighbor cache. The routers would have to guess which addresses 
might still be assigned to the hosts.

Thus all in all this is not a robust approach to the problem.

    Erik

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sat, 18 Jan 2014 00:58:28 -0800 (PST)

----- Original Message -----
> From: Greg Daley <[email-masked]>
> To: 'Ing-Wher Chen' <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: 
> Sent: Friday, 17 January 2014 1:14 PM
<snip>

> 
> 3/ Monitor the solicited nodes' addresses in the MLD querier router, and do 
> not transmit an NS from off-link for an incomplete address unless someone is 
> listening.
>

So I've been thinking for the last few months that this method could be a useful further mitigation to off-link ND cache attacks for routers. I've been writing something up which I've been planning to finish and post in the next week or so.

I think it could be fairly effective - there are a total possible 2^24 solicited-node multicast groups on a link, where as there will only be as many present ones as there are IIDs with unique lower 24 bits. For most subnets I think that will number in the order of 10s or 100s, and perhaps on rare occasions in the low 1000s. So NSes would only be necessary for e.g. 1000/2^24 portion of the unicast address space, otherwise the packets that would trigger them can be dropped (or perhaps sent to an RFC6018 greynet collector).

A neighbor cache attack is likely to be still be possible for the 2^40 portions of unicast address space covered by each of the the present solicited-multicast groups, however Fernando's Stable/Opaque IID draft would make them harder to find, even though it will increase the number of them, as there is an unique Opaque IID per prefix.

All routers listening to MLD track group membership, not just the MLD querier, so all routers on the link could implement this method.

Regards,
Mark.

---

From: Greg Daley <[email-masked]>
Date: Sun, 19 Jan 2014 22:50:12 +0000

Hi Mark, 

When we were looking at accelerating DAD for mobile nodes a while ago, I investigated the state held by MLD and wrote a draft.
(Now expired http://tools.ietf.org/html/draft-daley-ipv6-mcast-dad-02)

A much better solution was found (now RFC 4429), but the consistent state keeping by the MLD querier (and other routers) is still present (particularly for MLDv2).

(I am now thinking out loud, so please bear with me)

The difference is that the solicited nodes' address was not identical to an address binding and that (after listener state synchronization) only the non-presence of an MLD listener on the solicited nodes address could be used to prove the address was absent.  For relatively sparse links and subnets this would allow the router to state explicitly that the address was not in use.

For ND cache protection, the presence of any MLD listener on the solicited nodes' activates the group, and no-listeners means there isn't even a reason to transmit the neighbour solicitation.

Unless the router maintains additional ND cache state, it cannot distinguish between an activated group and which of the addresses is active, and thus a subset of the addresses (e.g. the globally routable equivalent of a Link-local address with a particular solicited nodes [and anything with the same IID lower order bits]).

Is this sufficient protection, or does there have to be more specific state gathered in the ND cache, perhaps through the discussed draft?

Sincerely, 

Greg Daley

-----Original Message-----
From: Mark ZZZ Smith [mailto:[email-masked]] 
Sent: Saturday, 18 January 2014 7:58 PM
To: Greg Daley; 'Ing-Wher Chen'; [email-masked]
Subject: Re: New Version Notification for draft-halpern-6man-nd-pre-resolve-addr-00.txt

----- Original Message -----
> Subject: RE: New Version Notification for 
> draft-halpern-6man-nd-pre-resolve-addr-00.txt
> 
> Hi Helen,
> 
<snip>

> 
> 3/ Monitor the solicited nodes' addresses in the MLD querier router, 
> and do not transmit an NS from off-link for an incomplete address 
> unless someone is listening.
>

Regards,
Mark.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 22 Jan 2014 00:33:08 -0800 (PST)

Hi Greg,

----- Original Message -----
> To: 'Mark ZZZ Smith' <[email-masked]>; 'Ing-Wher Chen' <[email-masked]>; "[email-masked]" <[email-masked]>
> Cc: 
> Sent: Monday, 20 January 2014 9:50 AM
> When we were looking at accelerating DAD for mobile nodes a while ago, I 
> investigated the state held by MLD and wrote a draft.
> A much better solution was found (now RFC 4429), but the consistent state 
> keeping by the MLD querier (and other routers) is still present (particularly 
> for MLDv2).
> 
> The difference is that the solicited nodes' address was not identical to an 
> address binding and that (after listener state synchronization) only the 
> non-presence of an MLD listener on the solicited nodes address could be used to 
> prove the address was absent.  For relatively sparse links and subnets this 
> would allow the router to state explicitly that the address was not in use.
> 
> For ND cache protection, the presence of any MLD listener on the solicited 
> nodes' activates the group, and no-listeners means there isn't even a 
> reason to transmit the neighbour solicitation.
> 

Exactly.

> Unless the router maintains additional ND cache state, it cannot distinguish 
> between an activated group and which of the addresses is active, and thus a 
> subset of the addresses (e.g. the globally routable equivalent of a Link-local 
> address with a particular solicited nodes [and anything with the same IID lower 
> order bits]).
> 

True. The presence of a solicited-node group on a link only indicates at least one of the addresses that would map to it is present.

> Is this sufficient protection, or does there have to be more specific state 
> gathered in the ND cache, perhaps through the discussed draft?
> 

I see this idea as another quite useful mitigation, but certainly not a prevention of the ND cache DoS attack.

As the number of present solicited-node groups is very unlikely to ever exceed 1% of the total available solicited-node groups (2^24/16M), that means that NSes don't have to be performed for destination addresses that map the the remaining 99% of solicited-node groups. This is in comparison to today where NSes would be performed for any unknown destination within the /64. I think that would be another measure that usefully reduces the effectiveness of the off-link ND cache DoS attack against a router. Less predictable solicited-node groups, as a result of draft-ietf-6man-stable-privacy-addresses, would further reduce the effectiveness of the off-link ND cache DoS.

I though of this idea while thinking about how MLD/solicited-node group membership might be able used to facilitate node registration, preventing the router ND cache DoS attack. It previously occurred to me that if nodes are using MLDv2, meaning that all nodes report their membership of all groups, then routers tracking solicited-node membership would now have knowledge of one of all of the attached nodes' link-local addresses (either as the nodes initialise their addresses, or because a router initiates a querier election when it initialises) . If the nodes then supported Inverse ND+, then the routers could query the nodes for their other addresses, giving them complete knowledge of all unicast addresses on all nodes, achieving complete node registration. NUD would then take care of expiring node registrations when the nodes disappear. 

This method wouldn't achieve the efficiency goals of draft-chakrabarti-nordmark-6man-efficient-nd. I think its value would be that it leverages existing mechanisms such as MLDv2 and Inverse ND, and would have a relatively low implementation cost.

Regards,
Mark.

+  or perhaps RFC4620 Node Information Queries, although I think Inverse ND might be better because it is likely to be simpler to implement, and isn't Experimental.

> Subject: Re: New Version Notification for 
>>  To: 'Ing-Wher Chen' <[email-masked]>; 
> "[email-masked]" 
>>  <[email-masked]>
>>  Cc: 
> So I've been thinking for the last few months that this method could be a 
> useful further mitigation to off-link ND cache attacks for routers. I've 
> been writing something up which I've been planning to finish and post in the 
> next week or so.
> 
> I think it could be fairly effective - there are a total possible 2^24 
> solicited-node multicast groups on a link, where as there will only be as many 
> present ones as there are IIDs with unique lower 24 bits. For most subnets I 
> think that will number in the order of 10s or 100s, and perhaps on rare 
> occasions in the low 1000s. So NSes would only be necessary for e.g. 1000/2^24 
> portion of the unicast address space, otherwise the packets that would trigger 
> them can be dropped (or perhaps sent to an RFC6018 greynet collector).
> 
> A neighbor cache attack is likely to be still be possible for the 2^40 portions 
> of unicast address space covered by each of the the present solicited-multicast 
> groups, however Fernando's Stable/Opaque IID draft would make them harder to 
> find, even though it will increase the number of them, as there is an unique 
> Opaque IID per prefix.
> 
> All routers listening to MLD track group membership, not just the MLD querier, 
> so all routers on the link could implement this method.
> 
> Regards,
> Mark.
>

---

From: Greg Daley <[email-masked]>
Date: Thu, 23 Jan 2014 22:56:50 +0000

Hi Mark, 

I guess it is for others to identify if the protection is sufficient, I would just like to show that there is a feasible mitigation with MLD.

[chop]

>> Unless the router maintains additional ND cache state, it cannot 
>> distinguish between an activated group and which of the addresses is 
>> active, and thus a subset of the addresses (e.g. the globally routable 
>> equivalent of a Link-local address with a particular solicited nodes 
>> [and anything with the same IID lower order bits]).
>> 

>> Is this sufficient protection, or does there have to be more specific 
>> state gathered in the ND cache, perhaps through the discussed draft?
>> 

> As the number of present solicited-node groups is very unlikely to ever exceed 1% of the total available solicited-node groups (2^24/16M), that means
> that NSes don't have to be performed for destination addresses that map the the remaining 99% of solicited-node groups. This is in comparison to
> today where NSes would be performed for any unknown destination within the /64. I think that would be another measure that usefully reduces the
> effectiveness of the off-link ND cache DoS attack against a router. Less predictable solicited-node groups, as a result of
> draft-ietf-6man-stable-privacy-addresses, would further reduce the effectiveness of the off-link ND cache DoS.

> I though of this idea while thinking about how MLD/solicited-node group membership might be able used to facilitate node registration, preventing
> the router ND cache DoS attack. It previously occurred to me that if nodes are using MLDv2, meaning that all nodes report their membership of all
> groups, then routers tracking solicited-node membership would now have knowledge of one of all of the attached nodes' link-local addresses (either as
> the nodes initialise their addresses, or because a router initiates a querier election when it initialises) . If the nodes then supported Inverse ND+,
> then the routers could query the nodes for their other addresses, giving them complete knowledge of all unicast addresses on all nodes, achieving
> complete node registration. NUD would then take care of expiring node registrations when the nodes disappear. 

I think that the value principally comes from the mandatory nature of MLD (though in MLDv1, a node can fail to transmit a report IFF there is another member of the group that has visibly reported - which activates the group anyway).

Additional information is probably extraneous and is limited by the fact that devices may not have implemented particular capabilities (i.e. they are not required by the Node Requirements RFC6434)

Greg Daley