Minutes reported by R. Quinn and S. Hanna.
Agenda:
Dave Thaler gave an overview of document status.
The next steps are implementation, then interoperability testing and eventually a move to Draft Standard status. Steve mentioned that Microsoft has client and server implementations in Windows 2000 and that he is working on a client implementation in Java.
Steve Casner asked what were the plans for the Java implementation and Steve Hanna said that no solid plans have been established yet. Anyone with strong opinions should contact him.
Typos were fixed. The requirement that the Multicast Nesting State Option appear after the Multicast Scope List option was removed. The INFORM message type was renamed to GETINFO to match the change in the MADCAP spec. Dependencies on MZAP were removed from the text (since you can statically configure scopes or use some other protocol for scope announcements and notification). And the document was restructured.
The next step is to assign a MADCAP option ID for this option and send the document to the IESG for publication as a Proposed Standard. Steve Hanna pointed out that we need to wait for MADCAP to be published as an RFC before this can happen.
Steve Hanna described the changes included in the latest version of the AAP specification (draft-ietf-malloc-aap-02.txt). This was a substantial rewrite of the document.
Support for IPv6 addresses was added. Address ranges are now used, instead of single addresses. IPsec is now used for security. And there is a new message type (ANA). Also several missing sections were filled in.
Steve then described AAP Security in more detail. Authentication of messages is the primary concern. The previous solution was to include a digital signature in each packet, but this would be expensive. The new solution is to use IPSec to authenticate packets. Because IPsec does not currently include support for group key establishment, manual keying will need to be employed for now to establish and maintain a shared group key. However, the Secure Multicast Research Group (SMuG) in the IRTF is working on group key mgmnt and efficient per-sender authentication and it is hoped that this work will make AAP key management simpler in the future.
The choice to use IPSec was the result of discussions on the MALLOC mailing list. Steve asked if the group approved of the use of IPsec and there was a generally positive repsponse from those present in the room (noone was against it, anyway).
Steve described the ANA message type that was added to the latest version of AAP. This message was added because the previous version of the spec required that one MAAS in the domain send periodic ASRP messages reporting on address space utilization, but it didn't provide a way for this MAAS to find out about failed allocations.
A MAAS sends ANA (Address Not Available) when an allocation fails. Other MAAS's make a note of the failure and address range. When any MAAS sends an address space report (ASRP) message to the prefix coordinator, it includes a summary of failed allocations. The ANA message is just sent a few times (not forever).If it is lost, it's not a big deal.
Dave Thaler said that the spec should point out that if you have responsive prefix coordinators, this should be a rare occurance. Normally, you won't have a huge jump in usage, so the allocation coordinator can track and predict usge. Failed allocations should be an exception condition rather than a normal state. Hence, using an ANA is a fall-back mechanism.
Roger Kermode asked if the ANA message could be used to mount a Denial of Service (DoS) attack. Steve said yes, that's one reason why authenticating AAP messages is important.
Steve asked that people read the latest spec and send comments to the MALLOC mailing list ASAP. He plans to put out another version next month and go to WG last call in December 1999. We hope to have the spec approved for publication as a Proposed Standard by spring.
Dave Thaler asked if timer reconsideration (a la SAP) should be done in AAP. Steve said that AAP uses a constant interval between messages, so timer consideration does not apply. Dave pointed out that a constant interval can cause scaling problems. Steve said that this is understood and we do not expect to have lots of AAP speakers in an allocation domain. We do not expect hosts to do AAP, except in highly constrained environments (which have small numbers of hosts anyway). Steve Casner pointed out that in SAP the number of announcements depends on the number of sessions, not the number of servers. Because AAP allows for many addresses to be included in a single AIU message, this does not apply to AAP.
The MASC draft has recently been revised to reflect comments received during working group last call. This draft will eventually be submitted for publication as an Experimental RFC.
Summary of changes
Any objections to submitting this to the IESG for publication as an Experimental RFC? There was some discussion about whether we would want to advance this to Proposed Standard at some later time and how that might be accomplished. But no objections were raised to going to Experimental at this time.
Pavlin has an experimental top level domain (TLD) and is allocating addresses. Feel free to launch your own experimental TLD and start peering with his. In response to a question, Dave clarified that Pavlin is using addresses from 225/8.
A zeroconf environment is one where no configuration is done for any device (e.g. a home network). A configured environment is one where some devices (especially routers and servers) require configuration. Also, the zeroconf working group has restricted its work to environments which contain no more than one router and one gateway (a router leading out of the zeroconf environment).
Dave described the scopes where dynamic allocation of multicast addresses is allowed: node-local, link-local, local, other small scopes, other large scopes, global, and global single-source. Currently, node-local and link-local addresses are only available for dynamic allocation with IPv6 addresses. And global single-source addresses are only supported for IPv4 addresses (in 232/8).
Node-local, link-local, local, global, and global single-source scopes are well-known. That is, they have a well-defined range of reserved addresses that should always be present.
Dave pointed out that there may be a need for administratively scoped single source addresses. Where should these go? In 232/8 or 239/8 or somewhere else? Nobody expressed an opinion, so Dave promised to ask on the list.
The protocols that Dave suggests using to implement zeroconf multicast address allocation are: MADCAP, AAP, and MZAP.
The first service that applications need is scope enumeration: obtaining a list of scopes to allocate from, so they can choose one. Scope enum is NOT required to allocate from a well known scope.
Zeroconf hosts can assume existence of well-known scopes with default names. The hosts SHOULD do a MADCAP scope-enum query and cache answers. Preferably this should be done at startup and periodically thereafter, but it could be done at request time. If no MADCAP responses are received, the host MAY listen for MZAP messages.
A gateway should have the same behavior as a host, in a configured environment. It should also create a local scope boundary between the configured and zeroconf environments and reply to MADCAP scope-enum queries from the zeroconf side.
The second service that applications need is address allocation. Node-local and single source addresses can be allocated instantly, since each node has its own pool of these addresses. Allocation of link local, local, and other "small" addesses should always be available. Allocation of other ("big" and global) addresses should be available whenever possible.
Zeroconf hosts can handle allocation from node-local and single source addresses on their own. Link-local addresses can be allocated using a subset of AAP (what Dave calls "ARPing": choosing an address and sending a multicast claim for it, then using and advertising it if no collision is detected). For local and other "small" addresses, the host should send a MADCAP request first. If that fails, the host can ARP for an address. For global and other "big" scopes, the host should send a MADCAP request. If that fails, no addresses should be allocated from that scope.
Steve Hanna pointed out that there are scaling limits to the ARPing technique. Also, if a zeroconf network is connected to another zeroconf network (or to a configured network), previously allocated addresses may encounter collisions. Thaler said that zeroconf hosts must be able to deal with such situations.
Steve Casner asked how useful link-local allocaton is for hosts? Dave said that it is mainly useful for expanding ring/scope searches and situations where there is a large number of hosts and you want very local scopes.
Zeroconf gateways can act as mini-MAAS's, providing multicast address allocation services to hosts in the zeroconf area. For node-local, link-local, and single source addresses, they won't be involved. For local addresses, they can act as a full MAAS, but then they need to have stable storage. Or they can let hosts ARP, but that doesn't scale well. For other small addresses, they can pass requests to a parent MADCAP server. If that fails, they can act as a full MAAS or let hosts ARP. For global and other large addresses, they must pass requests to a parent MADCAP server.
This is a nice extension to what the MALLOC group has done.
Steve Hanna asked why not let the gateway act as a full MAAS for global and other large addresses. Dave said maybe this is right.
Steve Hanna said this should not require any changes to the MADCAP spec, which is good, but we may need changes to the AAP spec. Dave said it requires an additonal field in AAP, but we wanted to do this anyway.
Steve Casner asked what names should be assigned to scopes when there's no MADCAP server. It was generally agreed that a host can provide reasonable defaults if no information is available. But a zeroconf gateway should provide a way to set the zone name for the Local scope (for instance).
Steve Casner also asked how an application can figure out the semantics of the scopes in the scope list. Dave said that the application could use the scope ID for well-known scopes.