Subject: [magma] IGMPv3: Incorrect group membership state expiry on Querier loss

From: "James Lingard" <[email-masked]>
Date: Mon, 25 Apr 2005 16:06:21 +0100

We've been studying the IGMPv3 specification (RFC 3376), and believe that there is a flaw in the mechanism for a multicast router taking over the role of Querier after the previous Querier has gone away.  The new Querier will send a General Query message, prompting all hosts to send Report messages refreshing their membership requirements, but the corresponding state might expire on the router before the host sends the Report.

For simplicity, consider a subnet on which there are two routers, and a single host that has a requirement for (S,G), and use the default configuration values on both routers:
- Robustness Variable of 2
- Query Interval of 125s
- Query Response Interval of 10s
- Group Membership Interval (GMI) of (2 * 125s + 10s) = 260s
- Other Querier Present Interval of (2 * 125s + 0.5 * 10s) = 255s

Suppose that the Querier sends its last General Query at time t=0, causing the other router to set its Other Querier Present timer to expire at t=255, and causing the host to send its Report at a random time in the range t=0..10.  This Report causes both routers to set their Source timer to expire GMI later, that is, t=260..270.

Now suppose that the Querier goes away.  At t=255, the other router becomes the Querier, and sends a General Query message, causing the host to send its Report at a random time in the range t=255..265.  This random range is independent of the previous random range.

Since the (S,G) state will expire at t>=260, allowing the host until t=265 to send the Report means that the state could expire incorrectly.

Is this a known problem?  If so, is there a generally accepted work-around?  For example, when calculating the Max Resp Code to insert into its first General Query after its Other Querier Present timer pops, a router could use slightly less than one half of the old Querier's Query Response Interval.

Thanks,
James.

-- 
James Lingard
Data Connection Ltd (DCL)
http://www.dataconnection.com/

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Brian Haberman <[email-masked]>
Date: Sun, 1 May 2005 08:39:26 -0400

Hi James,
      Sorry for the long delay in responding...

On Apr 25, 2005, at 11:06, James Lingard wrote:

> We've been studying the IGMPv3 specification (RFC 3376), and believe 
> that there is a flaw in the mechanism for a multicast router taking 
> over the role of Querier after the previous Querier has gone away.  
> The new Querier will send a General Query message, prompting all hosts 
> to send Report messages refreshing their membership requirements, but 
> the corresponding state might expire on the router before the host 
> sends the Report.
>
> For simplicity, consider a subnet on which there are two routers, and 
> a single host that has a requirement for (S,G), and use the default 
> configuration values on both routers:
> Suppose that the Querier sends its last General Query at time t=0, 
> causing the other router to set its Other Querier Present timer to 
> expire at t=255, and causing the host to send its Report at a random 
> time in the range t=0..10.  This Report causes both routers to set 
> their Source timer to expire GMI later, that is, t=260..270.
>
> Now suppose that the Querier goes away.  At t=255, the other router 
> becomes the Querier, and sends a General Query message, causing the 
> host to send its Report at a random time in the range t=255..265.  
> This random range is independent of the previous random range.
>
> Since the (S,G) state will expire at t>=260, allowing the host until 
> t=265 to send the Report means that the state could expire 
> incorrectly.
>
> Is this a known problem?  If so, is there a generally accepted 
> work-around?  For example, when calculating the Max Resp Code to 
> insert into its first General Query after its Other Querier Present 
> timer pops, a router could use slightly less than one half of the old 
> Querier's Query Response Interval.

What I have seen in one implementation is that the forwarding state is
not aged out until the Query Response Interval has expired.  In your
example, the second router would send its General Query at t=255, but
would not age out the forwarding state until t=265 (unless a response
is heard).

Regards,
Brian