Last Modified: 2004-02-04
The draft names listed below are the starting point for the work in the WG.
MAGMA specifications will include:
- Core IGMPv3/MLDv2 specifications. These specifications will describe the protocol used between hosts and routers to share group membership information. IGMPv3 and MLDv2 build on IGMPv2 and MLDv1 by adding two types of source-specific filtering; "include" (in which the system tells the router exactly which sources it desires) and "exclude" (in which the system tells the router that it does *not* desire a list of sources).
- IGMPv3: The IDMR working group has submitted this for Proposed Standard. MAGMA takes ownership after publication as RFC.
- MLDv2: draft-vida-mld-v2-00.txt
- Multicast Source Filtering API. This specification describes the API used to interact with IGMPv3 and MLDv2 to indicate source filters. - draft-ietf-idmr-msf-api-01.txt
- Host determination of network group membership. In a multicast environment, systems may be interested in learning whether or not there are any group members, in order to save the trouble of sending data that nobody is listening to.
- Multicast Source Notification of Interest Protocol: draft-ietf-idmr-msnip-00
- Multicast forwarding in tree topologies using IGMP/MLD Proxying - Create a single document from: - draft-ietf-idmr-igmp-proxy-00
- draft-he-mixed-igmp-proxy-00
- Source-Specific Multicast (SSM) consideration document. This work will describe the use of IGMPv3/MLDv2 in an SSM environment. - draft-holbrook-idmr-igmpv3-ssm-01.txt
- Considerations for "IGMP snooping" switches (switches that watch IGMP exchanges in order to determine multicast forwarding behavior)
- Multicast Router Discovery: The IDMR working group has submitted this for Proposed Standard. MAGMA takes ownership after publication as RFC. - Snooping Considerations: draft-ietf-idmr-snoop-00.txt
- Group management MIBs - update RFC 2933 for IGMPv3 - update RFC 3019 for MLDv2
- Interaction between IGMP/MLD and routing protocols - draft-ietf-idmr-igmpv3-and-routing-00.txt
- Extensions to MLD supporting anycast group memberships including authentication and access control mechanisms - draft-haberman-ipngwg-host-anycast-00.txt
In addition, this working group will coordinate with other IETF working groups where multicast and anycast group management protocols are utilized as well as coordinating with the Multicast Security WG.
| Done | Submit IGMPv3/MLDv2 Interfactions with Routing Protocols as Informational | |
| Done | Submit IGMP/MLD Proxying Specification as Proposed Standard | |
| Done | Submit IGMP & MLD Snooping Considerations as Informational | |
| Done | Submit SSM considerations for IGMPv3 & MLDv2 as Proposed Standard | |
| Done | Submit Multicast Source Filtering API as Informational | |
| Dec 03 | Submit MSNIP for IPv4 & IPv6 Specification as Proposed Standard | |
| Dec 03 | Submit IGMPv3/MLDv2 MIB as Proposed Standard |
| RFC | Status | Title |
|---|---|---|
| RFC3228 | BCP | IANA Considerations for IGMP |
| RFC3590 | PS | Source Address Selection for the Multicast Listener Discovery (MLD) Protocol |
| RFC3678 | I | Socket Interface Extensions for Multicast Source Filters |
Minutes for IETF 59 MAGMA Working Group meeting taken by Dave Thaler. Chairs: Brian Haberman <brian@innovationslab.net> Isidor Kouvelas <kouvelas@cisco.com> > Multicast & Anycast Group Membership WG (magma) > > Tuesday, March 2 at 1415-1515 > ============================== > > AGENDA: > > 1. Intro & Agenda Bashing chairs 5 minutes > 2. Document Status Haberman 10 minutes router disc newly picked up from IDMR msfapi is now an RFC MGMD MIB updated, will be presented today > - draft-vida-mld-v2-08.txt MLDv2 is at RFC editor queue > - draft-ietf-magma-snoop-10.txt in RFC queue but blocked on refs (MRD, proxy) authors want to update text to make refs informative Haixiang He: question about how to handle multiple routers on different switch ports will send a note to the authors with suggested text fenner: if not simple wording clarification, it will get kicked back to IESG toerless: what is target status? haberman: informational > - draft-ietf-magma-igmpv3-and-routing-05.txt in RFC queue but blocked on normative refs > - draft-ietf-magma-igmp-proxy-04.txt igmpv4-ssm-06 addresses comments from 2nd WG last call ready to advance mrdssm-03 to be obsoleted by draft-holbrook-ssm-scoping-00 not feasible anyway since MRD no longer allows options msnip-04 revision pending. will be simplified to use fixed SSM range per holbrook draft > 3. Group Management MIB Chesterfield 10 minutes > - draft-ietf-magma-mgmd-mib-02.txt > - Goal: status update clarified HostCacheStatus added HostCacheUp fixed various typos interval timers range - what is the right range restriction? thaler: not currently implementable since tables changed and OIDs conflict with IGMP MIB > 4. Multicast Router Discovery Martin 10 minutes > - draft-ietf-magma-mrdisc-00.txt > - Goal: status update went to IESG in June 2003, several issues were raised v6/4 not treated equally option format inconsistent with NDP concern about use of NDP for v6 insufficient security section use of All-Systems causes extra processing on uninterested nodes other problems TLV option format overkill for this application easy DoS attack with old Terminate message Changes in -00: protocol agnostic IGMP for v4, MLD (not NDP) for v6 removed TLV options replaced with fixed Query Interval, Robustness fields TTL/Hop Limit is consistently 1 defined All-Snoopers group Terminate now triggers Solicitation rather than shutdown of forwarding security statement identifies risks and points at SEND after -00: suggestion to add Link Local to draft name specify encoding of Query Interval ala IGMP/MLD validate that src addr is subnet-local for the interface add SEND to informative ref specify which type (informative) for type codes daley: security issues - do you want to secure MLD query? thaler: how do you prevent implosion of solicitations martin: only switches send them, and there's a random delay discussion of TLV options kouvelas: want options, e.g. for MSNIP capable, etc capabilities of multicast router thaler: either don't put TLV encoding in the spec or put some options in the spec so you can use and test it daley: could just define pad option |