Re: [pim] RFC 4541 - 224.0.0.*

William Atwood <william.atwood@concordia.ca> Fri, 09 November 2018 03:52 UTC

Return-Path: <william.atwood@concordia.ca>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20BB1292F1 for <pim@ietfa.amsl.com>; Thu, 8 Nov 2018 19:52:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.535
X-Spam-Level:
X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxh2K-kMaR2g for <pim@ietfa.amsl.com>; Thu, 8 Nov 2018 19:52:36 -0800 (PST)
Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5451277BB for <pim@ietf.org>; Thu, 8 Nov 2018 19:52:35 -0800 (PST)
Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209] port 56514) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id wA93qVlY028877; Thu, 8 Nov 2018 22:52:32 -0500
To: Ganesh.ChennimalaiSa@Dell.com
Cc: pim@ietf.org
References: <4228986f516a48a3840838b0c2bb1c6f@BLRX13MDC414.AMER.DELL.COM> <CAHANBtJ17EjjchmzUjbpDrnPYsSp=+smrS4bnv+BEtPjMnViug@mail.gmail.com> <f627989da6c04780b9b8c2acdf793a13@BLRX13MDC414.AMER.DELL.COM> <CAHANBtK-3nnHOoOb6dy6bd=TbZAVoFcnniV10p3u65ooOP0aZg@mail.gmail.com> <e457d33c14b341d988984fd05b9141fc@BLRX13MDC414.AMER.DELL.COM> <7c9f0b68-2c76-5023-b7d1-daa54bd74f16@concordia.ca> <5d5d723a9ac44ef781ea6e75957c4fd1@BLRX13MDC414.AMER.DELL.COM>
From: William Atwood <william.atwood@concordia.ca>
Openpgp: preference=signencrypt
Organization: Concordia University, Montreal
Message-ID: <e58aabb0-0b09-7e1c-2527-dfd2e7213dba@concordia.ca>
Date: Thu, 08 Nov 2018 22:52:33 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <5d5d723a9ac44ef781ea6e75957c4fd1@BLRX13MDC414.AMER.DELL.COM>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2018-11-08 22:52:32 EST
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/Z9YE2g4oDIGWtCvtZTLHza4Ggaw>
Subject: Re: [pim] RFC 4541 - 224.0.0.*
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Nov 2018 03:52:39 -0000

Ganesh,

I am personally not aware of a specific example; my knowledge is
primarily based on work with IGMP/MLD.  However, I believe that worrying
about this is fruitless.  RFC 4541 _requires_ that all packets in this
range be flooded to all ports (except IGMP/MLD, for the reasons
explained below), so whether or not there is anyone listening is not
relevant.

That said, I can certainly see a newly-booted router (or host) wanting
(or needing) to "listen in" for a while (as part of a boot-up sequence);
the rule in RFC 4541 is there to make switched subnets look as much like
an original Ethernet as possible.

I could also see that a host might receive (and act on) an "All Systems
on this Subnet" packet without ever sending one itself.

Concerning "Assigned, but no documentation":  This means that you cannot
find out what the "system" (host/router) will do with the packet, or
whether it will ever send one prior to listening.  The rule in RFC 4541
is designed to make sure that this lack of knowledge does not matter.

I hope that this helps.

  Bill

On 08/11/2018 10:09 PM, Ganesh.ChennimalaiSa@Dell.com wrote:
> Hi Bill,
> 
> Trying to understand passive listeners from a protocol interaction point of view. Is there an example of (2) passive listener case from IANA assigned multicast groups in this range ?
> 
> PS: Thanks for correcting. Sorry, I actually meant "assigned" by "reserved" in my email. 
> 
> regs
> Ganesh
> 
> -----Original Message-----
> From: William Atwood <william.atwood@concordia.ca> 
> Sent: Friday, November 9, 2018 2:03 AM
> To: ChennimalaiSankaran, Ganesh
> Cc: pim@ietf.org
> Subject: Re: [pim] RFC 4541 - 224.0.0.*
> 
> 
> [EXTERNAL EMAIL] 
> Please report any suspicious attachments, links, or requests for sensitive information.
> 
> 
> Hi,
> 
> Three things:
> 
> 1) The "reserved" numbers in the range 224.0.0.x are as yet unassigned.
> No protocol should be using them.  In the future, IANA may be requested
> to make a new assignment in this range; this will normally happen as the
> result of the issuing of an RFC (describing, for example, a new
> protocol).  So one has to assume the same properties in this range as
> for all presently know (i.e., assigned) protocols.
> 
> 2) NO protocol operating in the range 224.0.0.x need ever issue an
> explicit join.  As you quote in your first message, other than IGMP, all
>  switches MUST forward every packet received to every port on the
> switch.  This is _precisely_ because there may be silent listeners on
> that port.
> 
> 3) Concerning IGMP and MLD, I suspect that if you look elsewhere, you
> will find that IGMP v2 packets and MLD v1 packets must be forwarded in
> the same way, but IGMP v3 and MLD v2 packets need not be.  (This is
> because the latest versions of IGMP and MLD have different semantics
> from the previous versions.)
> 
>   Bill
> 
> On 08/11/2018 11:51 AM, Ganesh.ChennimalaiSa@Dell.com wrote:
>> Hi Stig,
>>
>> Going through the IANA registry, I see the below class of protocols 
>> 1. bidirectional protocols such as OSPF, RIPv2 etc
>> 2. protocols used to locate a service such as mDNS etc
>> 3. reserved but usage not known
>>
>> First two are chatty but as you said the response can be a unicast/multicast. Unfortunately, protocols under the third class does not have public documentation.
>>
>> regs
>> Ganesh
>>
>>
>> -----Original Message-----
>> From: Stig Venaas <stig@venaas.com> 
>> Sent: Thursday, November 8, 2018 2:40 PM
>> To: ChennimalaiSankaran, Ganesh
>> Cc: pim@ietf.org
>> Subject: Re: [pim] RFC 4541 - 224.0.0.*
>>
>>
>> [EXTERNAL EMAIL] 
>> Please report any suspicious attachments, links, or requests for sensitive information.
>>
>>
>> Hi
>>
>> OK, I think I understand. Isn't it a problem if a protocol expects to
>> be able to receive before sending though? If you look at
>> https://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml#multicast-addresses-1
>> you will see that there are quite a few different protocols, it is
>> difficult to say how all of them behave. Also, we don't know how
>> future protocols might behave.
>>
>> Also, I hope you aren't assuming that a router/host that wants to
>> receive for a specific group, would be sending messages to the same
>> group address. There could be client-server link-local protocols that
>> don't work that way.
>>
>> Stig
>>
>> On Thu, Nov 8, 2018 at 12:40 AM <Ganesh.ChennimalaiSa@dell.com> wrote:
>>>
>>> Hi Stig,
>>>
>>> I understand the point. My question is: when all protocols are chatty we theoretically can use an alternate mechanism to learn their existence and forward only to group members. For instance OSPF is chatty and OSPF PDUs can be forwarded only within OSPF routers by leveraging its chatty nature. But when we have passive listeners in a link-local group, there is no opportunity for the network to know about the existence of such receivers.
>>>
>>> Do we have passive receivers (or protocols) in this 224.0.0.* range ?
>>>
>>> regs
>>> Ganesh
>>>
>>> -----Original Message-----
>>> From: pim <pim-bounces@ietf.org> On Behalf Of Stig Venaas
>>> Sent: Thursday, November 8, 2018 1:58 PM
>>> To: ChennimalaiSankaran, Ganesh
>>> Cc: pim@ietf.org
>>> Subject: Re: [pim] RFC 4541 - 224.0.0.*
>>>
>>>
>>> [EXTERNAL EMAIL]
>>> Please report any suspicious attachments, links, or requests for sensitive information.
>>>
>>>
>>> Hi
>>>
>>> The problem is that many stacks don't send IGMP reports for link-local
>>> groups, making the assumption that only routers need to know about
>>> membership, and link-local groups are not routed. Hence, you cannot
>>> rely on IGMP to determine which ports have interested receivers.
>>>
>>> Stig
>>>
>>> On Sun, Nov 4, 2018 at 4:55 PM <Ganesh.ChennimalaiSa@dell.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> Looking at RFC4541 and specifically the discussion 2..1.2 (2) on data forwarding rules. It says
>>>>
>>>>
>>>>
>>>> “Packets with a destination IP (DIP) address in the 224.0.0.X range
>>>>
>>>>       which are not IGMP must be forwarded on all ports.”
>>>>
>>>>
>>>>
>>>> As I see, there may not be explicit joins in this range and looking at IANA registry most protocols look chatty.
>>>>
>>>>
>>>>
>>>> Are there any groups with silent listeners that use this range ?
>>>>
>>>>
>>>>
>>>> regs
>>>>
>>>> Ganesh
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> pim mailing list
>>>> pim@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pim
>>>
>>> _______________________________________________
>>> pim mailing list
>>> pim@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pim
>> _______________________________________________
>> pim mailing list
>> pim@ietf.org
>> https://www.ietf.org/mailman/listinfo/pim
>>
> 

-- 

Dr. J.W. Atwood, Eng.             tel:   +1 (514) 848-2424 x3046
Distinguished Professor Emeritus  fax:   +1 (514) 848-2830
Department of Computer Science
   and Software Engineering
Concordia University EV 3.185     email:william.atwood@concordia.ca
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8