Subject: [v6ops] Best venue to begin addressing the "/64 ND DoS" concerns ?

From: RJ Atkinson <[email-masked]>
Date: Fri, 15 Jul 2011 09:31:12 -0400

On 14  Jul 2011, at 23:00 , Joel Jaeggli wrote:
> On Jul 13, 2011, at 9:51 AM, RJ Atkinson wrote:
> 
>> On Weds 13 July 2011 at 11:54:08 -0400, Joel Halpern wrote:
>>> There appear to be several different cases, which can be addressed 
>>> by different reasonable mechanisms (not firewalls, and not lengthening
>>> the subnet prefix.)
>>> 
>>> For ISPs, I would assume the primary concern is routers connecting 
>>> to subnets used to provide services. A non-dynamic approach to ND
>>> can address that.
>>> 
>>> For ISPs providing bridged residential services, the ISP normally 
>>> operates on the basis that it gets registration information 
>>> from all the devices in the home.  Thus, it does not need
>>> to generate ND solicitations.
>> 
>> Agreed.
>> 
>> I do think it would be useful to have an informational document
>> that describes the issue, describes the several cases, and outlines 
>> some reasonable mechanisms (possibly separate mechanisms for each case),
>> both for the benefit of network operations folks and also for
>> the benefit of equipment suppliers.
> 
> we discussed some possible (but certainly incomplete) mitigations in:
> 
> http://tools.ietf.org/html/draft-gashinsky-v6nd-enhance-00
> 
> but we also proposed changes to v6nd so that's why we brought it to 6man
> 
>> Perhaps I am confused, but such a document sounds more like an IPv6 Ops WG 
>> item than an IPv6 WG item.  So I'm wondering whether this thread belongs 
>> over there rather than here.
> 
> possibly, probably it straddles both groups.

(First, a broad apology for cross-posting this note, which is in a
thread that originated on the IPv6 WG mailing list.  I encourage
authors of follow-up notes to consider whether their follow-up 
might belong only on 1 of these 2 lists.  WG Chair guidance 
about proper place for follow-up discussion would also be welcome.  :-)

I apologise for being unclear.  The document I was trying to propose
in the quoted text above was NOT about protocol changes, but instead
would focus on extant mitigations -- so the document I was proposing
would more obviously seem to fit in IPv6 Ops WG.

To some extent, I would prefer an approach where IPv6 Ops would work
on that informational document (threats/concerns, operational use cases,
existing mitigations that could be deployed) first.  Then, if there
were use cases not adequately covered by the material in that (proposed)
IPv6 Ops WG document, the IPv6 WG could use that IPv6 Ops WG document
to examine potential protocol specification changes on a much more 
informed basis.

I am concerned that the current document is inadvertently 
"putting the cart in front of the horse" by going straight 
to the IPv6 WG, without starting with an informational 
"issues and existing-mitigations" type document over in the 
IPv6 Ops WG.  Operator input on this topic would be strongly 
beneficial since this is fundamentally an operations issue.

I'm also concerned that most of the operational folks are active 
in the IPv6 Ops WG , while only some of those folks are active 
in IPv6 WG.  So it would seem better to start working these
concerns over there and later, after the IPv6 Ops WG has reached
some conclusions about the issues/existing mitigations,
possibly bring that output to the IPv6 WG to drive discussion
of potential protocol specification changes in a more informed
way than we seem to be achieving just now.  Perhaps I am 
more nearly an outlier in my concern that we not start with
protocol modification discussions and instead start with a
separate document covering the concerns/issues, use cases,
and existing/known mitigations (possibly organised by use case).

Yours,

Ran Atkinson

---

From: Philip Homburg <[email-masked]>
Date: Fri, 15 Jul 2011 19:35:01 +0200

>to examine potential protocol specification changes on a much more 

I could be wrong, but the impression I got from the various ops lists is that
the way you deal with this attack is to avoid using RFC-4862 and/or RFC-4861.

For example:
- Just use link local on a link between two routers
- Configure a much longer prefix (/120)
- Have /128s on separate interfaces
- Use a static neighbor cache and then disable ND
- (From draft-gashinsky-v6nd-enhance) Have hosts inject /128s 

And there is also
- Use a statefull firewall (and break end-to-end connectivity).

draft-gashinsky-v6nd-enhance give a nice overview, but more importantly
already tries to modify RFC-4861.

If v6ops first wants to spend time writing a requirements document, then
that's fine with me.

But to me it seems more productive to explore the design space, write an
informational document about that and then solicit feedback from v6ops on
whether there are any options that seem to make some kind of sense in their
environment.

>Operator input on this topic would be strongly 

I would classify a protocol that is at the heart of IPv6 and that is subject
of a relatively low-tech DoS as a protocol problem and not as an ops problem.
(Of course, it remains an ops problem until the protocol is fixed)

---

From: Fred Baker <[email-masked]>
Date: Sat, 16 Jul 2011 10:38:45 -0700

On Jul 15, 2011, at 6:31 AM, RJ Atkinson wrote:

> I apologise for being unclear.  The document I was trying to propose in the quoted text above was NOT about protocol changes, but instead would focus on extant mitigations -- so the document I was proposing would more obviously seem to fit in IPv6 Ops WG.

Sounds reasonable to me.

One general consideration in this note. In addition to the fact of multiple prefixes on a LAN, IPv6 Privacy Addresses (RFC 4491) are a case in which a single interface (and therefore MAC address) might legitimately have multiple addresses within the same prefix. Unless I am mistaken, Windows by default creates an address daily but keeps each such address active for a week, so any case in which Windows would use one IPv4 address, at any given time it will consider seven IPv6 addresses to be active. In addition, virtual machines in data centers amplify address use; one could imagine the address of a virtual machine serving a single user or service to be the counterpart of a locator+identifier in the sense that RFC 1992 uses the terms. So a part of the advice to implementers is to expect a much larger number of active addresses at any given time to be normal.

There are of course ways to simplify that in implementation. In a host/router's neighbor tables, it would make sense to keep a "used" flag. At least for routers (which normally have most of the hosts in a subnet as neighbors most of the time), it is common to periodically ARP/ND each address unicast and cull the table if it fails to respond (rather than simply timing the address out). One could modify that slightly by setting a flag in the neighbor entry when a datagram is sent to the address, and on the periodic sweep culling addresses that were not used and refreshing addresses that have been used.

There is also a place for LRU-style behavior. If the neighbor table is finite in size, keep an LRU list, moving used and new entries to the tail and simply overwriting entries from the front when needed. If there is no hard bound on the neighbor table besides the size of memory, one could imagine sweeping at a rate comparable to its size - every mumble time units culling/refreshing a percentage of the table. 

Where I worry is the concept of a hard limit on address count per MAC address, due to the existence of virtual hosts. Speaking as a vendor of the equipment we're concerned about here, I would rather provide an option that enables the administrator to buy more memory if that's what's needed than force him into a situation that might be suboptimal for his network.

---

From: Fred Baker <[email-masked]>
Date: Sat, 16 Jul 2011 10:41:55 -0700

> the way you deal with this attack is to avoid using RFC-4862 and/or RFC-4861.

I can imagine using DHCPv6 instead of SLAAC (RFC 4862 and the RS/RA component of RFC 4861). The counterpart to ARP is the NS/NA component of RFC 4861; I think you might find that helpful to keep.

That said, I do think you may find SLAAC more scalable than DHCPv6 address allocation. At least that's why it was developed.

---

From: Mark Smith <[email-masked]>
Date: Sun, 17 Jul 2011 11:32:37 +0930

On Sat, 16 Jul 2011 10:38:45 -0700

> > I apologise for being unclear.  The document I was trying to propose in the quoted text above was NOT about protocol changes, but instead would focus on extant mitigations -- so the document I wa…
<snip>
> Where I worry is the concept of a hard limit on address count per MAC address, due to the existence of virtual hosts. Speaking as a vendor of the equipment we're concerned about here, I would rathe…

The quite novel technique of allocation transient addresses to
applications/processes to assist with firewalling also takes advantage
of IPv6's large address space and that hosts can have multiple
addresses at once. It'd be a shame to loose the opportunity to do that
or similar innovative things with the large IPv6 address space -

"Transient addressing for related processes: Improved firewalling by
using IPv6 and multiple addresses per host", Peter M. Gleitz and Steven
M. Bellovin

https://www.cs.columbia.edu/~smb/papers/tarp.pdf

___________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Philip Homburg <[email-masked]>
Date: Sun, 17 Jul 2011 10:53:53 +0200

>or similar innovative things with the large IPv6 address space -

A more scalable approach is to simply route a /96 to the host. There paper
already suggests that:

"If necessary in a given environment, this could be faked by hav-
"ing a host pretend to be a stub router; however, this would require
"the host to participate in routing protocols, which is generally
"considered to be a bad idea. A better solution would be to extend
"NDP to handle host address prefix lengths.

I guess the authors didn't know about DHCPv6 prefix delegation.

I think the same applies to hosts with lots of VMs: maintaining a potentially
large number of NC entries for a single MAC address is unlikely to scale.
This is what routing is designed for.

---

From: Sander Steffann <[email-masked]>
Date: Sun, 17 Jul 2011 13:54:06 +0200

Hi,

> This is what routing is designed for.

Then why are there 64 bits in the IID? And I don't think it has anything to do with the MAC address. 1000 IPv6 addresses on 10 MAC addresses scales as well as 1000 IPv6 addresses on 1000 MAC addresses. It might make a difference for the switch, but not for ND/NC.

- Sander
PS: I consider having the possibility of having a large amount of IPv6 addresses on one interface a great feature, not something I would want to limit.

---

From: Mark Smith <[email-masked]>
Date: Sun, 17 Jul 2011 21:53:20 +0930

On Sun, 17 Jul 2011 13:54:06 +0200

> Then why are there 64 bits in the IID? And I don't think it has anything to do with the MAC address. 1000 IPv6 addresses on 10 MAC addresses scales as well as 1000 IPv6 addresses on 1000 MAC addres…

As people have observed, this is also a problem with IPv4 and ARP with
a large enough subnet, so it isn't unique to IPv6, it's just that the
size of IPv6 subnets is large and therefore it becomes more of an issue.

I think the ultimate root cause is that the creation of neighbor cache
entries is triggered by data plane traffic, rather than created by a
control plane protocol i.e. a neighbor registration protocol. I think
that means that what ever mitigations are put in place, they'll likely
always be fundamentally vulnerable to data plane traffic attacks.

If changing the way ND NS/NAs work is an option, then it might be
better to adopt or use as a model the 6lowpan neighbor registration
protocols, or perhaps review the ES-IS protocol as a model. That is
obviously a large and wholesale change, however I think it would be the
only way to truly eliminate any data plane traffic attacks on neighbor
resolution.

> PS: I consider having the possibility of having a large amount of IPv6 addresses on one interface a great feature, not something I would want to limit.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sun, 17 Jul 2011 22:48:40 +0930

On Sun, 17 Jul 2011 21:53:20 +0930

> only way to truly eliminate any data plane traffic attacks on neighbor

Actually, that level of change might not be that necessary. If the
destination address for the Duplicate Address Detection probes was
changed to the all-nodes rather than the solicited nodes multicast
address, then all receving nodes could immediately create a neighbor
cache entry for the new device if one doesn't already exist. From that
point on, Neighbor Unreachability Detection would then take care of
maintaining the neighbor cache entry, and deleting it if the host
disappears. 

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

---

From: Philip Homburg <[email-masked]>
Date: Sun, 17 Jul 2011 15:34:38 +0200

>always be fundamentally vulnerable to data plane traffic attacks.

I don't think that is true. But that is for later.

>only way to truly eliminate any data plane traffic attacks on neighbor

I think we should just put the various design options on the table. See how
they work, how many changes they require etc.

But before that, the question now on the table is whether v6ops wants to spend
more time figuring out what can be done with the current standards and/or
what guidance they can give for new options.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 17 Jul 2011 15:37:00 +0200

>maintaining the neighbor cache entry, and deleting it if the host

And then a router reboots. How does it find out about all the nodes already
there?

---

From: Mark Smith <[email-masked]>
Date: Sun, 17 Jul 2011 23:41:05 +0930

On Sun, 17 Jul 2011 15:37:00 +0200

> And then a router reboots. How does it find out about all the nodes already

Good point, there would need to be a message to solicit addresses. An
NS to the all nodes address with an unspecified (::) target address
perhaps.

So perhaps the changes required would be mostly limited to -

- DADs to all-nodes rather than solicited node addresses
- nodes receiving the DAD use that to create a neighbor cache entry
- NUD takes care of maintaining the validity of those entries
- ND NS to all nodes with an unspecified target address solicits NAs
  from all nodes to cover the router (or any device) reboot situation

Anycast addresses would be an issue because DAD isn't performed by
them. Perhaps a special "DAD" could be performed for them which causes
the receiving devices to record their presence, but a normal NS/NA
transaction for the anycast address is triggered if the anycast address
is attempted to be used and hasn't been fully resolved.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 17 Jul 2011 16:57:06 +0200

[I dropped v6ops]

>  from all nodes to cover the router (or any device) reboot situation

So my proposal would be to add an option to RA. This option specifies a time
over which nodes should distrubute updating the router (random number between
zero and the timeout). At the selected time, the node then starts NUD on 
the router. Note that it has to do that for all of its addresses. Which is
not part of ND at the moment.

This should be enough. When a node boots it sends an RS. When a node adds a
new address (not triggered by an RA) it may need to go over its list of
routers and update them.

Routers can always add the option to their RAs. But an alternative is to do
that only when they become overloaded.

---

From: Christian Huitema <[email-masked]>
Date: Sun, 17 Jul 2011 16:09:29 +0000

>  from all nodes to cover the router (or any device) reboot situation

I am not sure this addresses the problem too well. The DOS issue manifests itself at the gateway, and the main issue is the remote DOS: attacker sends packets to a very large number of putative IPv6 addresses in the subnet managed by the local gateway, causing the size of the neighbor cache to explode. If we want to protect the cache in the gateway, let's do that. The solution has to be a tweak in the implementation of ND in the gateway, along the lines of:

- Upon arrival of a packet from the local network:
- If the source address is already in ND cache, keep it there
- if the source address is not already in the ND cache:
	Perform some quota check on the source MAC address,
	If the quota is exceeded, drop the packet to protect against local DOS
	If the quota is not exceeded, perform ND for the source address

- Upon arrival of a packet bound to the local subnet
- If the destination address is already in ND cache, route the packet;
- If the destination address is not in ND cache:
	If the table is "too full," drop the packet
	Else, perform ND

The basic idea is that remote parties should only be sending to addresses that have already been discovered in the local subnet. This is, in a way, a weak form of stateful filtering. It needs to be implemented softly, because routers/gateways sometime lose their memory, so we want to allow for some dynamic learning if the tables are not already populated.

The proposed tweaks amount to making ND learn faster. They are fine in general, but they have the side effect of making local DOS easier. A local attacker could generate a large number of addresses, etc.

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Sun, 17 Jul 2011 12:49:16 -0400

> The proposed tweaks amount to making ND learn faster. They are fine in general, but they have the side effect of making local DOS easier. A local attacker could generate a large number of addresses…

As a defense against remote attack, I'm thinking that routers should limit the percentage of their ND caches that are associated with nonexistent hosts.  I suspect there are circumstances when it makes sense to have "passive" hosts, perhaps even large numbers of them, which the local router isn't aware of until traffic from outside arrives for them.   

It might also make sense to rate-limit ND messages sent as a result of inbound traffic - if this rate of such ND messages exceeds a certain threshold,  drop incoming packets for hosts not in the ND cache at random.

Regarding local attack, I doubt that the right thing to do is for routers to give preference to addresses already in the ND cache.  It seems like that would just invite DoS attack, by having the attacking host flood the router's ND cache at regular intervals (especially if the ND cache entry timeout were a constant).   A better idea might be for routers to give preference to addresses that are actually being used to exchange traffic.  That might mean associating a count or timestamp with each ND cache entry.  (which admittedly can introduce its own set of issues under certain conditions).

And I wonder whether ND cache entries should have a "half-life" rather than a strict timeout.

That still leaves the possibility of an attack where a local host generates large numbers of addresses, and actually uses each of them to exchange traffic with a remote host.  As long as hosts can easily and quickly change their interfaces' MAC addresses, I don't see an easy way to deal with that.... though perhaps platforms could rate-limit the ability of applications to do that.

Keith

---

From: Sander Steffann <[email-masked]>
Date: Sun, 17 Jul 2011 20:41:54 +0200

Hi,

> It might also make sense to rate-limit ND messages sent as a result of inbound traffic - if this rate of such ND messages exceeds a certain threshold,  drop incoming packets for hosts not in the ND…

It might be a good idea to increase the timers on the hosts that are in the cache, or to start refreshing those cache entries actively before they run out. In such a situation we might want to keep the pool of verified existing hosts as large as possible to keep the dropping of good packets to a minimum.

Sander

---

From: Daniel Roesen <[email-masked]>
Date: Sun, 17 Jul 2011 20:56:19 +0200

On Sun, Jul 17, 2011 at 04:09:29PM +0000, Christian Huitema wrote:
> The basic idea is that remote parties should only be sending to
> addresses that have already been discovered in the local subnet.

Breaks with any VRRP setup.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: Christian Huitema <[email-masked]>
Date: Sun, 17 Jul 2011 20:14:56 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Roesen

VRPP is probably a special case of a router losing its memory... 

In any case, as Ray Hunter noted, you need to somehow "tell good from bad" if you want to filter effectively. My suggestion is that an address from which traffic has been sourced locally is more likely to be "good" than an address that appears for the first time in a packet coming from afar. This is effectively the property used by most stateful firewalls, so there is some operational experience with that. 

There are indeed a few issues, e.g. the local server who expects remote TCP connections but remains otherwise silent, or the router that was just rebooted, or swapped in, and has no idea about the current working set. The solution to the server issue has to be some kind of keep-alive, e.g. with ND. The solution to the "router with no memory" is probably a looser control during a "learning" period, possibly combined with some form of fast ND refresh.

Of course, there are no good solutions against a local host who is actively trying to DOS a local router. Keith pointed out that local hosts can generate as many MAC addresses as they want... But then, there are meatspace solutions to this kind of things.

-- Christian Huitema

---

From: Mark Smith <[email-masked]>
Date: Mon, 18 Jul 2011 09:01:16 +0930

Hi Christian,

On Sun, 17 Jul 2011 16:09:29 +0000
Christian Huitema <[email-masked]> wrote:

> I am not sure this addresses the problem too well. The DOS issue manifests itself at the gateway, and the main issue is the remote DOS: attacker sends packets to a very large number of putative IPv6 addresses in the subnet managed by the local gateway, causing the size of the neighbor cache to explode. If we want to protect the cache in the gateway, let's do that.

I agree the attack is most likely going to be aimed at a remote router,
however I've also realised that a local host cache may also be a
target on a multi-user host. With virtualisation and (groan) "cloud
computing", these are becoming more common again.

> The solution has to be a tweak in the implementation of ND in the
> The proposed tweaks amount to making ND learn faster. They are fine in general, but they have the side effect of making local DOS easier. A local attacker could generate a large number of addresses…

True, it is vulnerable to a local DoS, although I think thats much
better than a remote DoS, because I think local attackers have more
of a vested interest in the router being available, and local segments
are fairly commonly controlled. In SP environments, there are a lot of
spoofing related attacks e.g. RAs, so the measures that SPs put in
place to sanitise their customers' traffic tends to mitigate these
local DoS attacks.

I definitely see addressing the remote DoS to be the main priority. If
the solutions to that can also help mitigate some of the local DoS
methods that's all the better, however I think they're less of a
threat, and ones we've already had experience with because similar ones
exist in IPv4.

Regards,
Mark.

---

From: Fred Baker <[email-masked]>
Date: Sun, 17 Jul 2011 16:44:46 -0700

> This is what routing is designed for.

One issue to think about has to do with virtual machines. If I have one physical platform that appears to the network to be many virtual platforms, I would likely want to give it many IPv6 addresses. In a cloud computing environment, if I move a virtual machine from one platform to another, I would like to move the address and its routing, by changing the MAC address associated with the IPv6 address. Forcing a /96 here would limit my options - to change the routing, I would be forced to change the address, which is something in a cloud computing environment that I don't want to do.

I could imagine a mix of the proposals, though. I could imagine using a /80 for a rack or a /96 per platform for virtual machines that reside there, with a smattering of /128s within the data center for virtual machines that have moved - and if there was a long term movement, I could imagine renumbering the machine by adding a new address to it in its new /96, changing the DNS name, waiting an appropriate interval, and then removing the old address's /128 from routing and from the virtual machine.

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 17 Jul 2011 17:54:09 -0700

> One issue to think about has to do with virtual machines. If I have one physical platform that appears to the network to be many virtual platforms, I would likely want to give it many IPv6 addresse…

Practically speaking you can also achieve the host mobility that large layer-2's achieve through an l3 mobility approach. eg. the host uses an igp to advertise it's availability (that is, the nexthop for a prefix which it has bound to it) within the datacenter... This (could) reduce the visibility of the subnet to which the host is attached. (it doesn't have to be externally reachable for example, host address assignments may be independent of local topology etc. I can't say I've done it with end systems but we do do a similar thing with load balancers (which are linux boxes running bgp), where they are ebgp peered with the DC border using a private AS and you you can take a load-balancer or prefix out of service or move it by withdrawing the prefix on one load balancer or advertise it on another.

vmware vmotion for example is happy to work across layer-3 networks, the hosts however need intervention when their numbering changes.

> I could imagine a mix of the proposals, though. I could imagine using a /80 for a rack or a /96 per platform for virtual machines that reside there, with a smattering of /128s within the data cente…

I was mostly interested in solving the problem independently of the subnet size. My assumption is that due to slaac, that I'm going to be using /64 subnets for networks which have hosts on them... while much of the exposed side of a DC probably doesn't rely on slaac and is in fact point-to-point links, places where hosts connect probably are. if the mac address ends up being encoded in the address at any point it seems a little silly to split the difference between /64 and /80, both are trivially big enough to blow up the unpoliced ND cache or dos the routers cpu.

> _______________________________________________
> v6ops mailing list
> [email-masked]

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 18 Jul 2011 09:50:52 -0700

> Then why are there 64 bits in the IID? And I don't think it has anything to do with the MAC address. 1000 IPv6 addresses on 10 MAC addresses scales as well as 1000 IPv6 addresses on 1000 MAC addres…

ieee eui-64 uses 64 bits therefore some interface types (firewire ports for example) have 64 bit mac address. we will eventually run out of 48 bit mac addresses given there are only 16.7 million oui blocks...

---

From: "Frank Bulk" <[email-masked]>
Date: Thu, 28 Jul 2011 20:19:36 -0500

Just like some routers allow one to partition the RIB between v4 and v6
address space, the ND cache could be customizably split between good and
"bad" cache (i.e. 80-20), with the bad operating on a FIFO basis with some
kind of customizable COPS-style rate-limiter attached to that "bad" cache.
This would give the network guy the necessary knobs to manage ND DoS.

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christian Huitema
Sent: Sunday, July 17, 2011 11:09 AM
To: Philip Homburg; Mark Smith
Cc: IPv6 Operations; [email-masked]
Subject: Re: [v6ops] Best venue to begin addressing the "/64 ND DoS"
concerns ?

>  from all nodes to cover the router (or any device) reboot situation

I am not sure this addresses the problem too well. The DOS issue manifests
itself at the gateway, and the main issue is the remote DOS: attacker sends
packets to a very large number of putative IPv6 addresses in the subnet
managed by the local gateway, causing the size of the neighbor cache to
explode. If we want to protect the cache in the gateway, let's do that. The
solution has to be a tweak in the implementation of ND in the gateway, along
the lines of:

	If the quota is exceeded, drop the packet to protect against local
DOS

The basic idea is that remote parties should only be sending to addresses
that have already been discovered in the local subnet. This is, in a way, a
weak form of stateful filtering. It needs to be implemented softly, because
routers/gateways sometime lose their memory, so we want to allow for some
dynamic learning if the tables are not already populated.

The proposed tweaks amount to making ND learn faster. They are fine in
general, but they have the side effect of making local DOS easier. A local
attacker could generate a large number of addresses, etc.

-- Christian Huitema