[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ssm] Document Action: An Overview of Source-SpecificMulticast(SSM) Deployment to Informational
> Ok, so in MLD i need not only start to send MLDv1 reports, i also have to
> have a smaller IP address to win and become the querier ? How much
> does this effectively buy me ?
Maybe I don't understand your question.. but, there is no change about
querier selection. (What is the relation to my last comment?)
> > "A forged Version 1 Query message will put MLDv2 listeners on
> > that link in MLDv1 Host Compatibility Mode. This scenario
> > can be avoided by providing MLDv2 hosts with a configuration
> > option to ignore Version 1 messages completely."
>
> Sure, such configuration options will be all over us and make deployment
> even more complex. You can pretty much figure that only the default
> behaviour will be what 90% of people will have installed.
I prefer to have an option to fix the problem rather than close my
eyes, even though it may make some additional complexity. (But it's
really complex?)
Anyway, in a README file of IGMPv3 imple., I specify as follws:
....
After this static configuration is done, any old IGMP Query
message doesn't affect to change the compatibility mode.
Remember this is useful only when correct upstream router(s)
must be IGMPv3 capable and you want to filter out or ignore
some bogus or unneeded old version's Report and Query messages
transfered by irregular nodes. This configuration affects all
interfaces of the box.
Note that this configuration is not mentioned in a spec and
turned off as the kernel's default value.
I've never said host compat is *always* wrong. But we may need to
bypass this automatic mode change *for some cases*. And at this
moment, I don't have other good idea to bypass it.
Or, do you have another solution to bypass the DoS Jon Zeeff mentioned?
Or, ignoring the problem is good for the deployment?
> > FYI, my IGMPv3/MLDv2 implementations (incl. KAME) support them, anyway.
>
> Is it on by default ?
No.
Thanks.
--
Hitoshi Asaeda
_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm