RE: [magma] MLDv2: editorial comments and questions

Erik,

Here is the follow-up with my comments on the rest of the issues...

> Section 6.6.1 and elsewhere talks about "Supress router-side
> processing flag".
> The only motivation and high-level explanation of this flag is
> in appendix B:
>    o The S flag (Suppress Router-Side Processing) is included in queries
>      in order to fix robustness issues.
> It would be useful for understanding if the issue and solution was
> explained in more detail at the higher level. I feel like I'm reading
> uncommented assembly code trying to deduct the programmers intent here!

Sections 4.1.7 and 6.6.1 explain how to handle a query, depending on whether
the S flag is set or not. Then, sections 6.6.3.1 and 6.6.3.2 show how to set
the flag while building a query.

As stated in appendix B, the S flag is necessary "to fix robustness issues".
When a multicast address specific or a multicast address and source specific
query is sent, several retransmissions of the query are scheduled (to assure
robustness). At the first transmission, the flag is clear, and timers are
lowered to LLQT. However, while waiting for the next scheduled queries to be
sent, the router might receive a report that updates the timers (setting the
multicast address timer or the source timers to MALI). The scheduled queries
still have to be sent, in order to assure for example that a non-querier
router keeps its state up to date with the current querier (it might not
receive the first query). Nevertheless, the timers should not be lowered
again to LLQT. Thus, in subsequent queries the S flag is set.

If you think it necessary, we could add such an explanation to the text.

> Section 6.6.2 talks of a "lower IPv6 address". I suspect some more
> detail would be useful - even for a 32 bit quantity we have byte-order
> issues thus how to compare a 128 bit quantity as an integer might
> be subject to different interpretations.

Ok, we could add a phrase.

> Section 6.6.2 reads as the elected querier sends general queries but other
> routers might send other queries. I assume that the elected querier is the
> only node sending queries. Is this correct?

Yes. The text says:
   MLDv2 elects a SINGLE router to be in Querier state per subnet [...]
   When a router receives a query with a lower IPv6 address, it sets the
   Other Querier Present timer to Other Querier Present Timeout and
   CEASES TO SEND QUERIES on the link if it was the previously elected
   querier.
We believed that by saying "ceases to send queries" it would be obvious that
we refer to all kind of queries.

> If so it makes sense to append "as well as other queries." to the last
> sentence in the first paragraph.

The last sentence you refer to is:
   After its Other Querier Present timer expires, it should
   begin sending General Queries.
This is correct, as when the timer expires, the new querier really starts to
send ONLY Geeneral Queries. These are the only queries sent periodically.
All the other queries are sent only in specific cases, as a reponse to
received reports. Thus, when the querier change occurs, only general queries
will be sent.
However, we could append your proposal, if this makes the text clearer.

> The second paragraph in 6.6.2 looks inconsistent with section 7.3.1.
> The former says that the router should automatically switch to
> MLDv1 queries if it hears a v1 query, but the latter talks about
> this being adminstratively assurred. At a minimum this is rather
> confusing.
> What should an implementation do?

6.6.2 says:
   If a router receives an older version query, it MUST use the older
   version of MLD on the link.
This does not say how the transition is done, whether it is automatical, or
administratively assured. On the other hand, it is said that details are
described in chapter 7.
Now section 7.3.1 says:
   If an older version of MLD is present on routers, the querier MUST
   use the lowest version of MLD present on the network.  This must be
   administratively assured; routers that desire to be compatible with
   MLDv1 MUST have a configuration option to act in MLDv1 mode.
Thus, here we state that the transition should be administratively assured,
as we did not succeed to come up with a consistent and correct mechanism to
do it automatically. After discussing the issue on the mailing list, it was
agreed that there's no reasonable scenario in which routers would
periodically pop up and dissappear on a specific link, as it might be the
case for the receivers. Thus, assuring the transition to be done by the
administrator is acceptable. In addition, this would filter out possible
attacks of malicious nodes sending out MLDv1 queries, and trying to switch
the link into MLDv1 mode.

Further down in section 7.3.1 it is stated:
  If a router is not explicitly configured to use MLDv1 and hears an
  MLDv1 General Query, it SHOULD log a warning.
This warning would alert the administrator, who could decide to configure
the MLDv1 mode or not.

However, you might be right saying that the sentence from 6.6.2 might be
confusing. We will try to rephrase it.

> The description of detecting an old router in 7.2.1 seems rather complex
> and hard to read. I understand from section 8 that this is just
> a case of
> 	when an old query is received switch to old mode and (re)start
> 	a timer.
> 	if the timer fires switch to new mode
> but I can't parse that from the text in 7.2.1.
> (I suspect the complexity is a carry over from IGMPv3 which deals with
> 3 versions.) Saying "older" isn't needed - "v1" is more specific in
> the case of MLDv2.
> Same for section 7.3.2.

Ok, we can change "older" by v1. We just wanted to keep the same terminology
for timers as in IGMP, in order to ease a programmer's or a reader's life,
who is already familiar with IGMP. That's why we kept terms like "Older
Version Querier Present Timer" or "Older Version Host Present Timer" instead
of saying "v1 querier present" or "v1 host present"

> Section 9 says that the use of the unspecified source
> address protects against off-link packets.

This is taken out of its context. The entire prase is:
   The requirement that nodes verify that the IPv6 Source Address
   of all received MLD messages is a link-local address (or the
   unspecified address) defends them from acting on forged MLD messages
   originated off-link.
Thus, the necessity to have a link-local address is the thing that protects
against off-link packtes. I agree however, that we should probably treat the
case of the unspecified address in a separate phrase.

> This isn't true since
> there is nothing in any IPv6 specification that says that routers
> MUST NOT forward packets with an unspecified source address.

It is this specific MLDv2 draft that says that. As I said, I agree that
stating this in a separate phrase would probably make things clearer.

> MLD snooping switches might have a
> security issue with off-link unspecified source reports though!)

As far as I see, snooping switches always stand behind an MLDv2 router. If
that router drops off-link unspecified source reports, I do not see how the
snooping switch could receive them.

> Section 1 says:
>    This document specifies Version 2 of MLD.  The previous version of
>    MLD became an Internet Standard and is specified in [RFC 2710].  In
> MLDv1 is a proposed standard and the above can be read as it being
> a standard. How about dropping "became and Internet Standard and"?

Ok.

> Section 3.1:
>    o If the requested filter mode is INCLUDE *and* the requested source
>      list is empty, then the entry corresponding to the requested
>      interface and multicast address is deleted if present.  If no
>      such entry is present, the request is ignored.
> I think "has no effect" is more accurate than "is ignored".
> For instance, some particular API might chose to return an error
> in such a case which doesn't sound like the request would be ignored.
> I don't think this specification should preclude there from being such
> an API.

Ok.

> Section 3.2 mostly talks about the interface state but it also
> has this important note:
>    but not on socket s2. Note that MLDv2 messages are not subject to
>    source filtering and must always be processed by hosts and routers.
> Shouldn't this be specified more visibly somewhere else?

Section 3.2 talks also about source filtering, based on the interface state.
Thus, I think that the phrase you refer to is included in the right place.
However, we could repeat it somewhere else in the text, maybe in the
enlarged introduction that you asked for, if this would make the text more
readable. We just have to be sure not to have an enlarged introduction of
tens of pages :-)

> Section 3.2 continues with
>    Filtering of packets based upon a socket's multicast reception state
>    is a new feature of this service interface.  The previous service
>    interface described no filtering based upon multicast listening
>    state; rather, a Start Listening operation on a socket simply caused
>    the node to start to listen to a multicast address on the given
>    interface, and packets sent to that multicast address could be
>    delivered to all sockets whether they had started to listen or not.
> The above doesn't match reality.
> While filtering based on the socket isn't required by any IETF standard
> (and I think requring it is the new thing) many implementations have
> some form of filtering. In some cases it is simple as in unless
> the socket has issued at least one add_membership type operation
> it will not receive any multicast packets (even if other sockets
> have joined the group). In other cases it might be full-fledged
> filtering of groups per socket.
> A possible fix is to just add "Requiring " before "Filtering of
> packets ...".

I'm OK with that.
But you should agree that we could not ask the reader to be aware of what
kind of undocumented tricks different implementors use in their products.
This is the first spec where this filtering is specified. That was what
motivated our formulation.

> Section 4:
>    link-local IPv6 Source Address (or the unspecified address, if the
>    node has not yet acquired such an address), an IPv6 Hop Limit of 1,
> It is the *interface* and not the *node* that needs to
> have a link-local address assigned.
> s/node/sending interface/
> Same issue in section 4.2.13.

Ok.

> The document seems inconsistent on whether the unspecified address
> can be used for v2 queries, but I think the intent is that
> they only be allowed on v2 reports.

Right.

> If so it makes sense to
> clarify the above sentence and also search for "unspecified"
> and make the other text consistent.

As I already stated in a previous e-mail, we could add a "source address for
queries" section in 4.1. This would clarify the issue.

> Section 4.2.12 says:
>        1    MODE_IS_INCLUDE - indicates that the interface has a filter
>             mode of INCLUDE for the specified multicast address. The
>             Source Address [i] fields in this Multicast Address Record
>             contain the interface's source list for the specified
>             multicast address, if it is non-empty.
> This reads as if MODE_IS_INCLUDE reports are sent even if the
> source address list is empty, but that is not the case AFAICT.
> Thus it makes sense to clarify this to say that MODE_IS_INCLUDE
> is never sent with an empty list.

Ok.

> Section 4.2.12 says:
>    o A "Filter Mode Change Record" is sent by a node whenever a local
>      invocation of IPv6MulticastListen causes a change of the filter
>      mode (i.e., a change from INCLUDE to EXCLUDE, or from EXCLUDE to
>      INCLUDE) of the interface-level state entry for a particular
>      multicast address. The Record is included in a Report sent from the
>      interface on which the change occurred.  The Record Type of a
>      Filter Mode Change Record may be one of the following two values:
> I makes it clear later, but it would be good to add
> "whether or not the source list changes at the same time"
> to the above.

Ok.

> Section 4.2.12 says:
>    Unrecognized Record Type values MUST be silently ignored.
>
> I assume this means more than just ignoring the type field when it
> isn't recognized. The question is whether it means that the
> whole report be ignored, or just the multicast address record
> with the unrecognized type. Which one is it?

Just the specific record should be ignored. We should probably rephrase as
follows:
"Multicast Address Records with an unecognized Record Type value MUST be
silently ignored."

> Section 5 says
>    There are two types of events that trigger MLDv2 protocol actions on
>    an interface:
> Presumably there is a set of timers that, when firing, trigger
> MLD protocol actions as well.
> It would make sense to list those timers here.

All the timers that might fire on an MLDv2 host are set in the first place
when a query is received. Thus, it is the reception of the query that
triggers the protocol action, and not the firing of the timer.

The corresponding protocol action is then described in detail. It includes
setting the timer, and executing a specific operation when the timer fires.

> Changing this means it makes sense to add a section 5.3 about
> interface timer firing and 5.4 about multicast address timer firing.

As I said, all these timers firing are just a part of the processing
triggered by the query reception. And all the corresponding actions are
already described in sections 5.1 and 5.2.

> Section 5:
>    (Received MLD messages of types other than Query are silently
>    ignored, except as required for interoperation with the earlier
>    version of MLD.)
> Replace "earlier version of MLD" with MLDv1 and look
> for other occurances of "version" where the same thing applies.
> (I understand that this type of language makes sense for IGMP
> since there are two earlier versions.)

Ok.

> Section 5.2:
>    When a new Query with the Router Alert option arrives on an
> The "router alert" is checked above.
> Using the expression "valid query" throughout the section captures
> the validity checks at the beginning of the section.

Ok.

> Section 6.2.2 says in the first paragraph
> 	kept per multicast address per attached link.
> but the "per attached link" doesn't appear in section 6.2.3 for the
> source timer which looks confusing.
> It would be better to say
> 	kept per multicast address record.

Ok.

> Section 9.1:
> Change "MLDv2 receivers" to "MLDv2 listeners".

Ok.

> Section 10.
> It would make sense to ask the IANA to assign a *link local
> scope* multicast
> address.
> It would make sense to say ICMPv6 instead of ICMP in this section
> as well.

Ok.

> The specification potentially introduces new name spaces.
> At least the multicast address record type is such a name space.
> It would make sense to state this in the IANA considerations section.
> (I'm Assuming that the assignment of new types be restricted to standards
> action.)

Ok.

> Section A.2 #1 made me believe that routers in this protocol
> would track membership per host which it clearly doesn't do.

it does not say that. It only says, that with MLDv1 it was not possible,
because of host suppression. In MLDv2, it becomes possible.

> And doing it per host doesn't seem to be an improvement.

We did not say that it must be done, but that it can be done. As far as I
know, several router vendors, e.g., Cisco, do implement explicit host
tracking.

> For instance, asking a host whether it wants group X would
> still require a timeout since the listener does not respond to queries
> for groups in which it is not interested.

This spec does not specify explicit host tracking. Nevertheless, if you want
to do that, you can do it without modifying the protocol behavior. All the
reports and the queries are the same. Only that the routers, upon receiving
a report, memorize additional information too (e.g., host address).

> What could be done without host supression is for the router to
> count the number of hosts interested in a particular group
> (at least for include mode - haven't thought about exclude mode)
> which makes it easier for the router to detect when it is likely
> that the last listener has unsubscribed without having to query for
> every leave.

You cannot do that. You cannot count the number of hosts, if you do not
memorize their identity (address), as you cannot make the difference between
a retrannsmitted report (because of robustness) of an already known host,
and the first report of a new host.

But I underline once again that this document does not specify explicit host
tracking. We only said that with MLDv2 it becomes possible, if someone wants
to do it.

> Appendix A.2 #2 seems to have an odd conclusion as the last sentence.
> Since MLDv2 mandates compatibility with MLDv1 and MLDv1 has host
> supression
> Thus I don't see how the snooping switches can be made simpler by removing
> anything at this point in time. In some future date when the v1
> compatibility
> is removed that might be the case.

The fact that we assure the compatibility with MLDv1 does not mean that we
will have MLDv1 hosts or routers in each and every part of the network. If
it would be the case, we would be always in MLDv1 compatibility mode, and
the MLDv2 protocol would never be used at its best.

Therefore, a scenario in which an MLDv2 snooping switch receives indeed an
MLDv2 report does not seem ackward to me. If the processing of this v2
packet is made simpler for the switch, then I think that this is a good
thing.

> A point that is missing is that in the precense of MLD snooping switches
> the utility of host supression is zero.

Ok, we could add a specific phrase saying that.

> That coupled with #3 and #4
> seems to make a strong case for removing host supression.
> But #1 and the current #2 seems weak arguments at best.

As I said, router vendors do implement explicit host tracking, at least in
IPv4. If they do it, I imagine that they have their reasons (fast leave,
security, accounting, whatever...). If this mechanism was made possible by
removing the host suppression, then I think that #1 is quite a strong
argument.

> Appendix B
> Change "65,535 seconds" to either "65,535 milliseconds" or "65 seconds".

Ok.

Thanks,
Rolland

_______________________________________________
magma mailing list
magma@ietf.org
https://www1.ietf.org/mailman/listinfo/magma