Josh Littlefield pointed out where I was confused - I reversed RS and RA, so my text should have read:
...a further comment on using standard stacks. There is a potential problem with using RS as "sign of life": if the node receives an unsolicited RA before it sends an RS, the node will accept that RA and never send an RS. The node waits a random interval between 0 and 1 seconds before sending an RA and the default delay time between unsolicited RAs 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 RA before sending an RS. So, roughly 1 in 1,000 nodes will fail to send an RS and trigger the unicast RAs. - Ralph On Aug 27, 2010, at 10:28 AM 8/27/10, Ralph Droms wrote: > 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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
