[This got stuck in my outbox] > - a time that decrements in real time, > that is, one that will result in a > Lifetime of zero at the specified > time in the future, or > > - a fixed time that stays the same in > consecutive advertisements. > > ==> AFAIK, the first option has not been implemented; I've at least not seen > in done. Therefore unless someone shows that there are two implementations > of this, this must be removed. (The same for AdvPreferredLifetime, and a bit > in section 6.2.7.)
FWIW This is implemented in Solaris 8 and later. I don't know if there is an second independent implementation though. > Note: Implementations can choose to process the on-link aspects of > the prefixes separately from the address autoconfiguration aspects > of the prefixes by, e.g., passing a copy of each valid Router > Advertisement message to both an "on-link" and an "addrconf" > function. Each function can then operate independently on the > prefixes that have the appropriate flag set. > > ==> similar to above, has this been implemented ? Not a as big issue as > above for me, because this is just an implementation note. As you say this is an implementation note. But it also attempts to re-emphasize the fact that the "on-link" and "addrconf" aspects of a prefix information option are completely independent. > 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. > 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 ..." > 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. > 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 > ==> AFAICS, you can remove 'both the Override flag is clear and' here, > because the same result happens if the Override flag is set. No. The "but do not update the entry in any other way" does not apply when the O flag is set, since in that case the recorded link layer address is updated. > 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? > 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. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
