A proxy MAY multicast Neighbor Advertisements when its link-layer address changes or when it is configured (by system management or other mechanisms) to proxy for an address. If there are multiple nodes that are providing proxy services for the same set of addresses the proxies SHOULD provide a mechanism that prevents multiple proxies from multicasting advertisements for any one address, in order to reduce the risk of excessive multicast traffic.
==> does anyone implement this SHOULD? Note that this does not give hints how to even go about doing that. If not, remove.
It is an odd "SHOULD" in that it doesn't add a requirement on implemetors of ND, but instead states a requirement on some potential other protocol which uses proxy NAs. But I do think that MIPv6 is an example of this. Even with multiple Home Agents on the same home link, MIPv6 ensures that only one home agent performs proxy ND for a given home address.
Even more reason to remove it from here, unless it has been implemented (I haven't seen it for sure -- doing it robustly is pretty difficult).
Inbound load balancing - Nodes with replicated interfaces may want to load balance the reception of incoming packets across multiple network interfaces on the same link. Such nodes have multiple link-layer addresses assigned to the same interface. For example, a single network driver could represent multiple network interface cards as a single logical interface having multiple link-layer addresses.
Load balancing is handled by allowing routers to omit the source link-layer address from Router Advertisement packets, [...]
==> this is conflicting. The first para discusses generic inbound load balancing, the second load balancing that applies only to routers w/ RAs. How do hosts perform inbound load balancing? Needs text tweaking..
Leaving the first paragraph as is, since it is basically explaining the term, and adding something before the second paragraph that "Neighbor Discovery allows a router to load balance traffic towards itself if the router has multiple MAC addresses by ..."
This does not address the point because Neighbor Discovery allows a _host_ to load balance incoming traffic as well ?
Unlike in IPv4 Router Discovery the Router Advertisement messages do not contain a preference field. The preference field is not needed to handle routers of different "stability"; the Neighbor Unreachability Detection will detect dead routers and switch to a working one.
==> preference has been plugged back, though not for stability reasons. I'd suggest just removing this paragraph.
I'm not sure removing aids in clarity for folks that come from the IPv4 word. In ICMP router discovery, part of the reason for the preference field was to handle routers with different stability, and that reason isn't present here due to NUD. The fact that we've seen a need to introduce preferences for other purposes is separate from that explanation. So perhaps adding a note that preferences can be useful for other purposes with a non-normative reference to the new spec would make sense.
Fine with me.
For instance, a mobile node, using [MIPv6], moving to a new link would need to discover such movement as soon as possible to minimize the amount of packet losses resulting from the change in its topological movement. Router Solicitations provide a useful tool for movement detection in Mobile IPv6 as they allow mobile nodes to determine movement to new links. Hence, if a mobile node received link layer information indicating that movement might have taken place, it MAY send a Router Solicitation immediately, without random delays. The strength of such indications should be assessed by the mobile node's implementation and is outside the scope of this specification.
==> it might not hurt to discuss the potential pitfalls of this approach somewhere. For example, n case the link indications are shaky, or just hints, and there is a significant number of MNs on a link, this could result in an RS storm.
Or at least clearly state the assumption that 1) this is only performed as part of a suspected movement 2) suspected movements are assumed to be uncorrelated between different hosts i.e. we assume that a trainload of wireless laptops wouldn't all detect movement and send a RS at the same time 3) the 2) assumption might not be true in all cases
Works for me.
A router MUST limit the rate at which Redirect messages are sent, in order to limit the bandwidth and processing costs incurred by the Redirect messages when the source does not correctly respond to the Redirects, or the source chooses to ignore unauthenticated Redirect messages. More details on the rate-limiting of ICMP error messages can be found in [ICMPv6].
==> 'or the source chooses to ignore unauthenticated Redirect messages' smells quite a bit from a leftover of IPsec AH times. Reword?
Can't SeND nodes choose to ignore redirects that aren't protected by SeND?
Sure. I was just referring this editorially, that "unauthenticated" is often an overloaded term, referring to IPsec AH..
An example of denial of service attacks is that a node on the link that can send packets with an arbitrary IP source address can both advertise itself as a default router and also send "forged" Router Advertisement messages that immediately time out all other default routers as well as all on-link prefixes.
==> 'on-link' is not accurate. Using these mechanisms, you can't capture _all_ on-link traffic as that goes between the nodes. You can capture that e.g. by advertising more specifics in RAs, with NA/ND spoofing, etc., but the sentence does not seem to be 100% correct.
What's the bug? If there are no on-link prefixes advertised, then the host will send all packets to a default router. So if an attacker sends RAs with a zero valid lifetime for all the prefixes and a zero default router lifetime for all the routers, and advertises itself as a default router, then all packets will be sent to that spoofed router. So I think the text is correct.
That approach is correct, but beacause the "two hour rule" applies to the on-link prefixes, it's not "immediately".
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
