From owner-malloc@catarina.usc.edu Mon Jun 11 12:36:36 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14295 for ; Mon, 11 Jun 2001 12:36:35 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id IAA98481 for malloc-list; Mon, 11 Jun 2001 08:59:42 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id IAA98476 for ; Mon, 11 Jun 2001 08:59:41 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id IAA18148 for malloc@catarina.usc.edu; Mon, 11 Jun 2001 08:59:41 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id CAA97605 for ; Mon, 11 Jun 2001 02:48:03 -0700 (PDT) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id CAA00797 for ; Mon, 11 Jun 2001 02:48:03 -0700 (PDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA05672; Mon, 11 Jun 2001 03:47:55 -0600 (MDT) Received: from vayne (muc-isdn-3 [129.157.164.103]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id LAA28160; Mon, 11 Jun 2001 11:47:54 +0200 (MET DST) Date: Mon, 11 Jun 2001 11:59:46 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: ZMAAP - please review To: mboned@network-services.uoregon.edu, malloc@catarina.usc.edu Cc: erik.guttman@sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-malloc@catarina.usc.edu Precedence: bulk The Zeroconf WG has issued two internet drafts related to IP multicast. These (short) documents have not received technical review. draft-ietf-zeroconf-zmaap-01.txt Standards Track We intend to recommend ZMAAP be published as a Proposed Standard, so I am seeking your assistance. draft-ietf-zeroconf-zmaap-api-00.txt Informational (or not needed?) This document specifies additional considerations not present in RFC 2771 and specifies concrete APIs in Java and C. Is this document useful? Please send comments on these documents to zeroconf@merit.edu Erik Guttman ZEROCONF WG cochair From owner-malloc@catarina.usc.edu Wed Jun 20 09:08:35 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05878 for ; Wed, 20 Jun 2001 09:08:34 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id FAA41092 for malloc-list; Wed, 20 Jun 2001 05:12:58 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from usc.edu (root@usc.edu [128.125.253.136]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id FAA41087 for ; Wed, 20 Jun 2001 05:12:46 -0700 (PDT) Received: from gemma.TechFak.Uni-Bielefeld.DE (gemma.TechFak.Uni-Bielefeld.DE [129.70.136.103]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id FAA12155 for ; Wed, 20 Jun 2001 05:12:44 -0700 (PDT) Received: from stromboli.TechFak.Uni-Bielefeld.DE (stromboli.TechFak.Uni-Bielefeld.DE [129.70.137.37]) by gemma.TechFak.Uni-Bielefeld.DE (8.9.1/8.9.1/TechFak/pk+ro20000427) with SMTP id OAA08041; Wed, 20 Jun 2001 14:09:18 +0200 (MET DST) From: Arne Hauenschild Received: by stromboli.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id OAA14731; Wed, 20 Jun 2001 14:09:17 +0200 Date: Wed, 20 Jun 2001 14:09:17 +0200 To: malloc@catarina.usc.edu Cc: pgmuscal@TechFak.Uni-Bielefeld.DE Subject: Questions about MZAP Message-ID: <20010620140917.B14114@stromboli.TechFak.Uni-Bielefeld.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-malloc@catarina.usc.edu Precedence: bulk Hello! We are a group of students trying to develop a simulation of administratively scoped multicast including MZAP. While implementing MZAP we had some problems understanding several points in the RFC 2776. The first problem is about the announcing of a router's ID using ZCMs. According to the definition of the MZAP header in the RFC the source IP address of a zam is the address of the interface originated the message. But does that mean that if a ZBR has 2 interfaces in a scope-zone it announces itself with different addresses? Example 1: : [B] : / | : / | :/ | X1 | -----[A]: | X2 | :\ | : \ | : \ | : [C] : _____________________________ | .... zone boundary | | | | ---- network connection | | | | X boundary on interface | ----------------------------- In this example ZBR A announces itself with the IP address of the interface X1 to B and with the address of interface X2 to C. When we use a routing protocol like DVMRP the ZBRs B and C won't forward the packets received from A towards each other. So B will signal a convexity problem because it reads about X2 in the ZCMs from C but doesn't receive a ZCM from the interfaceX2 directly. That won't happen if the source address in the ZCMs is always the lowest address used by a interface in the scope zone but that isn't the way described in the RFC. Another problem is about the configuration of a ZBR for the Local-Scope zone. RFC 2776: "When a ZBR is configured correctly, it can deduce which side of the boundary is inside the scope zone and which side is outside it." If there is only one interface with a boundary on it the router can assume that this interface is in one zone and the other interfaces are in the other one. But how could a ZBR with multiple interfaces configured with boundaries decide which of these interfaces belong to the same zone? Example 2: : [B]-----[D]---- : / | local zone 1 : / | :/ | X1 [E]---- ---------[A]: / X2 / :\ / : \ / local zone 2 : \ / : [C] : fig 1: router A has two interfaces in local zone 2 : : [B]-----[D]---- : / local zone 3 local zone 1 : / .............. :/ : X : [E]---- ---------[A]:......: / X / :\ / : \ / local zone 2 : \ / : [C] : fig 2: router A has one interface in local zone 2 and one in local zone 3 How can router A decide which of the two possibilities is the correct one? In this context we got a little confused about the definition of a boundary. Packets sent by router B must be forwarded by router A in order to arrive router C. This can only be done if the packets are received over the boundary on X1 and leave router A again over a boundary on interface X2. Is that the correct behaviour although the packet has to cross two boundaries? In RFC 2365, line 102 a ZBR is defined this way: Such a router, called a boundary router, does not forward packets matching an interface's boundary definition in either direction (the bi-directional check prevents problems with multi- access networks) There is no exception mentioned for the Local-Scope zone. The last question is about sending ZAMs. In RFC 2776, line 1058 is written In addition, the ZBR re-originates the ZAM out each interface with a Local Scope boundary [...] In figure 2 in the same RFC the router B receives the ZAM over a boundary but re-originates it out an interface without a boundary on it. Thanks in advance. -- Arne Hauenschild From owner-malloc@catarina.usc.edu Wed Jun 27 08:57:30 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08225 for ; Wed, 27 Jun 2001 08:57:28 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id FAA33355 for malloc-list; Wed, 27 Jun 2001 05:35:37 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id FAA33350 for ; Wed, 27 Jun 2001 05:35:36 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id FAA76891 for malloc@catarina.usc.edu; Wed, 27 Jun 2001 05:35:36 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id FAA33318 for ; Wed, 27 Jun 2001 05:25:46 -0700 (PDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id FAA21102 for ; Wed, 27 Jun 2001 05:25:45 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5RCLR029323 for ; Wed, 27 Jun 2001 08:21:31 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Wed, 27 Jun 2001 08:21:24 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N4CSBGJV; Wed, 27 Jun 2001 08:21:25 -0400 Received: from nortelnetworks.com (deathvalley.us.nortel.com [47.141.233.58]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JM9FPSDM; Wed, 27 Jun 2001 08:21:24 -0400 Message-ID: <3B39CFAE.DDE1E9E1@nortelnetworks.com> Date: Wed, 27 Jun 2001 08:21:02 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: MALLOC Mailing List CC: Allison Mankin , Thomas Narten Subject: Updated IPv6 allocation draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have updated the IPv6 allocation guidelines draft to incorporate comments made during IESG review. A key change to the document is clarification of the role IANA plays. Please take a look and post any comments or questions to the list. Editorial nits can be sent to the author. If you can't wait for the I-D editor's announcement, the draft can be found at the following URL: http://www.innovationslab.net/~haberman/draft-ietf-malloc-ipv6-guide-03.txt Brian From owner-malloc@catarina.usc.edu Thu Jun 28 09:47:03 2001 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11530 for ; Thu, 28 Jun 2001 09:47:01 -0400 (EDT) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id GAA39182 for malloc-list; Thu, 28 Jun 2001 06:31:56 -0700 (PDT) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id GAA39177 for ; Thu, 28 Jun 2001 06:31:55 -0700 (PDT) Received: (from pavlin@localhost) by rumi.usc.edu (8.9.3/8.9.3) id GAA50647 for malloc@catarina.usc.edu; Thu, 28 Jun 2001 06:31:55 -0700 (PDT) Received: from usc.edu (root@usc.edu [128.125.253.136] (may be forged)) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id EAA38812 for ; Thu, 28 Jun 2001 04:19:16 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id EAA09309 for ; Thu, 28 Jun 2001 04:19:13 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11058; Thu, 28 Jun 2001 07:15:14 -0400 (EDT) Message-Id: <200106281115.HAA11058@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-ipv6-guide-03.txt Date: Thu, 28 Jun 2001 07:15:14 -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 : Dynamic Allocation Guidelines for IPv6 Multicast Addresses Author(s) : B. Haberman Filename : draft-ietf-malloc-ipv6-guide-03.txt Pages : 6 Date : 27-Jun-01 This document specifies guidelines that must be implemented by any entity responsible for allocating IPv6 multicast addresses. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the MAC layer of media that utilizes IEEE 802 addressing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-malloc-ipv6-guide-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-ipv6-guide-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-ipv6-guide-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: <20010627132602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-malloc-ipv6-guide-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-malloc-ipv6-guide-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010627132602.I-D@ietf.org> --OtherAccess-- --NextPart--