I htink Woj is right and raises some fundamental issues. The RS/RA mechanism *assumes* that routers send out periodic multicast advertisements. Having nodes send out an RS to solicit RAs is a sort of optimization, intended to prod routers into sending out an RA immediately. But the sending of RSes is NOT a fundmental part of RAs.
Once a node has obtained an RA, the basic model assume that a node need not send any additional RSs out. Periodic RAs will supply the info it needs. This is made clear in RFC 4861, which says: Once the host sends a Router Solicitation, and receives a valid Router Advertisement with a non-zero Router Lifetime, the host MUST desist from sending additional solicitations on that interface, until the next time one of the above events occurs. where the "above events" refers to things like the interface restarting, attaching to a link again, etc. In other words, once a node has received RAs, the protocols do not require it to send additional RSs, even if it doesn't recieve RAs. The only reason RSes are there in the first place is to handle restarting nodes, who want to get an RA immediately instead of waiting for the next periodic one. This is not a flaw in ND. This was the intended design in an intended operating environment. What is proposed in Suresh's draft is a configuration that simply doesn't match a normal network. Namely, a single broadcast domain, but RAs tailored to individual clients. I am not yet convinced that the IETF needs to (or should) support such a configuration, as it is clear that even with the proposed option, there are other issues with the target environment. The Edge Router in the draft will be required to send unicast RAs to all individual devices. It will need to maintain sufficient state to do so, even if the Edge router restarts. Replacing the edge router with some other router will cause problems because the new router won't have the missing state, and there is no clear way to rebuild it. What is the BBF solution to this problem? Has it thought this through? A far better solution is for the AN node to have enough of an IP stack on it so that it can source RAs and provide the right information. Just because some "don't want to do this" (for cost or other reasons) doesn't mean we should support it, especially if we don't think the approach will be reliable or robust in practice. We should only bless an approach if we think it can be made to work in practice. Thomas -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
