From owner-malloc@catarina.usc.edu Wed Dec 1 10:33:34 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27724 for ; Wed, 1 Dec 1999 10:33:32 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.9.3/8.9.3) id HAA23622 for malloc-list; Wed, 1 Dec 1999 07:04:59 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-malloc@catarina.usc.edu using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id HAA23618 for ; Wed, 1 Dec 1999 07:04:54 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17686 for ; Wed, 1 Dec 1999 07:04:53 -0800 (PST) Received: from sunlabs.East.Sun.COM (sunlabs-74.East.Sun.COM [129.148.74.250]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA04441 for ; Wed, 1 Dec 1999 10:04:50 -0500 (EST) Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id KAA25468 for ; Wed, 1 Dec 1999 10:04:51 -0500 (EST) Message-ID: <384538BF.9DC49E07@sun.com> Date: Wed, 01 Dec 1999 10:03:27 -0500 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: malloc Subject: Draft minutes for MALLOC @ IETF 46 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here is a draft copy of the minutes from the MALLOC meeting at IETF 46. Please get comments to me by Friday morning. Speakers, please submit your slides to the secretariat if they contain significant information not contained in the minutes (or ask me to add it to the minutes). Thanks, Steve ---------------- Minutes of MALLOC Working Group IETF 46 (Washington, DC) Friday, November 12, 1999 Minutes reported by R. Quinn and S. Hanna. Agenda: - Agenda Bashing - Introduction and Document Status - Architecture Updates: Dave Thaler (draft-ietf-malloc-arch-03.txt) - MADCAP Updates: Steve Hanna (draft-ietf-malloc-madcap-07.txt) - MADCAP Scope Nesting Option Updates - Roger Kermode (draft-ietf-malloc-madcap-nest-opt-02.txt) - AAP Updates: Steve Hanna (draft-ietf-malloc-aap-02.txt) - MASC: Dave Thaler for Pavlin Radoslav (draft-ietf-malloc-masc-04.txt) - Zero Configuration Multicast - Dave Thaler (draft-thaler-zeroconf-multicast-00.txt, sent to malloc list) Agenda Bashing Thaler Introduction & Document Status Thaler Architecture Document Update Thaler MADCAP Update Hanna MADCAP Scope Nesting Option Update Kermode AAP Update Hanna MASC Update Thaler Zero Configuration Multicast Thaler I. Introduction and Document Status Dave Thaler gave an overview of document status. - Architecture doc: Recently revised to reflect comments from WG Last Call - MADCAP doc: Approved by IESG for Proposed Standard - AAP doc: In WG Discussion (recently updated) - MASC doc: Recently revised to reflect comments from WG Last Call - Scope Nesting doc: Recently revised to reflect comments from WG Last Call - Abstract API doc: Sent to IESG for Informational - MALLOC MIB doc: Waiting for AAP - Static Allocation: moved out of MALLOC into MBONED A revised version of the IPv6 multicast address static allocation scheme described in draft-haberman-malloc-static-ipv6-alloc-00.txt is expected soon (but this is not a MALLOC work item). Dave also gave an overview of the MALLOC architecture. II. Architecture Document Update Dave described the changes made in the most recent version of the architecture document (draft-ietf-malloc-arch-03.txt) in response to feedback during the WG Last Call. * A definition of "Allocation Scope" was added, with a proposed range of IPv4 admin scoped addresses and an IPv6 SCOP (6). * A Security Considerations section was added. There were no objections to sending the Architecture document directly to the IESG without another WG Last Call. This will be confirmed on the mailing list. III. MADCAP Update Steve Hanna explained that MADCAP (draft-ietf-malloc-madcap-07.txt) has been approved by the IESG for publication as a Proposed Standard. The changes since the last IETF meeting were pretty minor. The most significant one was that the INFORM message type was renamed to GETINFO, since the client uses it to request information from the server, not to inform the server of anything. 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. IV. Multicast Nesting State Option Update Roger Kermode described the changes included in the latest version of the Multicast Nesting State Option document, which was sent to the malloc mailing list on Tuesday (draft-ietf-malloc-madcap-nest-opt-03.txt). 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. V. AAP Update 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. VI. MASC Update This presentation was prepared by Pavlin Radoslavov. However, Pavlin could not attend so Dave Thaler actually gave the presentation. 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 - OPEN and UPDATE messages format modification: domain ID and Node ID lengths depend on AddrFam to get their lengths (to accomodate IPv6) - The "A-bit" (active prefix bit in a claim) was renamed to "D-bit" (deprecated bit) and its polarity was reversed - The "C-bit" (Close connection-bit in a notification message) was renamed to "O-bit" (the "keep connection Open" bit) and its polarity was reversed, to align with BGP and BGMP (to be consistent and allow code reuse). The purpose of this bit is to allow sending a non-fatal error that indicates the TCP connection should remain open. - Authentication code option must include 2 values instead of 3: "The algorithm for computing values of Marker fields" is removed to try to keep this info private (to avoid helping an attacker and because it was unnecessary anyway). - The "QUERY/RESPONSE debug messages" appendix was removed and is going to be put in separate document. 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. MASC Implementation Status Pavlin has posted source code for a MASC implementation at http://netweb.usc.edu/masc/mascd. The next step for this implementation is to update it to reflect the changes in the latest MASC spec. 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. VII. Zero Configuration Multicast Allocation Dave Thaler presented the ideas described in draft-thaler-zeroconf-multicast-00.txt. He gave this talk in the ZeroConf working group meeting, but only focused on the subset relevant to requirements (since that is all they are currently concentrating on there, as of yet). 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. From owner-malloc@catarina.usc.edu Thu Dec 2 07:15:01 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26887 for ; Thu, 2 Dec 1999 07:15:00 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.9.3/8.9.3) id DAA28636 for malloc-list; Thu, 2 Dec 1999 03:55:34 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-malloc@catarina.usc.edu using -f Received: by catarina.usc.edu (8.9.3/8.9.3) id DAA28631 for malloc@catarina.usc.edu; Thu, 2 Dec 1999 03:55:31 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id DAA28598 for ; Thu, 2 Dec 1999 03:53:15 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15691; Thu, 2 Dec 1999 06:53:13 -0500 (EST) Message-Id: <199912021153.GAA15691@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: malloc@catarina.usc.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-malloc-madcap-nest-opt-03.txt Date: Thu, 02 Dec 1999 06:53:13 -0500 Sender: owner-malloc@catarina.usc.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast-Address Allocation Working Group of the IETF. Title : MADCAP Multicast Scope Nesting State Option Author(s) : R. Kermode Filename : draft-ietf-malloc-madcap-nest-opt-03.txt Pages : 13 Date : 01-Dec-99 This document defines a new option to the Multicast Address Dynamic Client Allocation Protocol (MADCAP) to support nested scoping. The new option's purpose is to allow clients to learn which scopes nest inside each other, and hence may be used for expanding scope searches or hierarchical multicast transport. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-madcap-nest-opt-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-malloc-madcap-nest-opt-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-malloc-madcap-nest-opt-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19991201114919.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-madcap-nest-opt-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-madcap-nest-opt-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991201114919.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Fri Dec 3 17:32:40 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22529 for ; Fri, 3 Dec 1999 17:32:39 -0500 (EST) Received: by catarina.usc.edu (8.9.3/8.9.3) id OAA06913 for malloc-list; Fri, 3 Dec 1999 14:04:40 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA06909; Fri, 3 Dec 1999 14:04:30 -0800 (PST) Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id OAA07516; Fri, 3 Dec 1999 14:04:09 -0800 (PST) Message-Id: <199912032204.OAA07516@rumi.usc.edu> To: Steve Hanna cc: malloc Subject: Re: Draft minutes for MALLOC @ IETF 46 In-reply-to: Your message of "Wed, 01 Dec 1999 10:03:27 EST." <384538BF.9DC49E07@sun.com> Date: Fri, 03 Dec 1999 14:04:09 -0800 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk > MASC Implementation Status > 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. Just a clarification. Currently I am using 225.128/9 for the experimental TLD, so this leaves 225.0/9 for other malloc experiments. BTW, the 225/8 block is going to expire this month, so it should be renewed before the end of the year. Pavlin From owner-malloc@catarina.usc.edu Fri Dec 31 00:08:14 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16355 for ; Fri, 31 Dec 1999 00:08:14 -0500 (EST) Received: by catarina.usc.edu (8.9.3/8.9.3) id UAA21534 for malloc-list; Thu, 30 Dec 1999 20:52:05 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-malloc@catarina.usc.edu using -f Received: by catarina.usc.edu (8.9.3/8.9.3) id UAA21529 for malloc@catarina.usc.edu; Thu, 30 Dec 1999 20:52:01 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id MAA20541 for ; Thu, 30 Dec 1999 12:47:55 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05402; Thu, 30 Dec 1999 15:47:51 -0500 (EST) Message-Id: <199912302047.PAA05402@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: malloc@catarina.usc.edu From: The IESG Subject: Document Action: An Abstract API for Multicast Address Allocation to Informational Date: Thu, 30 Dec 1999 15:47:51 -0500 Sender: owner-malloc@catarina.usc.edu Precedence: bulk The IESG has approved the Internet-Draft 'An Abstract API for Multicast Address Allocation' as an Informational RFC. This document is the product of the Multicast-Address Allocation Working Group. The IESG contact persons are Scott Bradner and Vern Paxson.