2.7.8 Multicast-Address Allocation (malloc)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 18-Feb-00


Steve Hanna <steve.hanna@sun.com>
Dave Thaler <dthaler@microsoft.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>

Transport Area Advisor:

Vern Paxson <vern@aciri.org>

Technical Advisor(s):

Thomas Narten <narten@raleigh.ibm.com>

Mailing Lists:

General Discussion:malloc@catarina.usc.edu
To Subscribe: malloc-request@catarina.usc.edu
Archive: catarina.usc.edu/pub/multicast/malloc/

Description of Working Group:

Note: This Working Group is co-chartered in the Internet Area.

Multicast address allocation is an essential part of using IP multicast. Multicast addresses are an even more limited resource than unicast addresses, and must be allocated dynamically if they are to satisfy expected demand. To this end, the MALLOC WG will define three protocols which work together to form a global dynamic multicast address allocation mechanism. These protocols will be:

- a "host to Address Allocation Server" protocol used by a host to obtain one or more multicast addresses from an address allocation server within its domain.

- an intra-domain server to server protocol that address allocation servers within the same domain can use to ensure that they do not give out conflicting addresses.

- an inter-domain protocol to provide aggregatable multicast address ranges to domains, which the servers in that domain can then allocate individual multicast addresses out of. This protocol will work in conjunction with the IDMR WG's Border Gateway Multicast Protocol to provide a scalable inter-domain multicast routing solution.

Although mechanisms for enforcing policies for multicast address allocation may be considered, setting any such policies is not within the scope of this WG. Alternative multicast models are also out of scope.

Goals and Milestones:



Report on simulation and implementation efforts with existing protocol proposals. Address any problems in the specifications that were found.



Meet at Orlando IETF. Review and finalize the host-server protocol.



Submit the host-server protocol to the IESG for consideration as a Proposed Standard.



Repost the updated architecture document as a WG Internet-Draft



Repost the MADCAP scope-nesting option document as a WG Internet-Draft



Review and finalize the inter-domain protocol



Submit the abstract API document(s) to the IESG for consideration as Informational.



Submit the inter-domain protocol to the IESG for consideration as Experimental



Submit the architecture document to the IESG for consideration as Informational



Submit the MADCAP scope-nesting option document to the IESG for consideration as Proposed Standard

Mar 00


Review and finalize the intra-domain protocol

Apr 00


Submit the intra-domain protocol to the IESG for consideration as a Proposed Standard.

Apr 00


Submit the MIB for the host-server protocol to the IESG for consideration as a Proposed Standard.

Apr 00


Submit the MIB for the intra-domain protocol to the IESG for consideration as a Proposed Standard.


Request For Comments:







Multicast Address Dynamic Client Allocation Protocol (MADCAP)



An Abstract API for Multicast Address Allocation

Current Meeting Report

Multicast Address Allocation WG (malloc)

Thursday, March 30 at 0900-1130


CHAIRS: Dave Thaler <dthaler@dthaler.microsoft.com>

Steve Hanna <steve.hanna@sun.com>


Agenda Bashing

Introduction and Document Status

Dave Thaler

(5 minutes)

AAP Updates:

Mark Handley

(30 minutes)



Dave Thaler

(10 minutes)


IPv6 Multicast Address Allocation:

Brian Haberman

(5 minutes)



<Discussion on scoped source-specific groups added to end of agenda>


Document Status


Two RFCs were published since the last meeting:

- MADCAP is now RFC 2730 (Proposed Standard)

- Abstract API is now RFC 2771 (Informational)

Three documents were sent to IESG since last meeting:

- Architecure Document (submitted for Informational)

- MADCAP Scope Nesting Option (submitted for Proposed Standard)

- MASC (submitted for Experimental)

Other WG Documents remaining:


- MIB (blocked on AAP)

AAP Updates: Mark Handley



lots of changes in 02

only explanation changes in 03

changes from 02 - 03

- Scaling Analysis (section 6) added: some errors, needs to be revised again

- Reccomendation that hosts use MADCAP instead of AAP if a MADCAP server is available

- Added discussion of allocation conflicts

- Beau Williamson asked: include text on how apps should deal with shifting addresses within a session? E.g. when we have an allocation conflict

- Dave Thaler responded: Not in AAP, this is part of session advertisements, this is something that is explained in the architecture document.

- Added examples (Appendix A)

- Noted reserved port number: 2878

- Removed Appendix D (Unresolved Issues)

recap from 01 - 02


- Originally AAP assumed that could be large numbers of AAP speakers in a domain. e.g. sdr might speak AAP

- this no longer the intent

- can now use simpler algorithm for defending addresses

- use unform random backoff, not exponential random backoff

- aim is for approx 2-10 AAP speakers in a domain, with 1000 being the upper bound

2) Security mechanim

- Use IPSec AH instead of custom authentication

- Currently only use manual keying with a group-shared key

- SMuG is working on group-keying mechanisms for later on

What's next

- 3/00 Currently in WG last Call

- 4/00 Send to IESG, IETF Last Call

- 5/000? IESG approves as Proposed Standard

other docs will be discussed in zeroconf or mboned as approriate

MALLOC MIB Update: Dave Thaler




- defines IPv6Address type

- IPv6-specific MIBs can use this -> draft-ops-endpoint-mib-07.txt

- defines protocol-independent InetAddress type

- should be RFC soon

- protocol-independent MIBs should use this

Changes to the MALLOC MIB

- IPv6 support now uses standard InetAddress types

- Updated MIB Boilerplate text

- Language names now use Language Tag type defined in Multicast MIB

- Added Guid type to identify leases

- Reading key now MUST return empty string (was MAY) (Thanks to Lars Viklund for reviewing this MIB)


- Prefix coordinator config

- Has interval but not ranges to advertise

- Security

- currently has old "public key" objects

IPv6 Multicast Address Allocation: Brian Haberman



presented in IPNG WG


- Simplify IPv6 multicast address allocation

- Aid in debugging IPv6 multicast networks

- Single-source IPv6 multicast

Architecture change proposal

- borrow the idea from GLOP, but include the network prefix of the allocation domain in the mcast address

- can do this as only the bottom 32 bits actually get used


| prefix | len | unicast prefix | group id |


prefix is the multicast prefix to be reserved for this purpose

len is length of unicast prefix

Multicast Debugging

- Who owns the multicast address

- Who allocated the multicast address

Single-Source Multicast

- set "unicast prefix" to 0/0

This doc will been adopted as a WG document by the IPNG WG

IPv6 Multicast Allocation Guidelines: Brian Haberman



- short document that describes guidelines for MAAS's for generating the low 32-bits of multicast addresses so as to avoid layer-2 clashes.

- use pseudo-random address, avoiding group IDs reserved by IANA for the All-hosts, All-routers, etc groups.

- should this be a malloc WG doc?

Thaler: must make explicit assumption that allocation of unicast implies allocation of multicast prefix as well.

There are content provides who would like to use scope to construct borders around countries etc. Is there enough richness there to allow these things?

Thaler: out of scope this WG is about allocation

Haberman: new IAB doc on scoped address architecture

Thaler: current IPv6 draft says that scopes must nest, can't define "arbitrary" ones unless they nest.

Handley: arbitrary scopes are hard to do beacuse they must be convex...you will create black holes

Handley: yes, this should be a malloc WG doc, it should probably be "proposed"

239 vs 232 Discussion


Q: What addresses should be used for IPv4 source-specific, scoped groups?


1) is to take one piece of the 232 range and divide it up for scoping things. Arg is don't do this as it makes advertising and filtering more difficult.

2) is to take a piece of each 239 subrange and make it source-specific. Arg is 239 is set aside as being scopable but not as source-specific. This can expand downwards into 238, though.

3) take 238 and carve it up just like 239, and distribution is the same. So MZAP announcement for (say) 239.192/16 implies that 238.192/16 is a source-specific range with the same distribution scope. This is much closer to the IPv6 proposal discussed earlier, where a single bit in the address can identify (independent of scope) whether the address is source-specific or not.

Casner: just let certain scopes in 239 be used as SSM

Holbrook: if we make the 232 range dynamic, then routers do

become the MZAP servers?

Handley/Casner: we need to keep 232 clean. If we put structure

in then we will run into allocaiton conflicts at scope


Handley: we could use MZAP to indicate SS range within 239,

this would require that ALL routers that could have local hosts

listen to MZAP in this range.

Thaler: If you're running IGMP then you could have local hosts.

The argument for 238 is that routers can filter on all of 238.

Casner: my main concern with 238 is fragmentation

email list: ssm@external.cisco.com


1) Roger Kermode to resubmit MADCAP Nesting State Option Draft

to IESG after incorporating comments from ADs

2) Mark Handley to fix scaling analysis in AAP draft and resubmit

for WG last call

3) Brian Haberman to generate new document for immediate WG last call

4) Dave Thaler to generate new MIB and resubmit for WG last call

Thanks to Roger Kermode for taking minutes.


None received.