Re: [MBONED] addrarch: IANA allocations and assignments
David Meyer <dmm@1-4-5.net> Wed, 20 December 2006 15:33 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3Rm-0004gu-Sx; Wed, 20 Dec 2006 10:33:34 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx3Rm-0004gp-9z for mboned@ietf.org; Wed, 20 Dec 2006 10:33:34 -0500
Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx3Rj-0005ll-SV for mboned@ietf.org; Wed, 20 Dec 2006 10:33:34 -0500
Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id kBKFXOeS003150; Wed, 20 Dec 2006 07:33:24 -0800
Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id kBKFXNjS003147; Wed, 20 Dec 2006 07:33:23 -0800
X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f
Date: Wed, 20 Dec 2006 07:33:23 -0800
From: David Meyer <dmm@1-4-5.net>
To: Pekka Savola <pekkas@netcore.fi>
Subject: Re: [MBONED] addrarch: IANA allocations and assignments
Message-ID: <20061220153322.GA2160@1-4-5.net>
References: <Pine.LNX.4.64.0612201329120.22781@netcore.fi>
Mime-Version: 1.0
In-Reply-To: <Pine.LNX.4.64.0612201329120.22781@netcore.fi>
User-Agent: Mutt/1.4.1i
X-public-key: http://www.1-4-5.net/~dmm/public-key.asc
X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7
X-philosophy: "I find your lack of faith disturbing." -- Darth Vader, Star Wars Episode IV.
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4
Cc: mboned@ietf.org
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0639512647=="
Errors-To: mboned-bounces@ietf.org
On Wed, Dec 20, 2006 at 01:30:47PM +0200, Pekka Savola wrote: > AD review: IANA allocations and assignments > > 1) The draft says that IANA should not make direct multicast address > space allocations (big chunks) to operators and even direct > assignments (e.g., applications) seem like land-grabbing. > Justification for this recommendation did not seem to be suitably > well established, and this seems just discussion, given that we > presently do not make instructions for IANA (see issue 3). Issues > in particular: > > 1.1) What is the IPv4 multicast allocation approach for > those networks which will only have 4-byte AS numbers? > (Expected to happen in a couple of years.) GLOP is no > longer applicable. > > Possibilities include: > - IANA handing out static allocations (again, strongly > discouraged in Section 2.3), This is the current world, however. > - IPv4 unicast-prefix -based allocation could be marketed > as a potential solution in this space (would we need to revive > this or is the option of reviving it in the future if there is > interest good enough?), What was this? > - no approach seems to be needed for this (given SSM and v6 methods), That would, however, seem to be wrong, given the real world. SSM deployment seems to be stalled (and "my DSLAM doesn't do IGMPv3" [or whatever]), and IPv6 multicast, well, nuff said. So academic exercises aside, what people want are global scope IPv4 multicast addresses for various things, not the least (and not the most) of which is to hard-code to their application for resource discovery purposes. And we have no strategy other than to have the IANA expert look at the application and say "yes" or "no" (with very little to base those decisions on). > - something else? Like what? > 1.2) No evidence is presented that "land-grabbing" multicast assignments > has been a problem. It's true that there is still a lot of space > in the "AD-HOC Block" (224.0.2.0 - 224.0.255.0). Internetwork > control block is almost full though, and should probably not be > expanded too much. Not so if you believe that the IPv4 multicast address space is relatively small. The IANA also has a stewardship role here that we shouldn't forget/overlook. > Is there something we should do here, e.g., make Internetwork > control and local network blocks (224.0.1.0/24 and 224.0.0.0/24 > respectively) more difficult to get, tone down the AD-HOC block > language, or what? How exactly do you do that? I'll just note that to some extent it really doesn't matter what's in these documents. People come to the IANA with their requests that essentially say "No, I can't use any of these techniques. Please give me 255 globally scoped multicast addresses." (or whatever the number is). The point of 3171 was to provide some help to the IANA when assigning multicast addresses. It really hasn't been effective. To be honest, I have denied very few applications precisely because there was really no grounds on which to do so, notwithstanding all of the above. Basically, people want their own multicast address(es), even if in many (or even most) cases they don't know what that really means. That is just the nature of this game. --dmm
_______________________________________________ MBONED mailing list MBONED@ietf.org https://www1.ietf.org/mailman/listinfo/mboned
- [MBONED] addrarch: IANA allocations and assignmen… Pekka Savola
- Re: [MBONED] addrarch: IANA allocations and assig… Marshall Eubanks
- Re: [MBONED] addrarch: IANA allocations and assig… David Meyer
- Re: [MBONED] addrarch: IANA allocations and assig… Marshall Eubanks
- Re: [MBONED] addrarch: IANA allocations and assig… David Meyer
- Re: [MBONED] addrarch: IANA allocations and assig… Marshall Eubanks
- Re: [MBONED] addrarch: IANA allocations and assig… Toerless Eckert
- Re: [MBONED] addrarch: IANA allocations and assig… David Meyer
- Re: [MBONED] addrarch: IANA allocations and assig… Toerless Eckert
- Re: [MBONED] addrarch: IANA allocations and assig… David Meyer
- [MBONED] addrarch: resurrect IPv4 unicast-prefix-… Pekka Savola
- RE: [MBONED] addrarch: resurrect IPv4 unicast-pre… Dave Thaler
- RE: [MBONED] addrarch: resurrect IPv4 unicast-pre… Pekka Savola