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