Current Meeting Report
Jabber Logs

2.3.10 Multicast & Anycast Group Membership (magma)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 05/30/2002

Bill Fenner <>
Brian Haberman <>
Internet Area Director(s):
Thomas Narten <>
Erik Nordmark <>
Internet Area Advisor:
Erik Nordmark <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: subscribe
Description of Working Group:
Group management protocols are crucial to the operation of multicast within the Internet, and there are some benefits in extending group management protocols to also be able to support anycast. These protocols allow hosts to inform routers of their membership status within groups. This working group will be responsible for developing the functionalities required for group membership reporting and other related actions. This group will also address the initial authentication and access control issues associated with anycast group membership; this is likely to be limited to shared secrets and message authentication codes (MACs) much like current routing protocol security. Other aspects of Anycast, including architecture and routing, are outside the groups scope.

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.

Goals and Milestones:
AUG 01  Submit SSM considerations for IGMPv3 specification as Proposed Standard.
DEC 01  Submit IGMPv3 Interactions with routing protocols document as Informational.
DEC 01  Submit MLDv2 specification as Proposed Standard.
DEC 01  Submit IGMP Snooping Considerations document as Informational.
DEC 01  Submit Extensions to MLD for Anycast as Proposed Standard.
DEC 01  Submit Mixed-version IGMP Proxying as Proposed Standard.
DEC 01  Submit Multicast Source Filtering API as Informational
DEC 01  Submit SSM considerations for MLD specification as Proposed Standard
MAR 02  Submit IGMPv3 MIB as Proposed Standard.
MAR 02  Submit MSNIP for IPv4 specification as Proposed Standard.
MAR 02  Submit MLDv2 MIB as Proposed Standard.
MAR 02  Submit MLD Snooping Considerations document as Informational.
MAR 02  Submit MSNIP for IPv6 specification as Proposed Standard.
MAR 02  Submit MLDv2 Interactions with routing protocols document as Informational.
MAR 02  Submit MLD Proxying specification as Proposed Standard.
  • - draft-ietf-magma-msf-api-03.txt
  • - draft-vida-mld-v2-03.txt
  • - draft-ietf-magma-igmpv3-and-routing-02.txt
  • - draft-ietf-magma-snoop-02.txt
  • - draft-ietf-magma-mrdssm-00.txt
  • - draft-ietf-magma-msnip-00.txt
  • - draft-ietf-magma-rfc2933-update-00.txt
  • Request For Comments:
    RFC3228BCPIANA Considerations for IGMP

    Current Meeting Report

    Multicast & Anycast Group Membership WG Minutes
    Chairs: Bill Fenner (
            Brian Haberman (
    Document status
       - MLDv1 source address selection is in last call - proposed standard
       - MLDv2 specification is at the IESG
       - Source filtering API is awaiting author response to comments
            Dave Thaler - I'll take the action item on that
       - Ready for last call
            MSNIP (experimental) 
            MRD SSM Range Option (proposed standard) 
            Proxy (proposed standard) 
            Snooping (informational) 
            IGMPv3/MLDv2 for SSM (proposed standard) 
       Q. Problems with the MSNIP spec - I tried to understand the design 
    rational for the host state.  If you have 2 or more router, the host state 
    information is router based, so you have to double or triple your 
          And what if there is no router but lots of hosts - the state 
    information could be used by lots of hosts?
       Audience - How many hosts would be a problem - a million ? How much 
    state is really kept? What's the problem - the computation or the 
       A second concern - the scenario is SSM based - what about proxy based?
       If you want to run MSNIP on a proxy, this is not addressed. IGMP does not 
    have receiver subscription information.
       Answer - This is not an MSNIP issue, but a proxying issue.  The proxy 
    will be responsible for proxying MSNIP information.
    Charter update
         Originally, wanted to do v4 first, v6 afterwards.  Now, given the 
    speed of developments, the chairs cajoled the authors to include v6 as 
         The only issue is the IGMPv3/MLDv2 MIB - whether these 
    can/should be combined.
         Bill Fenner - there are benefits both ways. If separate, each can be 
    extensions of the existing MIBs. If together, then the old managers would 
    not be able to get any information from the new MIBs.
         Brian Haberman - Also the names of the variables and the 
    granularity of time variables would be different.
         Dave Thaler - There are other changes to the MIBs that are ongoing so it 
    may make more sense to combine them.
         Bill Fenner - I agree that neither the naming or the 
    granularity is a show stopper. It just has to be taken care of.
    Snooping draft
         Need a baseline of what to do - this is a strictly 
    informational document.
         the 6th version of the draft is answers to open issues etc. from 
    switch vendors.
         ready for last call.
         Beau Williamson - when you have a conflict between include and 
    exclude draft says the first person "rules" - whereas IGMPv3 says, 
    includes override.
         Bill Fenner - This sounds wrong.
         Audience member - What happens to snooping switches when we upgrade 
    IGMP or MLD?
         Brian Haberman - There is some sentiment in the MBONE working group 
    that snooping is not aa good idea.
         Audience member - Yes, we should document this stuff but say that 
    snooping is not a good idea.
         How it works:
            - Receiver sends igmp/ mld as normal.
            - Router sends a MCOP validate message to a MCA with a 
            - Once it is validated, a verify message is sent back and the join 
    can go as normal.
         This may be implemented over Diameter once this is published.
         Receivers should use RFC3122 inverse NDP to find out global scope 
    address of the client when used with MLD.
         Open issues:
            - How is the client informed that access is denied?
              Could use ICMP "administratively prohibited" messages but these 
    are supposed to have TTL-1. Should this be changed ?
         Next steps:
            - Finalize implementation
            - MCA+database protocol
         Want to publish as experimental.
         Dave Thaler - didn't talk about what the actual threat model is
         The threat model is something like the Ramen worm.
         Beau Williamson - I am constantly getting requests from network 
    administrators to limit the groups or the number of groups that users are 
    allowed to join or send.
         Dave Thaler - What do you when the MCA doesn't know anything about the 
    group accept or deny?
         Answer - We could do either as a policy issue - it's policy not 
         Dave Thaler - Why can't you use an existing protocol?
         Also, is the right WG for this?
         Daniel Senie - I think that some means of access control is needed.
         Whether this is the right one is another question.  Also, I am not 
    convinced that the clients IP address will be enough for an 
         Beau Williamson - I would like to see something like this move 
    forward - it is desperately needed.  However, at the very least the 
    authentication needs to move beyond IP address, and there needs to be more on 
    rate limiting.
         Brian Haberman - If you get these addresses dynamically (e.g. DHCP), 
    then you should have a token, which you could pass to the 
    authenticating router.
         There is not a clear definition of the threat model.  
    Authentication is not in our charter, and this model may or may not 
    involve IGMP/MLD.
         Let's first figure out the problem and then figure out the 
         IGMP for user Authentication Protocol
            - ISP/NSP connection to Internet
            - A CDN both attached to edge router
         IP Multicast in CDP
            - Successful services need
              - access control
              - limit to intra domain multicast to avoid interprovider issues
              - collaborations between content providers and network 
         At present
            - No user access control
            - no user usage information mechanism
            - multicast content security is being developed, but does not 
    provide all needed functionality.
         IGAP adds a protocol framework to transport user information to IGMP 
    enables providers to
            - enforce access control by a group
            - collect per user usage information
         IGAP is only used between edge router and end user.
         Initial IGAP is based on IGMPv2
         Edge router connects to a AAA server
         Request to make this a WG draft
         Marshall Eubanks - why does IGAP need a modification to the 
    user/edge router interaction?
         Answer - User authentication is based on more than the User IP 
         Toerless Eckart - I do not think that the working group should 
    accept any draft based on IGMPv2, unless it is historical only.
         Audience member - This seems strong as it implies as IGMPv2 is 
    harmful, and any way IGMPv3 is still in draft status.
         Response - No, IGMPv3 is an RFC.
         Beau Williamson - This is effectively IGMPv4, and the chances of 
    getting it deployed is very low. And what happens when a user sends IGMP 
    instead of IGAP?
         Brian Haberman - This is not really a network layer 
    functionality - it has been done before at a higher layer in unicast, and 
    that would be appropriate here.
         Audience - This is a piggy back protocol. IGMP happens to be a 
    protocol to register interest, and we have seen elsewhere in the IETF 
    attempts to use this functionality to do other things just because it 
         Toerless Eckart - Multicast is different, as you can be sent 
    traffic that you cannot use.
         Audience member - And I do not see any attempts to synchronize all of 
    these proposals.
         Thomas Hardjono - I think we need a requirements document and also 
    need to worry about layers - some of this stuff should not be done at the 
    transport layers.
    Non IGMP Specific Authentication
         General Internet case
            - Receiver node gets a group key from the group key server
            - hop by hop transmission between all the ISP's in the chain.
            - Why hop by hop - because you can only assume a security 
    relationship between neighboring ISP's
         In general, there is no security relationship between a user and the 
         General Case needs:
            - An ISP needs to
               - do some sort of accounting per client
               - needs to use ACL's, for ingress filtering, say.
         Content provider needs to control who views the content
         These goals are not multicast specific
         One solution:
            - When the receiver "connects" you can place ACL's based on 
    relationship at connect time.
            - You can secure hop by hop messages in the same fashion.
         Port ACL's can change over time.
         Per group security and keys can be done between apps and group key 
    servers; also data can be encrypted.
         Protecting bandwidth
            - You can charge the users
            - The _same_ problem exists with unicast data and is not solved 
            - If the receiver and content provider are on the same network, the 
              authorizer can cause the ACL to be updated
            - Group specific security in IGMP is not reasonable
            - Other solutions appear to solve this general case
            - No Need to change IGMP/MLD
         Audience - I would argue that having a full mesh security solution 
    does more for you than the existing piecemeal solutions.
         Dave Thaler - In the general case you do not have a full mesh 
    security solution because ISP's do _not_ trust one another.
         Toerless Eckart - There should be some message back to the 
    receiver if access is denied.
         Greg Shepard - People lining up expectations of multicast so that 
    nothing gets deployed is a problem. However, the problem is not 
    multicast but UDP.
         Audience member - What we want to do is to control access.
         Dave Thaler - there are two people who have an interest - the 
    content provider and the network operator. The content provider should 
    authenticate and encrypt, the network operator cares about bandwidth and 
    therefore can apply "ACL's" (in a generic sense - they might be port 
    filters, source filters, etc.). These are different problems.
         Beau Williamson - The IGAP protocol may solve the multicast UDP 
    problem, but not the unicast UDP problem, so this does not solve the 
    general problem.
         Tom Pusateri - If we have a general solution to the general 
    problem, why do we need a specific solution to a subset of the general 
         IGAP presenter - What is the specific solution for the special case 
    where the content provider and the receiver are on the same network ?
         Toerless Eckart - Do you mean that there will never be a need for this ?
         Dave Thaler - I never would say never. I am just saying that I do not 
    see it right now.
         Audience member - Two solutions from an ISP point of view
            - we pay for each bit that passes from another ISP - BAD
            - or, encryption.
         Brian Haberman - Before we get out of hand, we need to see what the 
    requirements are.  People interested in working on this problem should 
    collaborate on THAT draft and then we can assess where the work 


    Multicast Control Protocol
    Non-IGMP-Specific Security
    Considerations for IGMP and MLD Snooping Switches
    IGMP for user Authentication Protocol