Subject: [magma] IGMPv3 backward compatibility

From: Karen Kimball <[email-masked]>
Date: Fri, 20 Sep 2002 13:57:06 -0700 (PDT)

Hello, all,

I have a concern regarding how to better IGMPv3's backward 
compatibility with prior IGMP versions.

In particular, in section 2.1.1 IGMP Forwarding Rules, we have 
the following statement in sub-section 3:

"The switch that supports IGMP snooping MUST flood all unrecog
nized IGMP messages to all other ports and MUST NOT attempt to
make use of any information beyond the end of the network layer
header.  In particular, messages where any reserved fields in
the IGMP header are non-zero MUST NOT be subject to "normal"
snooping since this could indicate an incompatible change to
the IGMP message format."

It is this last sentence that I disagree with.

The best-practice recommendations for this situation call for
future versions of a protocol to be useable (NOT IGNORED) by 
prior versions of the protocol, and for earlier protocol 
versions not to contaminate future versions.

This could be expressed in the section above as follows:

"In addition, earlier versions of IGMP SHOULD interpret IGMP
fields as defined for their versions and MUST NOT alter these 
fields when forwarding the message. When generating new messages, 
a given IGMP version should set fields to the appropriate values 
for its own version. If any fields are reserved or otherwise 
undefined for a given IGMP version, the fields SHOULD be ignored 
when parsing the message and MUST be set to zeroes when new 
messages are generated by implementations of that IGMP version." 

This allows earlier versions of IGMP to process (not ignore) 
messages that are of a recognized type using only the defined-for-
that-version portions of the message. Later versions may then add
refinement to the message or its use by setting specific values in
the reserved fields, and by _appending_ any additional information
onto the end of the previously-defined end of the IGMP message.

I propose changing the language of 2.1.1 part 3 to reflect this.  
The changed paragraph for Section 2.1.1, part 3, would then read,

3)  The switch that supports IGMP snooping MUST flood all unrecog
    nized IGMP messages to all other ports and MUST NOT attempt to
    make use of any information beyond the end of the network layer
    header. 

    In addition, earlier versions of IGMP SHOULD interpret IGMP
    fields as defined for their versions and MUST NOT alter these
    fields when forwarding the message. When generating new messages,
    a given IGMP version should set fields to the appropriate values
    for its own version. If any fields are reserved or otherwise
    undefined for a given IGMP version, the fields SHOULD be ignored
    when parsing the message and MUST be set to zeroes when new
    messages are generated by implementations of that IGMP version.

In general I would also say that this language, and much of the 
language in this IETF draft document, applies to both switches and 
to any non-Querier routers implementing IGMP. Could we consider 
updating the document to reflect this?

Regards,
	Karen Kimball

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*   Karen Kimball                          * 
*   Hewlett Packard                        *
*   Email: [email-masked]            *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma