Subject: [magma] DSL Forum request on IGMP

From: Brian Haberman <[email-masked]>
Date: Fri, 16 Dec 2005 08:16:58 -0500

MAGMA members,
      The chairs received a liaison request from the DSL Forum for some
work they are doing on IGMP.  The first attachment to this e-mail is a 
DSL
Forum document outlining their problem space and possible solution.
The second attachment is a response that has been drafted to that 
proposed
solution.

      We would like to have MAGMA members review and comment on these
documents.  Suggested changes to the response would be appreciated.
The chairs will take comments through 12/30/2005.

Thanks,
Brian & Isidor

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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 16 Dec 2005 21:37:20 +0200 (EET)

On Fri, 16 Dec 2005, Brian Haberman wrote:
> work they are doing on IGMP.  The first attachment to this e-mail is a DSL
> The second attachment is a response that has been drafted to that proposed
> solution.

At least part of these requirements have been described in Section 4 
of draft-ietf-mboned-maccnt-req-02.txt which is currently in WGLC at 
mboned.  They should be pointed towards that document, while also 
encouraging writing their own problem statement.

I'm not sure what exactly suggestion 1 is suggesting, but my personal 
opinions are:

  1) all of those messages are just ones that can already be dealt with 
by silently ignoring such IGMP reports.  I do not see what's so 
special about DSL, so this is a more generic problem (see above).

  2) if you really want to do something on this, you could send 
"ICMP-like" message using UDP (because sending ICMPv4 based on a 
multicast packet is forbidden) which the host should listen to, but 
that would just be blocked by the host firewall so I'm not sure how 
much it'd help.  No need to even register a multicast address for 
this.  If DSL forum needs a quick hack, they can always implement 
this.

...

As a wording nit on the proposed message,

As far as I read the PDF, the DSL forum think that other intermediate 
nodes (not just routers) could also send these messages so:

  "Develop a prototype application that passes these messages from the
  router to the host."

should be reworded s/router/intermediate nodes/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pavlin Radoslavov <[email-masked]>
Date: Fri, 16 Dec 2005 14:25:20 -0800

> The chairs will take comments through 12/30/2005.

A comment about the mechanism design itself:

It is not acceptable that the reason the IGMP join failed (i.e., the
"Information" as called in the I-D) is in text format (the "Notes"
field). This makes it practically impossible for an application to
decode the reason a router rejected an IGMP join and to take some
action.

The reason should be encoded by pre-defined numerical values.
E.g., the BGP NOTIFICATION message format ("Error code, "Error
subcode", "Data") is one possible example.

[Issue #1 listed at the end of the original email also raises a
concern about the text string payload, but for a different reason].

Pavlin

---

From: Beau Williamson <[email-masked]>
Date: Mon, 19 Dec 2005 11:09:02 -0600

Brian, et al,

So why didn't we propose the use of an ICMP message to accomplish this?  I 
know several of us discussed this as a possible feedback to the DSL forum. 
Can you expand on why that would be a good option?

Beau Williamson

---

From: chenwm <[email-masked]>
Date: Tue, 20 Dec 2005 09:21:15 +0800

Hi, all

I think ICMP can fix a lot of problem. But an ICMP message is always an unicast
message, so all other hosts in the same attach network can not receive this message.
This is a little inefficient.

Chen Wumao

---

From: Thomas Morin <[email-masked]>
Date: Tue, 20 Dec 2005 08:59:50 +0100

Hi,

I also believe it may be elegant to imagine an ICMP extension to solve
this issue : 
   * ICMP already plays similar role when used for port/host/net
unreachable (intermediate router "talks" to one endpoint), 
   * ICMP was designed with type/subtype well defined error codes,
   * ICMP is quoting the related packet triggering the "error" and that
may help (we would not necessarily need to define encodings to specify
to which group/source the error relates)
   * there already are API-level interaction related to ICMP messages

Cheers,

-Thomas

---

From: Pekka Savola <[email-masked]>
Date: Tue, 20 Dec 2005 12:57:41 +0200 (EET)

>   * there already are API-level interaction related to ICMP messages

The problem is that RFC1812 says that ICMPv4 errors MUST NOT be sent 
in response to a multicast packet (which is what an IGMP report is).

I see 5 different options:

  0) just ignore this for now.  all of the information (feedback from 
the network) presented so far seems like "nice to have", not 
essential.  As it is, the routers and other equipment are free to 
silently discard the queries if they deem it appropriate e.g., for 
security reasons.

  1) just use ICMP anyway.. this could have issues in achieving IETF 
consensus,

  2) use UDP to communicate essentially the same information as ICMP 
would.

  3) define a new IGMP type/code to convey the information in some form 
(the proposed text string doesn't cut it).  Unfortunately, it seems 
that the existing IGMPv3 Membership Report messages cannot be easily 
augmented to include this.

  4) work at this as part of draft-ietf-mboned-maccnt-req-02.txt which 
have similar reqs.  Possibly develop a separate problem statement.

---

From: Thomas Morin <[email-masked]>
Date: Tue, 20 Dec 2005 12:24:01 +0100

Hi Pekka,

> silently discard the queries if they deem it appropriate e.g., for 

Well, obviously, if the problem is raised, it calls for a solution,
right ?

>   1) just use ICMP anyway.. this could have issues in achieving IETF 

I'm no multicast long gun, but as I understood, there were two
motivations to this restriction:
1) «These rules aim to prevent the broadcast storms that have resulted
      from routers or hosts returning ICMP error messages in response to
      broadcast packets.  For example, a broadcast UDP packet to a non-
      existent port could trigger a flood of ICMP Destination
      Unreachable datagrams from all devices that do not have a client
      for that destination port.»  [RFC1812, 4.3.2.7]
2) Multicast senders not reacting well to IGMP receive on their sockets 
  [ http://www.icir.org/fenner/mcast/icmp.html ]

Maybe we can re-examine section 4.3.2.7 of RFC1812, and analyze if we
could exempt IGMP packets from this restriction (or even just IGMP
received by IGMP Queriers) ? 

I mean: if ICMP is considered a good solution to this need, maybe we can
imagine updating RFC1812 (or RFC2644...) ?

Cheers,

-Thomas