Suresh - a further comment on using standard stacks. There is a potential problem with using RA as "sign of life": if the node receives an unsolicited RS before it sends an RA, the node will accept that RS and never send an RA. The node waits a random interval between 0 and 1 seconds before sending an RS and the default delay time between unsolicited RSs is 600 seconds (all of these details from RFC 4861). If I have the scenario and details (choosing default values) all correct, that means the node has an average 0.00083 probability (1/1200) of receiving an RS before sending an RA. So, roughly 1 in 1,000 nodes will fail to send an RA and trigger the unicast RAs.
Happy to hear where I'm confused... - Ralph On Aug 26, 2010, at 8:18 PM 8/26/10, Ralph Droms wrote: > Suresh... > > On Aug 26, 2010, at 7:20 PM 8/26/10, Suresh Krishnan wrote: > >> Hi Thomas, >> >> On 10-08-26 08:37 AM, Thomas Narten wrote: >>> I htink Woj is right and raises some fundamental issues. >> >> Yes. And nobody said anything to the contrary. I problem is that the issue >> is orthogonal to the mechanism described in the RS mark draft. Even if >> draft-krishnan-6man-rs-mark was never written, this problem would still >> exist. I have tried to put the issue down in a draft so that we can discuss >> a workable solution. I would appreciate your comments on the draft. >> >> http://www.ietf.org/id/draft-krishnan-6man-rs-lost-00.txt >> >>> 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. >> >> Right. And in this specific scenario routers DO send out periodic multicast >> advertisements as expected. > > But the multicast RAs don't advertise prefixes, right, so the subscriber > nodes won't be able to complete SLAAC? > >>> 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: >> >> I am not sure I agree with you on this one. Again, quoting from scripture >> (Section 6.3.7 of RFC4861): >> >> "Responses to solicited advertisements may contain more information >> than unsolicited advertisements." >> >> seems to indicate that the original ND spec anticipated the possibility that >> the periodic multicast RAs could contain less information that the solicited >> RAs. > > I think the point is to use standard node stacks: Windows 7, OS X, Linux. Do > any of them send periodic RSs? > >>> 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 have to say that such networks are not uncommon and not limited to >> Broadband Forum access networks. e.g. A wireless lan network with multiple >> SSIDs and different vlans upstream to reach the router needs to act in >> exactly the same way in order to keep prefixes separate between the SSIDs. >> >>> 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. >> >> This draft is a request for allocation of a destination option for >> implementing a BBF specific mechanism. It is specifically not a request for >> the IETF to bless the mechanism. The mechanism has been described in the >> draft to provide the background for the usage, as requested by the WG. >> >> The way I see it, without this option, SLAAC-only hosts will be left without >> any way of obtaining an address in these specific deployments. > > But this option isn't all that is needed for the deployment architecture, and > it appears that there is a significant problem with that deployment > architecture. It makes sense to me to hold off on approving this option > until the deployment architecture in which it will be used has been shown to > be deployable. > >> Thanks >> Suresh > > - Ralph > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
