Minutes from MALLOC Working Group

IETF 45, Oslo Norway

Thursday, July 15, 1999

Minutes reported by R. Quinn and S. Hanna.


Agenda Bashing [Hanna]
Introduction & Document Status [Hanna]
Architecture Document Update [Thaler]
Static IPv4 Allocation [Meyer]
Static IPv6 Allocation [Haberman]
MASC Update [Thaler]
MADCAP Update [Hanna]
AAP Discussion [Hanna]

I. Introduction and Document Status

Steve Hanna gave an overview of the MALLOC architecture. Then he provided an update on MALLOC document status:

Most documents should be able to go to IESG by August. AAP will probably be later. MIB will have to wait for AAP.

II. Architecture document update

Dave Thaler described the changes in the latest version of the MALLOC architecture document (draft-ietf-malloc-arch-02.txt). The latest draft is more abstract. It removes focus on specific protocol details (MADCAP, AAP and MASC) and now references roles, which can also apply to alternative proposals (like static allocation). A party that announces addresses available within a domain is now known as a "prefix coordinator" instead of a "MASC server," for instance.

Also, Dave has proposed that "large" scopes (which contain multiple allocation domains) now be called "divisible" and "small" scopes (which have a single allocation domain) now be called "indivisible." This idea was received with mixed emotions.

Dave proposed a 2 week working group last call for this document beginning July 23. There was general agreement.

III. IPv4 Static Allocation

Dave Meyer described the current status of the IPv4 multicast address static allocation method described in draft-ietf-mboned-static-allocation-00.txt.

The IANA just assigned the reserved multicast address range 233/8 for this proposal. These addresses are already being used by many ISPs.

There are many calculators available for converting an AS number into static multicast address assignments and vice versa. See http://gigapop.uoregon.edu/glop

Mark Handley asked how the MALLOC architecture would handle an AS (with a static allocation) that is larger than an allocation domain. It was agreed that you could use MASC or static configuration to break up the static allocation across multiple allocation domains. Mark agreed to help Dave Thaler add this to the Architecture document.

IV. Allocation of Multicast Addresses in IPv6

Brian Haberman described the IPv6 multicast address static allocation scheme described in draft-haberman-malloc-static-ipv6-alloc-00.txt.

An IPv6 multicast address contains a 16 bit prefix (with flags, scope, etc.) and a 112 bit group ID. An IPv6 unicast address contains a 64 bit network prefix and a 64 bit interface ID. The proposal is to statically allocate IPv6 multicast addresses to network prefixes by putting the unicast network prefix at the top of the group ID. This will provide 2^48 groups for each scope, prefix pair.

A concern was raised about how often IPv6 unicast network prefixes might change (due to renumbering). If they change too often, this could cause problems for this scheme. The answer was that each prefix has a lifetime and an orderly transition should be done, with several weeks during which the old prefix is deprecated and the new one preferred. This should be OK.

One open issue is how best to map IPv6 multicast addresses onto Ethernet multicast addresses. RFC 2373 to use only the low 32 bits of the group ID. It would probably be better to include more bits.

Another open issue is which working group this draft should be in. ipng? malloc? This will be discussed with the ADs.

V. MASC Update

This presentation was prepared by Pavlin Radoslavov. However, Pavlin could not attend so Dave Thaler actually gave the presentation.

A new MASC draft was posted today. This draft should be ready for working group Last Call by the end of July and will then be submitted to the IESG for publication as an Experimental RFC.

This draft includes several bug fixes and other changes in light of Pavlin's implementation experience and suggestions from others. Here is a description of some of the most important changes:

Bootup Operation
When a MASC server comes up, it should establish the TCP connection to its parents before its siblings or children. This helps avoid the node learning about its own PREFIX_MANAGED from its siblings or children.
Leaf vs. Non-Leaf MASC Domains
Leaf and non-leaf MASC domains must behave differently. Leaf domains must advertise all addresses to their own allocation domain. Non-leaf domains must save some for themselves and leave others for their children.
Clock Skew Work-around
Clock skew can cause problems with MASC. However, these problems can be avoided. First, timestamps are used to resolve claim collisions. Clock skew may result in one node's claims winning unfairly. But this should be rare and is not a big problem. More problematic is the possibility that clock skew may cause claims to be expired prematurely. To avoid this problem, all claims should be held for an extra 24 hours. And claims with clock skew approaching 24 hours should be rejected with an error.
Security Considerations
When attempting to restore internal state after a reboot, information received from internal peers and parents should be preferred to information received from siblings or children. This prevents siblings or children from providing false state. A denial of service attack (too many collisions) by a single node can be identified by all its siblings, who can ignore that node's claims. A similar attack with multiple origin addresses can be prevented by accepting claims only through the parent.
Sample Algorithms Appendix
Many simulations that have been performed are described.

An open issue was discussed. Currently, siblings with more than one common parent can multiplex all UPDATEs over a single TCP connection. This is too complicated and provides a negligible savings of a few TCP connections. Pavlin suggests opening a new TCP connection for each common pairing. There was general agreement that this sounded like a good idea.

Dave Thaler asked whether separate port numbers would be needed for these connections. He will send email to Pavlin.

MASC Implementation Status

Pavlin has implemented MASC and performed detailed testing, refining, and bug fixing of MASC processing code through simulations. He has also added QUERY/RESPONSE debug messages for debugging. The question arose as to whether these messages should be added to an appendix of the MASC spec. After some discussion, it was agreed that either a MASC MIB should be defined or the messages should be documented.

Pavlin is also working on implementing and testing the MASC-AAP interface. It would be helpful to him if someone who already has a MADCAP/AAP implementation could volunteer to do some testing with him. Nobody came forward.

Deborah Estrin said that Pavlin has lots of experimental and simulation results. He will publish an Internet Draft on these.


Steve Hanna described the current status of MADCAP. draft-ietf-malloc-madcap-04.txt went to the IESG in March. Since then, several rounds of comments have been received from the ADs. Draft -05 was published in May and draft -06 should be published very soon. After that, the spec should go to Proposed Standard status.

The changes in -05 included:

Draft -06 will include minor clarifications. Also, the INFORM message will be renamed to GETINFO.

VII. AAP Discussion

Steve Hanna led a discussion of the AAP protocol. He started off with a protocol overview, then a status update, and finally a discussion of open issues.

AAP is designed to fit into the middle tier in three-tier MALLOC architecture (intradomain). It will be used by prefix coordinators to announce addresses available for allocation and by Multicast Address Allocation Servers (MAAS's) to coordinate and ensure that allocations do not conflict.

All messages are UDP multicast to scope-relative addresses (in the Allocation Scope for "large" scopes, in the scope being allocated from for "small" scopes).

The AAP spec was written by Mark Handley last year. It was based on SAP (the Session Announcement Protocol). Steve Hanna joined as a co-author in March, with high hopes to resolve open issues quickly and move to Last Call by August. However, other things have intervened and little progress has been made as of yet. The last "working draft" has been converted to ASCII and published as draft-ietf-malloc-aap-01.txt in June. Steve is now aiming to for Last Call in December.

The protocol overview has been omitted here. See the protocol specification for details.

The first open issue was whether to add failover support to AAP. In this context, failover means the ability for one MAAS to take over seamlessly if another one fails (able to renew leases issued by the failed MAAS, etc.). Implementing failover would introduce a lot more complexity: sending per-lease information to backup servers, detecting server failure or network partition, backing off to a safe mode, and resynchronizing to recover.

It was generally agreed that we should wait on this for now and just get out a simple AAP spec and get some experience with that. Implementors can use proprietary protocols or other means to address this for now. And we can develop a standard protocol for it later, if need be. This is similar to what the dhc working group did with DHCP.

The second open issue was whether to add support for MADCAP Server Mobility to AAP. We aren't sure how to do this at this point without introducing lots of complexity (like failover). We agreed to think about this for a few weeks. If we can't come up with a reasonably simple solution, we'll punt on it for now.


Dave Thaler talked about the MALLOC MIB (draft-ietf-malloc-mib-01.txt). The initial MIB instrumented generic MAAS and objects. The WG consensus was that protocol-specific objects should be in the same document, so the MIB was updated in June.

It now contains several different conformance groups that different entities will implement depending on which protocols they speak:

The MADCAP-specific groups contain various MADCAP config options as specified in MADCAP spec, as well as counters for each error type and counters for each packet type.

The AAP-specific groups contain various AAP config options as specified in the AAP spec, as well as a write-only private key configuration entry with appropriate precautions, a read-only public key table, and a trap for when you stop hearing ASA messages.

This draft also includes a few other changes. The scope table has been split onto a scope table and an allocation range table to support divisible ("large") scope better. And IPv6 support has been added by making address objects generic.

The MIB should wait for all the protocol specs to go Proposed Standard. This means it will need to wait for AAP. However, the protocol documents don't need to wait for the MIB.

Brian Haberman asked whether this MIB should use the generic object for IPv4/IPv6 address representation in MIBs that is being developed. Dave said that if this object is done soon enough, we'll use it. Otherwise, we will move ahead with the current proposal.


MASC Update