From owner-malloc@catarina.usc.edu Mon Oct 4 12:03:59 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04389 for ; Mon, 4 Oct 1999 12:03:59 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA22002 for malloc-list; Mon, 4 Oct 1999 08:19:22 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA21997 for malloc@catarina.usc.edu; Mon, 4 Oct 1999 08:18:57 -0700 Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id DAA21268; Mon, 4 Oct 1999 03:53:37 -0700 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 4 Oct 1999 11:53:16 +0100 To: David Oran cc: maddogs , idmr , idr , msdp , pim , mboned , malloc , rmt Subject: Re: Maestro BoF Results In-reply-to: Your message of "Mon, 02 Aug 1999 11:17:41 EDT." Date: Mon, 04 Oct 1999 11:53:15 +0100 Message-ID: <11012.939034395@cs.ucl.ac.uk> From: Jon Crowcroft Sender: owner-malloc@catarina.usc.edu Precedence: bulk ... ..."One of the conclusions from the BoF was to continue discussions on these subjects to ascertain if there is a critical mass of support to charter one or more Working Groups to pursue IETF standards (or other outputs) in these areas. We are therefore resurrecting a moribund Routing Area mailing list for this purpose: routing-discussion@ietf.org" so whats the conclusion vis-a-vis multicast discussion (considering imminance of next/DC) ietf? cheers jon (apols for multi-list hit, but some folks might have had a peripheral but strong enough interest to want to know the outcome without seeing the process) From owner-malloc@catarina.usc.edu Tue Oct 5 08:57:45 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29470 for ; Tue, 5 Oct 1999 08:57:44 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id FAA29817 for malloc-list; Tue, 5 Oct 1999 05:32:01 -0700 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id FAA29813; Tue, 5 Oct 1999 05:31:57 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.6.9) with ESMTP id FAA22493; Tue, 5 Oct 1999 05:31:25 -0700 (PDT) Message-Id: <199910051231.FAA22493@rumi.usc.edu> To: malloc@catarina.usc.edu Cc: bgmp@catarina.usc.edu Subject: MASC implementation public release + request for alpha testers Date: Tue, 05 Oct 1999 05:31:24 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk The software is available from: ftp://catarina.usc.edu/pub/masc/mascd/ http://netweb.usc.edu/masc/mascd/ It is alpha release, and lacks all desired functionalities (e.g. no AAP and MZAP), but even in this form it can be used for various experiments, tests and evaluations: * mascd : up to date (draft-3) MASC implementation. It has zebra-lib (aka. VTY) interface, which is very useful for remote (telnet-like) configuration and experiments (allocating addresses, modifying timers, etc). * mascsim: the MASC simulator. It shares the same MASC-specific code with mascd, and has proven to be quite useful improving the address allocation algorithms, and discovering various protocol and implementation bugs by creating a number of failure scenarios. A toolkit for running the simulations is included too. I have setup one machine as a Top-Level Domain MASC server, so if you are interested in wide-area experiments, I encourage you as a starting point to peer your TLD MASC server with that machine. More details in the READMEs files. Enjoy, Pavlin P.S. If you are interested in more systematic testing, please let me know, and later I will send you more detailed description of wide-area testing plan and procedures. From owner-malloc@catarina.usc.edu Wed Oct 6 15:00:49 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17335 for ; Wed, 6 Oct 1999 15:00:49 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA09101 for malloc-list; Wed, 6 Oct 1999 11:22:36 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA09094; Wed, 6 Oct 1999 11:22:04 -0700 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00542; Wed, 6 Oct 1999 11:21:44 -0700 (PDT) Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA24199; Wed, 6 Oct 1999 14:21:39 -0400 (EDT) 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 OAA10266; Wed, 6 Oct 1999 14:21:41 -0400 (EDT) Message-ID: <37FB9308.D4D5E077@sun.com> Date: Wed, 06 Oct 1999 14:20:56 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pavlin Ivanov Radoslavov CC: malloc@catarina.usc.edu Subject: Re: AAP draft quick comments References: <199907100621.XAA03779@rumi.usc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Some months ago, you commented on aap-01: > 2) The ASA (Address-Set-Announce) message should have entry with > total number of sets in the message and > 4) All other messages (ACLM, AITU, AIU, ASRP) do not have mask > field. A 'Mask' field and 'Number of Entries' field should be added > to each of those messages. Why do you think that a Number of Entries field should be added? It should be easy to determine the number of entries in any of these messages, using the message length. With respect to the Mask field, I think that this field should only be used in the ASA and ASRP messages. In the ACLM, AITU, and AIU messages, I would like to use a first address-last address format like MZAP and MADCAP use. The latter format can represent any address range, while the former can only represent certain ranges. For instance, the range 239.192.17.27-239.192.17.35 is easy to represent in the first-last format, but hard to represent in the first/mask format. The first/mask format can represent discontiguous address sets more efficiently than the first-last format, but I don't expect that this feature will be used very often in the ACLM, AITU, and AIU messages. I do expect that MAAS's may frequently want to claim ranges that can't be easily represented with the address/mask format. In fact, I think that we might want to consider using the first-last format for the ASA messages, too. There's a conflict between scopes that use MASC, where a discontiguous mask is useful, and scopes where the set of addresses available is configured by an administrator. In the latter case, the address set may not be easily representable using an address/mask representation. For the former, the address/mask representation representation will be more efficient. For instance, a MASC router might want to announce that the addresses starting at a base address of 224.2.0.0 with a mask of 0xfffeff00 are available. That is, addresses 224.2.0.0-224.2.0.255 and 224.3.0.0-224.3.0.255 are available. This is the example from section 4.2.1 of the AAP spec with your suggested modification to use 1 bits in the mask to indicate invariant bits. In another example, a "small" scope may be defined to contain addresses 239.192.17.27-239.192.18.255. This range is a legal admin scope (as far as I can tell) and it can be represented easily in MZAP's first address-last address representation, but it cannot be easily represented using address/mask representation. The address/mask representation would be 239.192.17.27/32, 239.192.17.28/30, 239.192.17.32/27, 239.192.17.64/26, 239.192.17.128/25, 239.192.18.0/24. Now, there may be an unwritten rule that all admin scopes must be representable using a single address/mask pair. But this doesn't completely solve the problem, as you might have a "large" scope of 239.192.16.0-239.192.31.255 that is divided up by a foolish administrator using manual configuration into several allocation domains, which he gives addresses 239.192.16.0-239.192.17.26 and 239.192.17.27-239.192.18.255. Perhaps the best solution is to tell people not to do that. And use address/mask for ASA and first-last for the other messages. -Steve From owner-malloc@catarina.usc.edu Wed Oct 6 16:53:14 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20078 for ; Wed, 6 Oct 1999 16:53:13 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA09786 for malloc-list; Wed, 6 Oct 1999 13:23:06 -0700 Received: from hugo.usc.edu (hugo.usc.edu [128.125.51.40]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA09782; Wed, 6 Oct 1999 13:23:02 -0700 Received: from hugo (localhost [127.0.0.1]) by hugo.usc.edu (8.9.3/8.6.9) with ESMTP id NAA46142; Wed, 6 Oct 1999 13:22:46 -0700 (PDT) Message-Id: <199910062022.NAA46142@hugo.usc.edu> To: Steve Hanna cc: malloc@catarina.usc.edu Subject: Re: AAP draft quick comments In-reply-to: Your message of "Wed, 06 Oct 1999 14:20:56 EDT." <37FB9308.D4D5E077@sun.com> Date: Wed, 06 Oct 1999 13:22:46 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk > > 2) The ASA (Address-Set-Announce) message should have entry with > > total number of sets in the message > > and > > > 4) All other messages (ACLM, AITU, AIU, ASRP) do not have mask > > field. A 'Mask' field and 'Number of Entries' field should be added > > to each of those messages. > > Why do you think that a Number of Entries field should be added? It > should be easy to determine the number of entries in any of these > messages, using the message length. You are right. I just thought that if for some reason the format is changed in the future such that there is something after the the set of addresses, then the above technique cannot be used. > With respect to the Mask field, I think that this field should only be > used in the ASA and ASRP messages. In the ACLM, AITU, and AIU messages, > I would like to use a first address-last address format like MZAP and > MADCAP use. The latter format can represent any address range, while the > former can only represent certain ranges. For instance, the range I agree that the first address-last address format allows more flexibility. However, I didn't see any start/end address fields in any of the messages, just "IPv4 Multicast Address". Am I looking in the wrong version of the draft (the one I have is from the I-D directory in ftp.isi.edu)? > In fact, I think that we might want to consider using the first-last > format for the ASA messages, too. There's a conflict between scopes that > use MASC, where a discontiguous mask is useful, and scopes where the set > of addresses available is configured by an administrator. In the latter > case, the address set may not be easily representable using an > address/mask representation. For the former, the address/mask > representation representation will be more efficient. Agree. Pavlin From owner-malloc@catarina.usc.edu Thu Oct 7 11:32:30 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19054 for ; Thu, 7 Oct 1999 11:32:29 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id HAA13414 for malloc-list; Thu, 7 Oct 1999 07:41:48 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id HAA13410; Thu, 7 Oct 1999 07:41:36 -0700 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07167; Thu, 7 Oct 1999 07:41:22 -0700 (PDT) Received: from sunlabs.East.Sun.COM (sunray-svr.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 KAA24569; Thu, 7 Oct 1999 10:40:52 -0400 (EDT) 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 KAA20715; Thu, 7 Oct 1999 10:40:53 -0400 (EDT) Message-ID: <37FCB0C7.28A83647@sun.com> Date: Thu, 07 Oct 1999 10:40:07 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pavlin Ivanov Radoslavov CC: malloc@catarina.usc.edu Subject: Re: AAP draft quick comments References: <199910062022.NAA46142@hugo.usc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pavlin Ivanov Radoslavov wrote: > > Why do you think that a Number of Entries field should be added? It > > should be easy to determine the number of entries in any of these > > messages, using the message length. > > You are right. I just thought that if for some reason the format is > changed in the future such that there is something after the the set > of addresses, then the above technique cannot be used. That's true. But I'm not sure we want to encourage adding fields to the end of existing messages. It would probably be better to just define new packet types. > > With respect to the Mask field, I think that this field should only be > > used in the ASA and ASRP messages. In the ACLM, AITU, and AIU messages, > > I would like to use a first address-last address format like MZAP and > > MADCAP use. The latter format can represent any address range, while the > > former can only represent certain ranges. For instance, the range > > I agree that the first address-last address format allows more > flexibility. However, I didn't see any start/end address fields in > any of the messages, just "IPv4 Multicast Address". Am I looking in > the wrong version of the draft (the one I have is from the I-D > directory in ftp.isi.edu)? Nope. You're looking at the right version. I'm working on a new version now and I'll be changing the packet format to use first-last format. > > In fact, I think that we might want to consider using the first-last > > format for the ASA messages, too. There's a conflict between scopes that > > use MASC, where a discontiguous mask is useful, and scopes where the set > > of addresses available is configured by an administrator. In the latter > > case, the address set may not be easily representable using an > > address/mask representation. For the former, the address/mask > > representation representation will be more efficient. > > Agree. OK. Thanks, Steve From owner-malloc@catarina.usc.edu Tue Oct 12 11:22:09 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18560 for ; Tue, 12 Oct 1999 11:22:08 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id GAA10693 for malloc-list; Tue, 12 Oct 1999 06:31:14 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id GAA10689 for ; Tue, 12 Oct 1999 06:31:09 -0700 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA14790 for ; Tue, 12 Oct 1999 06:31:07 -0700 (PDT) Received: from sunlabs.East.Sun.COM (sunray-svr.East.Sun.COM [129.148.74.250]) by eastmail1.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA25667 for ; Tue, 12 Oct 1999 09:31:04 -0400 (EDT) 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 JAA22054 for ; Tue, 12 Oct 1999 09:31:05 -0400 (EDT) Message-ID: <380337E7.5BD83E77@sun.com> Date: Tue, 12 Oct 1999 09:30:15 -0400 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: MADCAP to PS! Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Our first RFC! -Steve -------- Original Message -------- From: The IESG Subject: Protocol Action: Multicast Address Dynamic Client Allocation Protocol (MADCAP) to Proposed Standard Date: Tue, 12 Oct 1999 06:46:36 -0400 The IESG has approved the Internet-Draft 'Multicast Address Dynamic Client Allocation Protocol (MADCAP)' as a Proposed Standard. This document is the product of the Multicast-Address Allocation Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. Technical Summary MADCAP is a client/server protocol by which hosts can request multicast addresses for use at a specified time in the future and for a specified duration. Addresses are allocated by a lease mechanism, so the client can later attempt to extend the allocation's lifetime. The protocol is intended for intra-domain use, and assumes that the server has some sort of access to a pool of addresses it can then manage. MADCAP requests and replies are transmitted in UDP datagrams, and requests can be multicast for better flexibility and fault tolerance. Working Group Summary The specification is the result of extensive WG discussion, particularly concerning the degree of compatibility with DHCP, and a number of last-call comments, including adding error codes to the protocol for indicating why a server has rejected a request. There is solid WG consensus for this version of the document. Protocol Quality The specification was reviewed for the IESG by Thomas Narten and Vern Paxson. From owner-malloc@catarina.usc.edu Tue Oct 12 12:23:15 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20275 for ; Tue, 12 Oct 1999 12:23:14 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA11308 for malloc-list; Tue, 12 Oct 1999 08:48:58 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA11303 for malloc@catarina.usc.edu; Tue, 12 Oct 1999 08:48:54 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id DAA10089 for ; Tue, 12 Oct 1999 03:47:41 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08003; Tue, 12 Oct 1999 06:46:37 -0400 (EDT) Message-Id: <199910121046.GAA08003@ietf.org> To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: malloc@catarina.usc.edu From: The IESG Subject: Protocol Action: Multicast Address Dynamic Client Allocation Protocol (MADCAP) to Proposed Standard Date: Tue, 12 Oct 1999 06:46:36 -0400 Sender: owner-malloc@catarina.usc.edu Precedence: bulk The IESG has approved the Internet-Draft 'Multicast Address Dynamic Client Allocation Protocol (MADCAP)' as a Proposed Standard. This document is the product of the Multicast-Address Allocation Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. Technical Summary MADCAP is a client/server protocol by which hosts can request multicast addresses for use at a specified time in the future and for a specified duration. Addresses are allocated by a lease mechanism, so the client can later attempt to extend the allocation's lifetime. The protocol is intended for intra-domain use, and assumes that the server has some sort of access to a pool of addresses it can then manage. MADCAP requests and replies are transmitted in UDP datagrams, and requests can be multicast for better flexibility and fault tolerance. Working Group Summary The specification is the result of extensive WG discussion, particularly concerning the degree of compatibility with DHCP, and a number of last-call comments, including adding error codes to the protocol for indicating why a server has rejected a request. There is solid WG consensus for this version of the document. Protocol Quality The specification was reviewed for the IESG by Thomas Narten and Vern Paxson. From owner-malloc@catarina.usc.edu Tue Oct 12 12:31:16 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20529 for ; Tue, 12 Oct 1999 12:31:14 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA11324 for malloc-list; Tue, 12 Oct 1999 08:52:09 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA11319 for malloc@catarina.usc.edu; Tue, 12 Oct 1999 08:52:05 -0700 Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA11198 for ; Tue, 12 Oct 1999 08:31:34 -0700 Received: from fmsmsx29.FM.INTEL.COM (fmsmsx29.fm.intel.com [132.233.42.29]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.7 1999/10/05 18:05:20 spurcell Exp $) with ESMTP id LAA06580; Tue, 12 Oct 1999 11:32:07 GMT Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0) id <439RNY7N>; Tue, 12 Oct 1999 08:31:31 -0700 Message-ID: <638EC1B28663D211AC3E00A0C96B78A8024130FB@orsmsx40.jf.intel.com> From: "Patel, Baiju V" To: "'Steve Hanna'" , malloc Subject: RE: MADCAP to PS! Date: Tue, 12 Oct 1999 08:24:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-malloc@catarina.usc.edu Precedence: bulk I would like to thank Steve for working through all the details and getting this draft to progress to PS. Baiju ----------------------- Baiju V. Patel Architect IDS Engineering 503 696 8192 -----Original Message----- From: Steve Hanna [mailto:steve.hanna@sun.com] Sent: Tuesday, October 12, 1999 6:30 AM To: malloc Subject: MADCAP to PS! Our first RFC! -Steve -------- Original Message -------- From: The IESG Subject: Protocol Action: Multicast Address Dynamic Client Allocation Protocol (MADCAP) to Proposed Standard Date: Tue, 12 Oct 1999 06:46:36 -0400 The IESG has approved the Internet-Draft 'Multicast Address Dynamic Client Allocation Protocol (MADCAP)' as a Proposed Standard. This document is the product of the Multicast-Address Allocation Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. Technical Summary MADCAP is a client/server protocol by which hosts can request multicast addresses for use at a specified time in the future and for a specified duration. Addresses are allocated by a lease mechanism, so the client can later attempt to extend the allocation's lifetime. The protocol is intended for intra-domain use, and assumes that the server has some sort of access to a pool of addresses it can then manage. MADCAP requests and replies are transmitted in UDP datagrams, and requests can be multicast for better flexibility and fault tolerance. Working Group Summary The specification is the result of extensive WG discussion, particularly concerning the degree of compatibility with DHCP, and a number of last-call comments, including adding error codes to the protocol for indicating why a server has rejected a request. There is solid WG consensus for this version of the document. Protocol Quality The specification was reviewed for the IESG by Thomas Narten and Vern Paxson. From owner-malloc@catarina.usc.edu Tue Oct 12 14:24:41 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23525 for ; Tue, 12 Oct 1999 14:24:40 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA12095 for malloc-list; Tue, 12 Oct 1999 11:01:00 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id LAA12078 for ; Tue, 12 Oct 1999 11:00:41 -0700 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA28262; Tue, 12 Oct 1999 11:00:26 -0700 (PDT) Received: from sunlabs.East.Sun.COM (sunray-svr.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 OAA11983; Tue, 12 Oct 1999 14:00:24 -0400 (EDT) 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 OAA28853; Tue, 12 Oct 1999 14:00:23 -0400 (EDT) Message-ID: <38037705.9171078D@sun.com> Date: Tue, 12 Oct 1999 13:59:33 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Munil Shah (Exchange)" CC: "'Patel, Baiju V'" , malloc Subject: Re: MADCAP to PS! References: <19398D273324D3118A2B0008C7E9A56904A39738@SIT.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Really, guys. It was a team effort and I'm proud to have been part of the team. Thanks and congratulations to all working group members and especially to my co-authors, Munil and Baiju. Now let's wrap up the other six documents before this working group and we can all go home! Until it's time to advance MADCAP to Draft Standard, that is. Thanks, Steve "Munil Shah (Exchange)" wrote: > > Indeed. Congratulations! > > -----Original Message----- > From: Patel, Baiju V [mailto:baiju.v.patel@intel.com] > Sent: Tuesday, October 12, 1999 8:25 AM > To: 'Steve Hanna'; malloc > Subject: RE: MADCAP to PS! > > I would like to thank Steve for working through all the details and getting > this draft to progress to PS. > > Baiju > > ----------------------- > Baiju V. Patel > Architect > IDS Engineering > 503 696 8192 > > -----Original Message----- > From: Steve Hanna [mailto:steve.hanna@sun.com] > Sent: Tuesday, October 12, 1999 6:30 AM > To: malloc > Subject: MADCAP to PS! > > Our first RFC! > > -Steve > > -------- Original Message -------- > From: The IESG > Subject: Protocol Action: Multicast Address Dynamic Client Allocation > Protocol (MADCAP) to Proposed Standard > Date: Tue, 12 Oct 1999 06:46:36 -0400 > > The IESG has approved the Internet-Draft 'Multicast Address Dynamic > Client Allocation Protocol (MADCAP)' > as a Proposed Standard. This document is the product of the > Multicast-Address Allocation Working Group. The IESG contact persons > are Scott Bradner and Vern Paxson. > > > Technical Summary > > MADCAP is a client/server protocol by which hosts can request multicast > addresses for use at a specified time in the future and for a specified > duration. Addresses are allocated by a lease mechanism, so the client > can > later attempt to extend the allocation's lifetime. The protocol is > intended for intra-domain use, and assumes that the server has some > sort > of access to a pool of addresses it can then manage. MADCAP requests > and > replies are transmitted in UDP datagrams, and requests can be multicast > for better flexibility and fault tolerance. > > Working Group Summary > > The specification is the result of extensive WG discussion, > particularly > concerning the degree of compatibility with DHCP, and a number of > last-call > comments, including adding error codes to the protocol for indicating > why > a server has rejected a request. There is solid WG consensus for this > version of the document. > > Protocol Quality > > The specification was reviewed for the IESG by Thomas Narten and > Vern Paxson. From owner-malloc@catarina.usc.edu Tue Oct 12 14:56:09 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24057 for ; Tue, 12 Oct 1999 14:56:07 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA12507 for malloc-list; Tue, 12 Oct 1999 11:30:59 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id LAA12495 for malloc@catarina.usc.edu; Tue, 12 Oct 1999 11:30:41 -0700 Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA11947 for ; Tue, 12 Oct 1999 10:48:27 -0700 Received: by dfssl with Internet Mail Service (5.5.2650.21) id <4RCWVD4M>; Tue, 12 Oct 1999 10:47:56 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A56904A39738@SIT.platinum.corp.microsoft.com> From: "Munil Shah (Exchange)" To: "'Patel, Baiju V'" , "'Steve Hanna'" , malloc Subject: RE: MADCAP to PS! Date: Tue, 12 Oct 1999 10:47:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-malloc@catarina.usc.edu Precedence: bulk Indeed. Congratulations! -----Original Message----- From: Patel, Baiju V [mailto:baiju.v.patel@intel.com] Sent: Tuesday, October 12, 1999 8:25 AM To: 'Steve Hanna'; malloc Subject: RE: MADCAP to PS! I would like to thank Steve for working through all the details and getting this draft to progress to PS. Baiju ----------------------- Baiju V. Patel Architect IDS Engineering 503 696 8192 -----Original Message----- From: Steve Hanna [mailto:steve.hanna@sun.com] Sent: Tuesday, October 12, 1999 6:30 AM To: malloc Subject: MADCAP to PS! Our first RFC! -Steve -------- Original Message -------- From: The IESG Subject: Protocol Action: Multicast Address Dynamic Client Allocation Protocol (MADCAP) to Proposed Standard Date: Tue, 12 Oct 1999 06:46:36 -0400 The IESG has approved the Internet-Draft 'Multicast Address Dynamic Client Allocation Protocol (MADCAP)' as a Proposed Standard. This document is the product of the Multicast-Address Allocation Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. Technical Summary MADCAP is a client/server protocol by which hosts can request multicast addresses for use at a specified time in the future and for a specified duration. Addresses are allocated by a lease mechanism, so the client can later attempt to extend the allocation's lifetime. The protocol is intended for intra-domain use, and assumes that the server has some sort of access to a pool of addresses it can then manage. MADCAP requests and replies are transmitted in UDP datagrams, and requests can be multicast for better flexibility and fault tolerance. Working Group Summary The specification is the result of extensive WG discussion, particularly concerning the degree of compatibility with DHCP, and a number of last-call comments, including adding error codes to the protocol for indicating why a server has rejected a request. There is solid WG consensus for this version of the document. Protocol Quality The specification was reviewed for the IESG by Thomas Narten and Vern Paxson. From owner-malloc@CATARINA.USC.EDU Tue Oct 12 17:00:28 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26600 for ; Tue, 12 Oct 1999 17:00:27 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA12894 for malloc-list; Tue, 12 Oct 1999 12:31:05 -0700 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA12889 for ; Tue, 12 Oct 1999 12:31:01 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.6.9) with ESMTP id MAA57777 for ; Tue, 12 Oct 1999 12:30:24 -0700 (PDT) Message-Id: <199910121930.MAA57777@rumi.usc.edu> To: malloc@CATARINA.USC.EDU Subject: MASC draft Date: Tue, 12 Oct 1999 12:30:24 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@CATARINA.USC.EDU Precedence: bulk This weekend I am planning to review again the MASC draft (draft-ietf-malloc-masc-03.txt), so if you have any comments please send them before the weekend so I can include them. This eventually will be the lastest revision circle of the spec, so after that it may be too late for changes. Thanks, Pavlin From owner-malloc@catarina.usc.edu Fri Oct 15 10:22:20 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12399 for ; Fri, 15 Oct 1999 10:22:19 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id GAA01916 for malloc-list; Fri, 15 Oct 1999 06:37:49 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id GAA01912 for ; Fri, 15 Oct 1999 06:37:44 -0700 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA25785 for ; Fri, 15 Oct 1999 06:37:42 -0700 (PDT) Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA05349 for ; Fri, 15 Oct 1999 09:37:40 -0400 (EDT) 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 JAA06226 for ; Fri, 15 Oct 1999 09:37:40 -0400 (EDT) Message-ID: <38072DEF.82422469@sun.com> Date: Fri, 15 Oct 1999 09:36:47 -0400 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: AAP security Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have been working on the next version of the AAP spec and I'd like to discuss the topic of how AAP messages should be authenticated. Authentication for AAP messages is important. Otherwise, denial of service can be easily accomplished by announcing a tiny address set (or blocking everyone's claims, etc.). The current AAP draft calls for each message to be signed with a digital signature. This is problematic, since verifying a digital signature is very expensive (about 160 ms for a DSA verify on my Sun SPARC Ultra 1). Asking each MAAS and Prefix Coordinator (MASC router) to verify a digital signature on each AAP packet received is clearly problematic. And only checking signatures on some packets is also problematic. This just helps detect a denial of service, not prevent one. I suggest that we authenticate messages with a keyed hash (MAC) and discard packets that fail the authentication test. Verifying an MD5-based MAC takes only .21 ms on my Ultra 1. The primary disadvantage of a MAC is that it uses a shared key. If all MAAS's and Prefix Coordinators share the key (as I would suggest), it would not be possible to securely determine which MAAS or Prefix Coordinator sent a particular message. But that's consistent with the general peer-to-peer nature of AAP. Also, the current AAP draft uses a special-purpose packet format. There's really no need for this. The IPsec format (AH or ESP) should work perfectly fine for AAP. We're just doing normal authentication. IPsec doesn't include support for automatic key agreement within multicast groups yet, so people will need to enter the shared key manually on the MAAS's and Prefix Coordinators. But this is a one-time task. The Secure Multicast Research Group (SMuG) is working on group key management techniques that will remove the need for manual keying. They're also working on fast multicast authentication techniques that would allow us to efficiently and securely determine which MAAS or Prefix Coordinator sent a message. Also, if we switch to using IPsec for authentication, we may be able to take advantage of future hardware assist for IPsec. So I suggest that we switch over to using IPsec for our packet authentication. For now, we will suggest that people use MACs with a manually configured shared key. At some later date, they may be able to switch over to some of the SMuG techniques. The primary benefits as I see them are: * Simpler AAP protocol (easier to agree on, implement, etc.) * Less chance of security holes * Leverage current and future IPsec work * Better performance (~500x better) * Invalid packets are discarded in kernel (or hardware) for even better performance The primary disadvantage is: * IPsec support required for secure deployment Comments, please? -Steve From owner-malloc@catarina.usc.edu Mon Oct 18 16:14:13 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18220 for ; Mon, 18 Oct 1999 16:14:12 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA08435 for malloc-list; Mon, 18 Oct 1999 12:36:20 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id MAA08431 for ; Mon, 18 Oct 1999 12:36:14 -0700 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA04646 for ; Mon, 18 Oct 1999 12:36:10 -0700 (PDT) Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id PAA21800 for ; Mon, 18 Oct 1999 15:36:08 -0400 (EDT) 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 PAA13589 for ; Mon, 18 Oct 1999 15:36:08 -0400 (EDT) Message-ID: <380B7672.CFB17BF6@sun.com> Date: Mon, 18 Oct 1999 15:35:14 -0400 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: malloc scheduling for 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 I have just heard that at IETF 46, the malloc working group has been scheduled for Friday, November 12, 9 AM. -Steve From owner-malloc@catarina.usc.edu Mon Oct 18 17:18:30 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19514 for ; Mon, 18 Oct 1999 17:18:29 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA09144 for malloc-list; Mon, 18 Oct 1999 13:49:26 -0700 Received: from dthaler.microsoft.com ([131.107.152.20]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA09140 for ; Mon, 18 Oct 1999 13:49:20 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id PAA24579; Mon, 18 Oct 1999 15:28:57 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199910182228.PAA24579@dthaler.microsoft.com> Subject: Re: AAP security In-Reply-To: <38072DEF.82422469@sun.com> from Steve Hanna at "Oct 15, 1999 9:36:47 am" To: steve.hanna@sun.com (Steve Hanna) Date: Mon, 18 Oct 1999 15:28:57 -0700 (PDT) Cc: malloc@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Steve Hanna writes: > So I suggest that we switch over to using IPsec for our packet > authentication. For now, we will suggest that people use MACs with a > manually configured shared key. At some later date, they may be able to > switch over to some of the SMuG techniques. My personal opinions... I am okay with this. However, you may want to think about the effect of multiple scopes. I would suggest saying "a manually configured shared key per scope". This way, MAAS's in a small scope (which may be configured by the same person) can use a key for that scope which doesn't have to be known by admins in a slightly wider area. I would also ask that the wording be general enough not to preclude the use of public keys with IPsec if/when smug develops practical solutions. -Dave From owner-malloc@catarina.usc.edu Mon Oct 18 17:29:07 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19660 for ; Mon, 18 Oct 1999 17:29:04 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA09239 for malloc-list; Mon, 18 Oct 1999 13:56:02 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA09232 for ; Mon, 18 Oct 1999 13:55:47 -0700 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13994; Mon, 18 Oct 1999 13:55:43 -0700 (PDT) Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA29913; Mon, 18 Oct 1999 16:55:41 -0400 (EDT) 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 QAA15304; Mon, 18 Oct 1999 16:55:42 -0400 (EDT) Message-ID: <380B8917.1D5D1101@sun.com> Date: Mon, 18 Oct 1999 16:54:47 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: malloc@catarina.usc.edu Subject: Re: AAP security References: <199910182228.PAA24579@dthaler.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave Thaler wrote: > Steve Hanna writes: > > So I suggest that we switch over to using IPsec for our packet > > authentication. For now, we will suggest that people use MACs with a > > manually configured shared key. At some later date, they may be able > > to switch over to some of the SMuG techniques. > > My personal opinions... > > I am okay with this. However, you may want to think about the effect > of multiple scopes. I would suggest saying "a manually configured > shared key per scope". This way, MAAS's in a small scope (which may > be configured by the same person) can use a key for that scope > which doesn't have to be known by admins in a slightly wider area. Yes. I will mention this explicitly. > I would also ask that the wording be general enough not to preclude > the use of public keys with IPsec if/when smug develops practical > solutions. Definitely. Thanks for the comments, Steve From owner-malloc@catarina.usc.edu Tue Oct 19 12:31:20 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25124 for ; Tue, 19 Oct 1999 12:31:18 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA14318 for malloc-list; Tue, 19 Oct 1999 08:58:19 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA14313 for malloc@catarina.usc.edu; Tue, 19 Oct 1999 08:57:59 -0700 Received: from public.szptt.net.cn (pop.szptt.net.cn [202.96.134.151]) by catarina.usc.edu (8.6.10/8.6.9) with SMTP id IAA14231 for ; Tue, 19 Oct 1999 08:28:23 -0700 Received: from public.szptt.net.cn([202.96.134.151]) by public.szptt.net.cn(JetMail 2.3.1.0) with SMTP id /m1/aimcque/jmail.rcv/4/jm0380c918b; Tue, 19 Oct 1999 15:33:02 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.3.1.0) with SMTP id /m1/aimcque/jmail.rcv/5/jm537f28b87; Wed, 29 Sep 1999 14:00:44 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id IAA16914 for ietf-123-outbound.01@ietf.org; Wed, 29 Sep 1999 08:35:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA16055 for ; Wed, 29 Sep 1999 06:57:40 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22089; Wed, 29 Sep 1999 06:57:10 -0400 (EDT) Message-Id: <199909291057.GAA22089@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-07.txt Date: Wed, 29 Sep 1999 06:57:09 -0400 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 : Multicast Address Dynamic Client Allocation Protocol (MADCAP) Author(s) : S. Hanna, B. Patel, M. Shah Filename : draft-ietf-malloc-madcap-07.txt Pages : 50 Date : 28-Sep-99 This document defines a protocol, Multicast Address Dynamic Client Allocation Protocol (MADCAP), that allows hosts to request multicast addresses from multicast address allocation servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-madcap-07.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-07.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-07.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: <19990928085859.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-madcap-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-madcap-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990928085859.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Wed Oct 20 01:10:08 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09943 for ; Wed, 20 Oct 1999 01:10:07 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id VAA18900 for malloc-list; Tue, 19 Oct 1999 21:50:44 -0700 Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id VAA18896 for ; Tue, 19 Oct 1999 21:50:40 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.6.9) with ESMTP id VAA01814 for ; Tue, 19 Oct 1999 21:50:39 -0700 (PDT) Message-Id: <199910200450.VAA01814@rumi.usc.edu> To: malloc@catarina.usc.edu Subject: MASC and IPv6 IDs Date: Tue, 19 Oct 1999 21:50:38 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk Currently, MASC uses variable length fields for Mcast Prefix Address and Prefix Mask for each claim. The length is defined by the Address Family field in each claim: 4 octets for IPv4, and 6 octets for IPv6; however, the Domain and the Node IDs (in both the OPEN and UPDATE messages) have fixed length: 32 bits each. The Origin Domain ID and Origin Node ID need to be unique among all siblings, parents, and children of a given MASC domain. To avoid problems that may come by selecting "locally unique IDs", it is better if those IDs are globally unique, but obviously this is not possible with IPv6 and Node ID of only 32 bits. I would suggest to make both Node ID and Domain ID variable length (defined by AddrFamily): 32 bits for IPv4 and 128 bits for IPv6. Strictly speaking, we don't need 128 bits for Domain ID, but it will be less confusing if both Node ID and Domain ID are same length, and anyway MASC is very slow and low BW protocol, so the overhead will be negligible. Comments? Thanks, Pavlin P.S. BTW, I don't have strong opinion if/when/why we may need to use MASC for IPv6, but it seems easy to do support it, and won't hurt anyway ;) From owner-malloc@catarina.usc.edu Wed Oct 20 16:49:30 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23404 for ; Wed, 20 Oct 1999 16:49:29 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA23856 for malloc-list; Wed, 20 Oct 1999 13:20:18 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA23852 for ; Wed, 20 Oct 1999 13:20:00 -0700 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA24563 for ; Wed, 20 Oct 1999 13:19:37 -0700 (PDT) Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA09011 for ; Wed, 20 Oct 1999 16:17:28 -0400 (EDT) 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 QAA16292 for ; Wed, 20 Oct 1999 16:17:28 -0400 (EDT) Message-ID: <380E2321.5B6C5DDF@sun.com> Date: Wed, 20 Oct 1999 16:16:33 -0400 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: Revised AAP draft (draft-ietf-malloc-aap-02.txt) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have submitted a new version of the AAP spec to the Internet Drafts editor and posted a copy on the malloc web site. It's available from: http://www.aciri.org/malloc/draft-ietf-malloc-aap-02.txt This version is a complete rewrite of the previous version, but the basic protocol hasn't changed much. I think I have filled in all the details, so please review this draft and send comments to the mailing list (or to me, if you prefer). We will discuss this draft at IETF 46 in Washington. Thanks, Steve P.S. I know that the formatting in Appendix C is messed up and I need to add some protocol examples to Appendix A. From owner-malloc@catarina.usc.edu Wed Oct 20 20:38:14 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26164 for ; Wed, 20 Oct 1999 20:38:13 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id QAA25433 for malloc-list; Wed, 20 Oct 1999 16:24:57 -0700 Received: from dthaler.microsoft.com ([131.107.152.20]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id QAA25429 for ; Wed, 20 Oct 1999 16:24:51 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id SAA28686; Wed, 20 Oct 1999 18:04:19 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199910210104.SAA28686@dthaler.microsoft.com> Subject: Updated Malloc Arch Doc To: malloc@catarina.usc.edu Date: Wed, 20 Oct 1999 18:04:19 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit I've updated the MALLOC Architecture doc in response to comments received during WG Last Call. I've put a version up on the malloc web site for anyone who wants to take a look before it appears in the Internet-Drafts directory. http://www.aciri.org/malloc/draft-ietf-malloc-arch-03.txt Changes include: * definition of "Allocation Scope" (including values for IPv4 and IPv6), and cleaning up related discussion of "allocation domains", * addition of required Security Considerations section containing points which have been discussed at previous IETF meetings, * addition of required Authors Addresses section, * addition of required Full Copyright Statement, * a number of wording clarifications, and * updating of references. Since section 5.1 (Allocation Scope) and section 7 (Security Considerations) contain new text, I would like to ask for some WG review of at least these two sections prior to IETF. Thanks, -Dave From owner-malloc@catarina.usc.edu Thu Oct 21 11:43:22 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00710 for ; Thu, 21 Oct 1999 11:43:21 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA01567 for malloc-list; Thu, 21 Oct 1999 08:01:53 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA01563 for ; Thu, 21 Oct 1999 08:01:38 -0700 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26065 for ; Thu, 21 Oct 1999 08:01:30 -0700 (PDT) Received: from sunlabs.East.Sun.COM (sunray-svr.East.Sun.COM [129.148.74.250]) by eastmail1.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA27639 for ; Thu, 21 Oct 1999 11:01:27 -0400 (EDT) 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 LAA24338 for ; Thu, 21 Oct 1999 11:01:24 -0400 (EDT) Message-ID: <380F2A8B.F31CC0D4@sun.com> Date: Thu, 21 Oct 1999 11:00:27 -0400 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: Another revised AAP draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit The Internet Drafts editor tells me that the AAP draft we posted in June was actually -00 in their database (and on their web server), so the draft I posted yesterday must be -01. I tried to argue, but they would not be moved. So I took the opportunity to fix a few problems with yesterday's draft. I wrote up a new -02 draft and sent it off to the Internet Drafts editor. Here's hoping they don't get confused again. The new draft is available from: http://www.aciri.org/malloc/draft-ietf-malloc-aap-02.txt The changes in this draft are not substantial. I merged a few sections, fixed some typos, and took out the definition of the Allocation Scope, since Dave has now placed that in the architecture document. I know this is confusing. But it's easier to get in synch now, rather than later. The easiest way to distinguish between the two -02 drafts is that the one I posted today has an explanation of this confusing situation in Appendix C. -Steve From owner-malloc@catarina.usc.edu Thu Oct 21 12:10:39 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02590 for ; Thu, 21 Oct 1999 12:10:38 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA01782 for malloc-list; Thu, 21 Oct 1999 08:28:33 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id IAA01778 for ; Thu, 21 Oct 1999 08:28:20 -0700 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09412; Thu, 21 Oct 1999 08:27:41 -0700 (PDT) Received: from sunlabs.East.Sun.COM (sunray-svr.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 LAA27185; Thu, 21 Oct 1999 11:27:37 -0400 (EDT) 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 LAA25697; Thu, 21 Oct 1999 11:27:39 -0400 (EDT) Message-ID: <380F30B2.150E9CBF@sun.com> Date: Thu, 21 Oct 1999 11:26:42 -0400 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: malloc@catarina.usc.edu Subject: Re: Updated Malloc Arch Doc References: <199910210104.SAA28686@dthaler.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for getting this draft out in time. I only have one comment of substance. In section 6, you talk about "prefixes" being passed to MAAS's by the Prefix Coordinator. I think we discussed this a few weeks ago on the mailing list and decided that Prefix Coordinators could pass in any arbitrary set of address ranges from the scope. The address ranges need not make up a "prefix" in the normal sense of the word. This wouldn't be likely with MASC, but it might be used with static configuration for Layer 3, when an AS decides to split up into several smaller allocation domains and decides to split up its glop addresses in a way that doesn't match prefix conventions. I know that any such split can be broken down into a set of prefixes (perhaps including some /32s), but I don't think that's what people normally think of when they hear prefix. Also, a few typos: In section 3.1 in the first paragraph of the Static section, it would be nice to add a reference for Network Time Protocol. The AAP and MADCAP specs have suitable references for this. In section 5, the last line of the third paragraph begins with "scopes are scopes are". And in the last paragraph of section 7, you have "should not allow don't allow". Other than that, it looks fine. Thanks, Steve Dave Thaler wrote: > > I've updated the MALLOC Architecture doc in response to comments > received during WG Last Call. I've put a version up on the malloc > web site for anyone who wants to take a look before it appears > in the Internet-Drafts directory. > > http://www.aciri.org/malloc/draft-ietf-malloc-arch-03.txt > > Changes include: > * definition of "Allocation Scope" (including values for > IPv4 and IPv6), and cleaning up related discussion > of "allocation domains", > * addition of required Security Considerations section > containing points which have been discussed at previous > IETF meetings, > * addition of required Authors Addresses section, > * addition of required Full Copyright Statement, > * a number of wording clarifications, and > * updating of references. > > Since section 5.1 (Allocation Scope) and section 7 (Security > Considerations) contain new text, I would like to ask for some WG > review of at least these two sections prior to IETF. > > Thanks, > -Dave From owner-malloc@catarina.usc.edu Fri Oct 22 13:07:56 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24903 for ; Fri, 22 Oct 1999 13:07:55 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA09482 for malloc-list; Fri, 22 Oct 1999 09:04:05 -0700 Received: from carlsbad.usc.edu (carlsbad.usc.edu [128.125.51.5]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id JAA09478 for ; Fri, 22 Oct 1999 09:03:57 -0700 Received: (pavlin@localhost) by carlsbad.usc.edu (8.6.10/8.6.9) id JAA02067 for malloc@catarina.usc.edu; Fri, 22 Oct 1999 09:03:52 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id DAA08279 for ; Fri, 22 Oct 1999 03:58:46 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06116; Fri, 22 Oct 1999 06:58:44 -0400 (EDT) Message-Id: <199910221058.GAA06116@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-aap-01.txt Date: Fri, 22 Oct 1999 06:58:44 -0400 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 : Multicast Address Allocation Protocol (AAP) Author(s) : M. Handley, S. Hanna Filename : draft-ietf-malloc-aap-01.txt Pages : 35 Date : 21-Oct-99 The document defines a Multicast Address Allocation Protocol (AAP) that forms a part of the Internet Multicast Address Allocation Architecture being defined by the IETF Multicast Address Allocation Working Group. AAP addresses the specific issue of coordination among Multicast Address Allocation Servers within a domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-aap-01.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-aap-01.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-aap-01.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: <19991021142918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-aap-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-aap-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991021142918.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Fri Oct 22 13:08:33 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24948 for ; Fri, 22 Oct 1999 13:08:30 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA09488 for malloc-list; Fri, 22 Oct 1999 09:04:21 -0700 Received: from carlsbad.usc.edu (carlsbad.usc.edu [128.125.51.5]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id JAA09484 for ; Fri, 22 Oct 1999 09:04:14 -0700 Received: (pavlin@localhost) by carlsbad.usc.edu (8.6.10/8.6.9) id JAA02071 for malloc@catarina.usc.edu; Fri, 22 Oct 1999 09:04:10 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id DAA08288 for ; Fri, 22 Oct 1999 03:58:52 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06130; Fri, 22 Oct 1999 06:58:51 -0400 (EDT) Message-Id: <199910221058.GAA06130@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-arch-03.txt Date: Fri, 22 Oct 1999 06:58:50 -0400 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 : The Internet Multicast Address Allocation Architecture Author(s) : D. Thaler, M. Handley, D. Estrin Filename : draft-ietf-malloc-arch-03.txt Pages : 15 Date : 21-Oct-99 This document proposes a multicast address allocation architecture for the Internet, and is intended to be generic enough to apply to both IPv4 and IPv6 environments. As with unicast addresses, the usage of any given multicast address is limited in two dimensions: Lifetime: An address has a start time and a (possibly infinite) end time, between which it is valid. Scope: An address is valid over a specific area of the network. For example, it may be globally valid and unique, or it may be a private address which is valid only within a local area. This architecture assumes that the primary scoping mechanism in use is administrative scoping, as described in RFC 2365 [1]. While solutions that work for TTL scoping are possible, they introduce significant additional complication for address allocation [2]. Moreover, TTL scoping is a poor solution for multicast scope control, and our assumption is that usage of TTL scoping will decline before this architecture is widely used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-arch-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-arch-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-arch-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: <19991021142930.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-arch-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-arch-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991021142930.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Fri Oct 22 16:48:31 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06104 for ; Fri, 22 Oct 1999 16:48:30 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA11578 for malloc-list; Fri, 22 Oct 1999 13:28:39 -0700 Received: from rumi.usc.edu ([128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA11355 for ; Fri, 22 Oct 1999 13:04:25 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.6.9) with ESMTP id NAA12787 for ; Fri, 22 Oct 1999 13:04:19 -0700 (PDT) Message-Id: <199910222004.NAA12787@rumi.usc.edu> To: malloc@catarina.usc.edu Subject: MASC I-D Date: Fri, 22 Oct 1999 13:04:19 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk I've just submitted draft-ietf-malloc-masc-04.txt. Until it appears in the I-D directory, you can get a copy of it from http://netweb.usc.edu/masc/draft-ietf-malloc-masc-04.txt Below is the list of changes (most of them are due to Dave's detailed comments and suggestions): * OPEN message format modification: - AddrFam field added - Sender Domain ID, Sender MASC Node ID, Parent's Domain ID are variable length (depend on AddrFam: 4 octets for IPv4, 16 octets for IPv6) instead of fixed length of 4 octets. - The three IDs above are re-ordered * UPDATE message format modification: - Origin Domain ID and Origin Node ID are variable length (4 octets for IPv4; 16 octets for IPv6) - The fixed length fields (Timestamp, Lifetime, Holdtime) are moved in front of the variable length fields. - The "A-bit" (the Active prefix bit) is renamed to D-bit (Deprecated prefix bit), and its polarity is reversed: if reset, the prefix is Active, otherwise is Deprecated. - The Rol, D-bit and AddrFam fields are re-ordered to reflect the ordering of Rol and AddrFam in the OPEN message. * The Authentication Code must include 2 values instead of 3: "the algorithm for computing values of Marker fields" is removed. * The C-bit (the Close-bit in the Notification message) is renamed to O-bit (Open-bit), and its polarity is reversed: if reset, the connection will be closed, otherwise it may remain open. * Clarification in Section 14 (Security consideration) re. whose signature an UPDATE message should carry. * Appendix C (QUERY/RESPONSE Debug Messages) removed (will put it in a separate document somewhere on the Web) * APPENDIX D (Major Changes and Updates) removed. * A number of re-wording and clarifications Pavlin From owner-malloc@catarina.usc.edu Fri Oct 22 17:17:58 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07886 for ; Fri, 22 Oct 1999 17:17:57 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id NAA11359 for malloc-list; Fri, 22 Oct 1999 13:04:29 -0700 Received: from rumi.usc.edu ([128.125.51.41]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id NAA11355 for ; Fri, 22 Oct 1999 13:04:25 -0700 Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.6.9) with ESMTP id NAA12787 for ; Fri, 22 Oct 1999 13:04:19 -0700 (PDT) Message-Id: <199910222004.NAA12787@rumi.usc.edu> To: malloc@catarina.usc.edu Subject: MASC I-D Date: Fri, 22 Oct 1999 13:04:19 -0700 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk I've just submitted draft-ietf-malloc-masc-04.txt. Until it appears in the I-D directory, you can get a copy of it from http://netweb.usc.edu/masc/draft-ietf-malloc-masc-04.txt Below is the list of changes (most of them are due to Dave's detailed comments and suggestions): * OPEN message format modification: - AddrFam field added - Sender Domain ID, Sender MASC Node ID, Parent's Domain ID are variable length (depend on AddrFam: 4 octets for IPv4, 16 octets for IPv6) instead of fixed length of 4 octets. - The three IDs above are re-ordered * UPDATE message format modification: - Origin Domain ID and Origin Node ID are variable length (4 octets for IPv4; 16 octets for IPv6) - The fixed length fields (Timestamp, Lifetime, Holdtime) are moved in front of the variable length fields. - The "A-bit" (the Active prefix bit) is renamed to D-bit (Deprecated prefix bit), and its polarity is reversed: if reset, the prefix is Active, otherwise is Deprecated. - The Rol, D-bit and AddrFam fields are re-ordered to reflect the ordering of Rol and AddrFam in the OPEN message. * The Authentication Code must include 2 values instead of 3: "the algorithm for computing values of Marker fields" is removed. * The C-bit (the Close-bit in the Notification message) is renamed to O-bit (Open-bit), and its polarity is reversed: if reset, the connection will be closed, otherwise it may remain open. * Clarification in Section 14 (Security consideration) re. whose signature an UPDATE message should carry. * Appendix C (QUERY/RESPONSE Debug Messages) removed (will put it in a separate document somewhere on the Web) * APPENDIX D (Major Changes and Updates) removed. * A number of re-wording and clarifications Pavlin From owner-malloc@catarina.usc.edu Mon Oct 25 15:10:17 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02484 for ; Mon, 25 Oct 1999 15:10:14 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA23040 for malloc-list; Mon, 25 Oct 1999 08:34:15 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id IAA23035 for malloc@catarina.usc.edu; Mon, 25 Oct 1999 08:34:04 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id EAA22338 for ; Mon, 25 Oct 1999 04:01:10 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03451; Mon, 25 Oct 1999 07:01:08 -0400 (EDT) Message-Id: <199910251101.HAA03451@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-aap-02.txt Date: Mon, 25 Oct 1999 07:01:08 -0400 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 : Multicast Address Allocation Protocol (AAP) Author(s) : M. Handley, S. Hanna Filename : draft-ietf-malloc-aap-02.txt Pages : 35 Date : 22-Oct-99 The document defines a Multicast Address Allocation Protocol (AAP) that forms a part of the Internet Multicast Address Allocation Architecture being defined by the IETF Multicast Address Allocation Working Group. AAP addresses the specific issue of coordination among Multicast Address Allocation Servers within a domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-aap-02.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-aap-02.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-aap-02.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: <19991022140201.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-aap-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-aap-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991022140201.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Tue Oct 26 15:16:11 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20943 for ; Tue, 26 Oct 1999 15:16:10 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA29726 for malloc-list; Tue, 26 Oct 1999 10:55:09 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA29721 for malloc@catarina.usc.edu; Tue, 26 Oct 1999 10:55:04 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id EAA28352 for ; Tue, 26 Oct 1999 04:24:52 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01550; Tue, 26 Oct 1999 07:24:49 -0400 (EDT) Message-Id: <199910261124.HAA01550@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-aap-02.txt Date: Tue, 26 Oct 1999 07:24:48 -0400 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 : Multicast Address Allocation Protocol (AAP) Author(s) : M. Handley, S. Hanna Filename : draft-ietf-malloc-aap-02.txt Pages : 35 Date : 22-Oct-99 The document defines a Multicast Address Allocation Protocol (AAP) that forms a part of the Internet Multicast Address Allocation Architecture being defined by the IETF Multicast Address Allocation Working Group. AAP addresses the specific issue of coordination among Multicast Address Allocation Servers within a domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-aap-02.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-aap-02.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-aap-02.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: <19991022140201.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-aap-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-aap-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991022140201.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-malloc@catarina.usc.edu Wed Oct 27 12:35:43 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21359 for ; Wed, 27 Oct 1999 12:35:43 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id JAA07202 for malloc-list; Wed, 27 Oct 1999 09:11:33 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id JAA07198 for ; Wed, 27 Oct 1999 09:11:25 -0700 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28093 for ; Wed, 27 Oct 1999 09:11:21 -0700 (PDT) Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail1.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA06307 for ; Wed, 27 Oct 1999 12:11:17 -0400 (EDT) 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 MAA07299 for ; Wed, 27 Oct 1999 12:11:15 -0400 (EDT) Message-ID: <381723E6.E6136159@sun.com> Date: Wed, 27 Oct 1999 12:10:14 -0400 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: AAP discussion issues 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 the list of open issues from the latest AAP draft. I would like to encourage discussion of these topics on the malloc list before IETF. Thanks, Steve ----------- Is Prefix Coordinator really the right name for the hosts that announce the set of multicast addresses available for use within an allocation domain? We don't require the addresses to be prefixes any more. Maybe they should be called Address Coordinators. Or Domain Address Coordinators. When a MAAS has just done a successful claim, is it really necessary to send AIU with an interval starting at [RESEND-INTERVAL]? We already did that with the ACLM! The old draft talked about MAAS's allocating from only one half of a prefix if utilization is low in that prefix. I don't see how that will work. There will probably be long-lived allocations all over the prefix. And I don't think it is needed. A Prefix Coordinator can just extend the lifetime of only part of the existing prefix. Or allocate a new, smaller set of addresses with a longer lifetime and let the old prefix expire. Should we add start times to the ASA message so that Prefix Coordinators can announce upcoming addresses? If so, should we let MAAS's allocate addresses before their start times? And should we add something to ASA that says "I'm working on these address requests, but these others are right out." That would give MAAS's a way to give feedback to their clients on address requests. I would be inclined to leave all of these things for the future, when they can be added (via new message types). From owner-malloc@catarina.usc.edu Wed Oct 27 13:33:40 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25247 for ; Wed, 27 Oct 1999 13:33:39 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA07733 for malloc-list; Wed, 27 Oct 1999 10:14:11 -0700 Received: from dthaler.microsoft.com ([131.107.152.20]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA07729 for ; Wed, 27 Oct 1999 10:13:56 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id LAA12450; Wed, 27 Oct 1999 11:52:50 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199910271852.LAA12450@dthaler.microsoft.com> Subject: Re: AAP discussion issues In-Reply-To: <381723E6.E6136159@sun.com> from Steve Hanna at "Oct 27, 1999 12:10:14 pm" To: steve.hanna@sun.com (Steve Hanna) Date: Wed, 27 Oct 1999 11:52:50 -0700 (PDT) Cc: malloc@catarina.usc.edu X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Steve Hanna writes: > Is Prefix Coordinator really the right name for the hosts that announce > the set of multicast addresses available for use within an allocation > domain? We don't require the addresses to be prefixes any more. Maybe > they should be called Address Coordinators. Or Domain Address > Coordinators. I don't have a better suggestion, but I don't like Address C.'s or Domain Address C.'s since they imply single coordination of single addresses rather than ranges. If they're ranges, then Address Range Coordinators might be appropriate. > When a MAAS has just done a successful claim, is it really necessary to > send AIU with an interval starting at [RESEND-INTERVAL]? We already did > that with the ACLM! > > The old draft talked about MAAS's allocating from only one half of a > prefix if utilization is low in that prefix. I don't see how that will > work. There will probably be long-lived allocations all over the prefix. > And I don't think it is needed. A Prefix Coordinator can just extend the > lifetime of only part of the existing prefix. I think that's what the old draft meant. Extend the lifetime of half, and only make new allocations and renewals for addresses in that half. > Or allocate a new, smaller > set of addresses with a longer lifetime and let the old prefix expire. > > Should we add start times to the ASA message so that Prefix Coordinators > can announce upcoming addresses? My opinion: no, too much complexity. At the domain level and above, there are currently no start times (on ranges). > If so, should we let MAAS's allocate > addresses before their start times? And should we add something to ASA > that says "I'm working on these address requests, but these others are > right out." That would give MAAS's a way to give feedback to their > clients on address requests. I would be inclined to leave all of these > things for the future, when they can be added (via new message types). I would be inclined to agree (leave them right out for now). -Dave From owner-malloc@catarina.usc.edu Wed Oct 27 14:10:33 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27561 for ; Wed, 27 Oct 1999 14:10:27 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id KAA08098 for malloc-list; Wed, 27 Oct 1999 10:47:14 -0700 Received: from dthaler.microsoft.com ([131.107.152.20]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id KAA08092 for ; Wed, 27 Oct 1999 10:47:01 -0700 Received: (from dthaler@localhost) by dthaler.microsoft.com (8.8.7/8.8.7) id MAA12564; Wed, 27 Oct 1999 12:25:54 -0700 (PDT) (envelope-from dthaler) From: Dave Thaler Message-Id: <199910271925.MAA12564@dthaler.microsoft.com> Subject: Zeroconf-Malloc draft To: zeroconf@merit.edu, malloc@catarina.usc.edu Date: Wed, 27 Oct 1999 12:25:54 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA27561 The following is a first cut on doing multicast address allocation in zeroconf networks. It missed the I-D deadline, so I'm posting it on the malloc and zeroconf lists. Members of the MALLOC and ZEROCONF WGs, please review... We'd like some time in DC (ideally in both WG's) to discuss this. Thanks, -Dave --- Network Working Group D. Thaler INTERNET-DRAFT B. Aboba October 22, 1999 Microsoft Expires: April 2000 Multicast Address Allocation in Auto-Configured Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Expires April 2000 [Page 1] Draft Multicast Auto-Configured Networks October 1999 1. Abstract Today, with the rapid rise of home networking, there is an increasing need for auto-configuration mechanisms. This document describes how small networks without a multicast address allocation server may auto-allocate multicast addresses. 2. Introduction The Internet Multicast Address Allocation Architecture [1] provides a framework which includes multicast address allocation servers (MAASs) that allocate addresses to hosts. The Multicast Address Dynamic Client Allocation Protocol (MADCAP) [2] has been proposed as the protocol via which hosts and servers communicate. The Multicast Address Allocation Protocol (AAP) [3] has been proposed as the protocol via which servers communicate with each other to prevent allocating the same addresses. However, servers may not be present in all environments. Today, with the rapid rise of home networking, there is an increasing need for auto-configuration mechanisms. This document describes how small networks without a multicast address allocation server may auto-allocate multicast addresses. 3. Terminology This document uses the following terms: Configured environment A network area (such as the Internet or an enterprise network) which are managed by one or more administrators or organizations. Zero-configuration environment A network area consisting of devices which have no manual configuration done to them, and are not managed by an administrator or organization. There are two primary zero-configuration scenarios which we distinguish between, and between a configured environment, in this document. Expires April 2000 [Page 2] Draft Multicast Auto-Configured Networks October 1999 Isolated: A group of hosts communicate as peers in a zero- configuration environment. In this scenario, there are no address allocation servers, and likely no routers. Edge: In this scenario, we assume there is a router which connects a zero-configuration environment to a configured environment such as the Internet. In this scenario, there are no address allocation servers configured in the zero-configuration area, and there may or may not be servers in the configured environment. In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [4]. 4. Configuration requirements for small networks In order to enable effective multicast address allocation in small networks, the following requirements need to be met: Allocation A mechanism MUST be provided to allow for hosts to allocate multicast addresses. Ideally, host behavior should be the same in a zero-configuration environment and in a configured environment so that transitions can be done easily. Isolated to Edge transition A mechanism MUST be provided to transition between the Isolated and Edge scenarios. This happens when a router is added to connect an Isolated area to a configured environment, such as when a host in an Isolated environment dials an Internet Service Provider (ISP) and becomes a router. Similarly, the reverse transition occurs if the router goes down. Isolated to Configured transition A mechanism MUST be provided to transition between an Isolated and a Configured environment. This occurs, for example, in a corporate environment when a router comes up or goes down. When a router is down, any hosts on disconnected links may be in an Isolated environment. Expires April 2000 [Page 3] Draft Multicast Auto-Configured Networks October 1999 5. Auto-configuration prescription In this section, we assume that MADCAP and AAP are the protocols in use, since they appear to meet the requirements. 5.1. Zero-configuration host behavior As described in [5], a host provides two services to its applications through some API. First, it must allow applications to enumerate the set of available multicast scopes. Second, it must allow applications to request, renew, and release addresses, where the scope must be specified by the application. Note that acquiring the set of enumerated scopes does not necessarily imply that addresses are available in each scope, only that it is legal for an application to request an address in one. 5.1.1. Scope enumeration To determine whether a multicast address allocation server is available, a host SHOULD, at startup time, attempt to acquire the list of multicast scopes available by using MADCAP's GETINFO request as described in [2], and done periodically thereafter. This determination MAY instead be delayed until an application wants to enumerate scopes, at the expense of increasing the time needed. If any servers are found, a host should use the set of scopes returned by the servers. In addition, if ranges are defined for allocation of Link-Local, Node-Local, and/or Single-Source addresses, these may be assumed as well (for example, such Link- Local and Node-Local are currently defined in IPv6 [6], and Single-Source is currently defined in IPv4 [7]). If no servers are found, a host can assume that any scopes exist which are well-known with specified ranges. These include the Global scope, the Local scope [6], the Allocation scope [1], and the Single-Source scope. In this situation, a host MAY also begin passively listening to MZAP [8] messages to build up its scope list further. (MZAP sends very low frequency reports of scopes to listeners inside those scopes.) Expires April 2000 [Page 4] Draft Multicast Auto-Configured Networks October 1999 5.1.2. Address Allocation Node-Local and Single-Source addresses can be allocated immediately by any host. The algorithm for choosing an address is implementation-dependent, but the address range to use MUST be the range registered with IANA for the specified scope. Link-Local addresses can be allocated only by hosts which implement at least a minimal subset of AAP consisting of the ACLM and AIU messages For all other addresses, the following procedures apply. If the host has recently tried to obtain the scope list, then the host already knows whether any MAAS's are present. If it has not tried recently, then the host can use MADCAP to discover a server when it wants to allocate an address. If a server is present, the host simply uses MADCAP to allocate addresses. If no server is present, then if the scope associated with the request is "big" (Global, or any scope obtained from MZAP and identified by MZAP as "big"), then no addresses may be allocated; otherwise (if the scope is not "big") then the host MAY allocate addresses by participating in AAP. The host MUST NOT allocate the last 256 addresses in the range as these are reserved for scope- relative addresses [6]. 5.2. Zero-configuration router behavior In the Edge scenario, a zero-configuration router exists, with a link which connects to a configured environment. Here, there is likely a well-understood distinction between the local area and the external environment, as well as a potential requirement to be able to scope some data to the local area. Hence, if the router detects that it is an "Edge" router (i.e. a router in an Edge scenario), it should instantiate a Local scope boundary on that link. However, before it can do this, a router must be able to distinguish between whether it is in an Edge scenario, or in a configured environment. This could be done in any implementation- specific manner. For example, the router could assume it is in a Expires April 2000 [Page 5] Draft Multicast Auto-Configured Networks October 1999 zero-configuration environment unless it is specifically configured otherwise. This would appear to be acceptable, since if it is in a configured environment, the router would typically be configured anyway. If the router determines that it is an Edge router, the router SHOULD instantiate a Local scope boundary and become a mini-MAAS with behavior as follows. 5.2.1. Scope enumeration To acquire a set of scopes, the router performs the same actions as those described for hosts in Section 5.1.1 above, with MADCAP queries being sent out over the link to the configured environment. When the router receives GETINFO messages from clients in the zero-configuration environment asking for the scope list, it responds as a MADCAP server would, by including the scope list it acquired above. 5.2.2. Address Allocation Local scope addresses can be allocated immediately by the router as if it were a MADCAP server. For addresses in all larger scopes, the following procedures apply. If a MADCAP server was found in the configured environment, the router acts as a MADCAP proxy and relays the request to an appropriate server as if it were a client. The response is relayed back to the client as if it were a server. if no MADCAP server was found in the configured environment, the router MAY allocate addresses itself if it implements AAP to coordinate with any other MAASs (such as other Edge routers) reached via the configured environment. 6. Transitioning Between Scenarios In an Isolated environment, each host should periodically (either at regular intervals, or only when applications request addresses Expires April 2000 [Page 6] Draft Multicast Auto-Configured Networks October 1999 or scope lists) re-check whether a server is available. This allows simple transition to an Edge or configured environment. Similarly, if the host stops receiving responses from any servers, the behavior specified in Section 5.1 allows it to continue allocating addresses. In an Edge environment, the Edge router should periodically (either at regular intervalue, or only when hosts request addresses or scope lists) re-check whether a server is available in the configured environment. Similarly, if the Edge router stops receiving responses from any servers in the configured environment, the behavior specified in Section 5.2 allows it to continue allocating addresses. 7. Security Considerations In the interest of simplicity, this draft does not prescribe a means of securing the multicast auto-configuration mechanism. Thus it is possible that hosts will allocate conflicting multicast addresses for a period of time, or that non-conforming hosts will attempt to deny service to other hosts by allocating the same multicast addresses. Since MADCAP is used as a mechanism for determining whether to auto-configure, it should be noted that it is likely that hosts in small network scenarios will not attempt to secure their MADCAP traffic. If unsecured, MADCAP is vulnerable to a number of threats, including message modification and attacks by rogue servers and unauthenticated clients. While the procedure described in this document does not preclude implementation of MADCAP security, the extra configuration required to set this up represents an implementation barrier in the home network. As a result, it is likely that most home routers will not support MADCAP authentication, and that those networks will remain vulnerable to attack. These threats are most serious in wireless networks such as 802.11, since attackers on a wired network will require physical access to the home network, while wireless attackers may reside outside the home. In order to provide for privacy equivalent to a Expires April 2000 [Page 7] Draft Multicast Auto-Configured Networks October 1999 wired network, the 802.11 specification provides for RC4-based encryption. This is known as the "Wired Equivalency Privacy" (WEP) specification, described in [9]. Where WEP is implemented, an attacker will need to obtain the WEP key prior to gaining access to the home network. 8. Acknowledgements This draft has been enriched by comments from Steve Hanna of Sun Microsystems. 9. References [1] Thaler, D., Handley, M., and D. Estrin, "The Internet Multicast Address Allocation Architecture", Internet Draft, draft-ietf-malloc-arch-03.txt, October 1999. [2] Hanna, S., Patel, B., and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", Work in progress, draft-ietf-malloc-madcap-07.txt, September 1999. [3] Handley, M. and S. Hanna, "Multicast Address Allocation Protocol (AAP)", Work in progrss, draft-ietf-malloc- aap-02.txt, October 1999. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] R. Finlayson, "Abstract API for Multicast Address Allocation", Work in progress, draft-ietf-malloc-api-07.txt, August 1999. [6] D. Meyer, "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [7] IANA, "Single-source IP Multicast Address Range", http://www.isi.edu/in-notes/iana/assignments/single-source- multicast, October 1998. [8] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope Zone Announcement Protocol (MZAP)", Work in progress, draft- ietf-mboned-mzap-04.txt, June 1999. Expires April 2000 [Page 8] Draft Multicast Auto-Configured Networks October 1999 [9] IEEE 802.11 specification. 10. Authors' Addresses Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 (425) 703-8835 EMail: dthaler@microsoft.com Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 (425) 936-6605 EMail: bernarda@microsoft.com 11. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN Expires April 2000 [Page 9] Draft Multicast Auto-Configured Networks October 1999 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." April 1, 2000. Expires April 2000 [Page 10] From owner-malloc@catarina.usc.edu Thu Oct 28 15:42:32 1999 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08508 for ; Thu, 28 Oct 1999 15:42:31 -0400 (EDT) Received: (from majordomo@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA14861 for malloc-list; Thu, 28 Oct 1999 12:21:34 -0700 Received: (from pavlin@localhost) by catarina.usc.edu (8.6.10/8.6.9) id MAA14856 for malloc@catarina.usc.edu; Thu, 28 Oct 1999 12:21:31 -0700 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by catarina.usc.edu (8.6.10/8.6.9) with ESMTP id EAA12596 for ; Thu, 28 Oct 1999 04:10:06 -0700 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14114; Thu, 28 Oct 1999 07:10:04 -0400 (EDT) Message-Id: <199910281110.HAA14114@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-masc-04.txt Date: Thu, 28 Oct 1999 07:10:03 -0400 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 : The Multicast Address Set Claim (MASC) Protocol Author(s) : D. Estrin, R. Govindan, M. Handley, S. Kumar, P. Radoslavov, D. Thaler Filename : draft-ietf-malloc-masc-04.txt Pages : 60 Date : 27-Oct-99 This document describes the Multicast Address-Set Claim (MASC) protocol which can be used for inter-domain multicast address set allocation. MASC is used by a node (typically a router) to claim and allocate one or more address prefixes to that node's domain. While a domain does not necessarily need to allocate an address set for hosts in that domain to be able to allocate group addresses, allocating an address set to the domain does ensure that inter-domain distribution trees will be locally-rooted, and that traffic will be sent outside the domain only when and where external receivers exist. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-masc-04.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-masc-04.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-masc-04.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: <19991027140553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-masc-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-masc-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991027140553.I-D@ietf.org> --OtherAccess-- --NextPart--